WIP: navigation bar redesign #17
Closed
momar
wants to merge 8 commits from feature/navbar-design into master
No reviewers
No Milestone
No Assignees
9 Participants
Notifications
Due Date
No due date set.
Blocks
#21 Navigation Bar
Codeberg/Documentation
Loading…
Reference in new issue
There is no content yet.
Delete Branch 'feature/navbar-design'
Deleting a branch is permanent. It CANNOT be undone. Continue?
This PR moves the links from the navigation bar into a dropdown menu, which makes it possible to add way more links to other services we want to offer.
Obviously, everything about this design is open for discussion.
Stuff to do:
Here's the full menu again in all its glory:
Generally, this navbar should be used on all the services IMO, but that would require on a longer term a few of the following things (which are only ideas what I would do and completely open to discussion):
Codeberg Registry would probably have to be built by ourselves (I haven't found something similar yet).
Codeberg Play would be the next version of qbin.io (which I hope to release some day this year), which will then also feature Fomantic UI.
Wow, this looks really good. Are you planning on contributing some of these changes (like the searchbar and an optional dropdown menu) to gitea?
Pretty cool long-term mock-up with plenty room for new underlying functionality!
@opyale I think it's important that Codeberg has a distinct design, and especially the dropdown menu is more tailored towards a "services for developers" experience like what Codeberg strives to be, instead of just a general Git hosting service.
To make it work reliably, a patch to Gitea makes sense though, and I'll probably implement it as one - that way, someone would be able to just use the code & design to build something flexible enough for an upstream patch, but honestly it's not really a priority for me right now.
Just wondering, wouldn't maybe CI and chat be more intuitively integrated as project/org/repo tabs, like issues and wiki?
You're absolutely right about that, but most of the tools we could utilize for that are inherently standalone - I'd vote for both, the navbar menu for accessing the standalone application directly and the tabs for an embedded version of just the relevant page, with a "open in new tab" button for the standalone version.
Hi there, this looks like a useful addition to the relatively static, linear menu. Can somebody explain to me where this menu would appear and what parts would change based on being browsing your own repo/repos or not being logged in.
I do have some ideas for improvement depending on getting the big picture here.
My idea is that it's present on all Codeberg sites - Gitea, blog, documentation, and maybe even other standalone services (although that's a huge amount of work).
The left side of the dropdown (and the club-related stuff at the bottom right) would then be completely identical on all pages (letting you choose the service, kind of like apps in Nextcloud), while the remainder of the right side of the dropdown is specific to the current service (Gitea in this case).
The navbar would then always have the Codeberg logo, the current service's name with the dropdown menu ("Codeberg Repositories" in this case), while the rest could be service-specific for now. It makes sense though to make search & notifications global (again a lot of work), and maybe always have the account menu with logout and the link to the profile page & settings.
If the goal is to underline parts of the project being separate, but also part of a big picture, I can imagine each section getting color coded, similar to the "Pages" using the dark green:
The current use of the wordmark is problematic in two ways:
it does not use the correct kerning and weight of the original font and looks off:
it should not be separated from the symbol, ideally the symbol can stand on its own, but never just the wordmark alone.
That's why I would remove ist. As a side effect you'd gain valuable space in the layout by not repeating "Codeberg" so often. An interesting approach might be to just use the respective service title like "Pages" in a recurring, maybe even color coded style.
Something like this:
…we would need to work on a proper palette for that first though…
Oh, this also includes not re-arranging the symbol and word mark next to each other in this case:
Here the element that should remain in tact gets truncated in being partially inside a button, partially not. Both parts linking to different places.
The triangular layout if the symbol+wordmark should not get lost (attached an animated gif – for some reason gitea really sucks at using webm and even gif inline)
At some point there probably should be a documentation to make dos and don'ts of our logo usage clearer.
Thanks for the input, I think dos and donts are quite important for the logo in the long term.
The triangular layout is cool, but I think it's not that great for the navbar to have logo and text below each other?
You're absolutely right. That's why the symbol should be expressive enough and usable at small sizes: we can just use the symbol.
In the long term we should try getting the symbol known – not so much the word mark. I'm finw with having it on the landing page(es) but it seems a bit long for the menu anyway…
So, maybe a bit like this?
The color coding IMO only makes sense when the primary color on the page (for links, buttons, ...) gets changed, and the navbar stays blue - or would recoloring the navbar be an option for you as well? That way we'd loose our brand color though...
I think it'd be a bit confusing though to use color-coding if the navbar doesn't change color. Maybe we should just use icons in the dropdown?
Yes, looks much better to me.
Color coding was just a rough idea to think about in the long term. The idea wasn't to tint the entire page but just give the different sections a slightly different, but subtle home feeling – not a complete switch of all colors.
I wouldn't use the logo font for the subsection entry in the menu. If you want to do so, I'd choose a slightly heavier weight.
Hm, I think the logo font makes sense for the navbar (I couldn't find something similar with the default font of Gitea), but for the menu, I think you're right and the default font looks better - I'll play around with this in the next couple days, but I have used a slightly heavier weight in the navbar for now.
Regarding the color coding, I came up with a concept for Codeberg Pages a few weeks ago, which incorporates your color example like this - would be great to know what y'all think about it:
My biggest worry is that some of the colors may clash with the navbar, but we'll have to see how bad that is.
@momar I can't say anything specific about the color now, but in my opinion you've done a really good job with the design and it fits almost perfectly with the rest. 👍
Your last post seems to be more abou the "Pages" landing page, than the menu.
Maybe Codeberg/Design#5 is the better place to gather feedback about it?
I've just used that as an example of what the color coding could look like here, for Codeberg Pages that's actually for a whole different version with completely different features (like custom domains, building projects with static-site-generators and so on) that will maybe, some day, in the far future, replace the current version.
what is the current state @momar ?
I'm currently working on a more generic toolkit for this new design approach, that includes all required styles for the navbar and a customizable menu.
It will work on all pages using Fomantic UI (like Gitea), so that will be required for all official Codeberg services for now. Maybe it'll be possible to extract only the required styles somehow in the future.
I'll push my current state this week, but this will be moved to the Codeberg/Design repo, as the toolkit will be an independent design resource instead of part of the build process itself.
That sounds great, and the Fomantic-based approach fits well with Codeberg/Design#20
Alright, I've got a little update ready: on https://codeberg.org/Codeberg/Design/src/branch/master/navbar, there's now a template for a navigation bar, which is now responsive and will be available in two versions: one that's standalone and comes with all CSS rules embedded, and one that's part of a whole Codeberg UI kit based on Fomantic UI.
Currently I'm only targeting Gitea though, and will try to incorporate the new design into this PR in the next couple of days.
All the entries and configuration related to Codeberg in general are stored in
brand.json, andcodeberg-*.jsoncontains the links specific to the various services.It relies quite heavily on JavaScript for translation and user status though, and accessibility is something that might take a hit by this, so if someone has an idea how to improve that while still keeping it as portable as it is right now, I'd be really glad to implement it.
How it looks on mobile now (clicking the arrow next to "repositories" shows all services):
Does Codeberg plan to self-host Rocket Chat?
I'd advise against that, especially in light of the Gitter + Element merge.
If a Matrix home-server was hosted instead, you could achieve native interoperability with Gitter, and an emerging community of developers :-)
Hm, that sounds interesting, didn't know that they want to switch over to Matrix. The idea came from Codeberg/Community#38 - seems like Matrix now does support SSO, albeit I'm not sure how good it works with Gitea's OAuth2. Definitely something to think about, but probably makes more sense to discuss in the other thread.
If there is something needed to support Oauth2 for Matrix on the gitea side I'm happy to help ..
but I think it got impemented alreadyGitea Support Webhooks to Matrix & Gitea can serve as Oauth2 Server ...
@6543 : There might be some protocol/compatibility issues, would you like to get access to https://codeberg-test.org to drive a test installation?
Might be worth a consideration: In the recently linked issue (Codeberg/Community#392) we talked about moving some CSS as the forced navbar creates some colour inconsistency with custom themes, this problem would increase with more themes.
Maybe we should keep this in mind once we add the new navbar, probably be putting the layout as CSS in the Codeberg overrides and reusing the colours from the theme via CSS vars.