Labels
Clear labels
Design relevant outside of Codeberg
Codeberg Design Kit
Codeberg's navigation bar
Gitea themes
The priority is critical
The priority is high
The priority is low
The priority is medium
Something has been confirmed
Something exists already
Something was marked as invalid
Something won't be fixed
Work is complete
Work is in progress
Feedback is needed
Apply labels
Kind: Breaking
Kind: Bug
Kind: Documentation
Kind: Enhancement
Kind: Feature
Kind: Maintenance
Kind: Public Relations
Design relevant outside of Codeberg
Kind: Question
Kind: Security
Kind: Testing
Kind: Web Design
Part: Color Palette
Part: Design Kit
Codeberg Design Kit
Part: Fonts
Part: Logo
Part: Navbar
Codeberg's navigation bar
Part: Themes
Gitea themes
Priority: Critical
The priority is critical
Priority: High
The priority is high
Priority: Low
The priority is low
Priority: Medium
The priority is medium
Reviewed: Confirmed
Something has been confirmed
Reviewed: Duplicate
Something exists already
Reviewed: Invalid
Something was marked as invalid
Reviewed: Wontfix
Something won't be fixed
Status: Blocked
Status: Completed
Work is complete
Status: Help wanted
Status: In progress
Work is in progress
Status: Needs feedback
Feedback is needed
Status: Stale
No Label
Kind: Breaking
Kind: Bug
Kind: Documentation
Kind: Enhancement
Kind: Feature
Kind: Maintenance
Kind: Public Relations
Kind: Question
Kind: Security
Kind: Testing
Kind: Web Design
Part: Color Palette
Part: Design Kit
Part: Fonts
Part: Logo
Part: Navbar
Part: Themes
Priority: Critical
Priority: High
Priority: Low
Priority: Medium
Reviewed: Confirmed
Reviewed: Duplicate
Reviewed: Invalid
Reviewed: Wontfix
Status: Blocked
Status: Completed
Status: Help wanted
Status: In progress
Status: Needs feedback
Status: Stale
Milestone
Set milestone
Clear milestone
No items
No Milestone
Assignees
Assign users
Clear assignees
No Assignees
5 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.
No due date set.
Dependencies
No dependencies set.
Reference: Codeberg/Design#23
Reference in New Issue
There is no content yet.
Delete Branch '%!s(<nil>)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
No
Yes
This is a mockup for a new footer for Codeberg.
Its main purpose is to create space in the main menu until Codeberg/build-deploy-gitea#17 is ready, but its life can be extended beyond that to add a neat index of important links at first glance at the bottom of the page.
It would keep the items for daily usage (plus Donations 😉) in the top menu, while moving items that are used less-than-daily down to the footer.
It would solve the following issues the short term:
I’m not sure yet where to put the language selector in this design. I'd currently lean towards putting it centered in the very bottom, under the small print.
Please share your thoughts on this design and feel free to comment and critizise it.
Generally nice, maybe the double logo is a bit irritating?
Yes, that was a concern of mine too. Maybe the logo should be in grey instead of in color, so more like a watermark?
By the way: While redesigning the footer, we could also add links to our profiles on Mastodon etc. - maybe as its own column ("Social"?)
good point
I like the idea of having that footer.
Just for reference this is how github/Gitlab/Bitbucket present their footer for anonymous users on the homepage:
Is this footer to be displayed in for logged in users, too? It might make sense to not have that heavy footer in your way all day if you just want to keep working (like GitLab handles it).
Donation links should remain in the top header either way ;)
I like the clean structure that resembles the gitlab one 👍
Just the logo-symbol would suffice here imo
Adding more linespacing would probably make it "lighter"
making use of some darker background makes the section cut clearer
Uppercasing looks better but messes too much with Codeberg not supposed to be looking like CODEBERG. :P
maybe we should feature a mastodon link, too?
Here I juxtapose what I would probably change on your proposal:
I like the color scheme of your mockup and I think the roomier spacing makes it appropriate for use on the main page, when not logged in 👍
To answer your questions:
Where would you suggest to put the language chooser? It's a bit "lost" down in the footer. Maybe putting only the globe symbol in the main menu would be an option (but that would mean space lost there 🙈)
The real benefit would come from having less content (or no content at all) in the footer, not the actual size of things. I guess it is just like working on a tidy bench. For consistency I'd not go for different footers (except responsiveness)
No idea. But it could look like that:
It is always a good thing to put that kind of link in a place where people are used to find them on other pages: the top right. I'm not a huge fan of the
icon, but it does the trick and would not take up that much space up there.
Okay, but there needs to be some place to put the links for logged-in users as well, IMHO. Where would we put them so that people can find them if there's no footer and not enough space in the main menu?
As a rule of thumb, I'd avoid having any link exclusively in the footer. I know that's not really helpful in that case but ties into the general way of how navigation is structured.
I don't know the current status of the redesign of the main menu…
See Codeberg/build-deploy-gitea#17
The footer approach would really be a quick stop-gap solution until the new main menu is completely finished. As such, it would be acceptable to have it also visible for logged in users in the short term, in my opinion.
I don't see the footer links as a replacement for anything. Especially for new visitors it is an easy and established way to find certain links. Even the best possible main menu would benefit from also having the essential links in a footer.
I can't follow. What intended replacement are you referring to?
Did you mean "the main menu as a replacement" in your first sentence?
In any case: Wouldn't what you said also apply to logged-in users? I mean, as a logged-in user I would like to be able to find the links in the footer too, right? I can see though, that they would be a bit heavy on the looks. But by making the footer a bit more "quiet" in the logged-in case and giving the main content some breathing space by adding an appropriate margin that could be mitigated.
No, I just wanted to say that the footer links should generally not replace any other link. (Including any link of the new main menu)
If I understood you correctly you proposed to put up the footer in question, only as long as the the new menu isn't available, then remove the footer as the new menu would probably contain all needed links.
Yes that seems about right. 👍 So, how do we more forward now?
I think having the proposed footer for all not-logged in users is a safe next step either way.
Logged-in users should not miss any important links and get them at least via one other place.
That does not need to be a menu item, but could also be any page.
I think it's problematic to have these links hidden behind a level of indirection. We wouldn't want to sacrifice the findability of e.g. the Blog to keep the design slightly more minimal.
Currently, I don't have the time to start to implement a partial solution that misses the goal of quickly and effectively providing space in the main menu for all users. This is especially with the new Documentation site in mind, which currently is not findable for most users because of this problem.
Can you suggest a concrete alternative that's quick to implement and that would be acceptable for you design-wise? Then I can get to work and implement the PR.
I don't want to interfere with current work that is happening in the menu. I think it is a lot of effort to wrap your head around the project and come up with a good structure, and I currently don't feel well prepared to even start that task.
But as of next steps, just having your proposed footer as an addition poses no real problem at all. Hiding the footer (for logged in people) and restructuring the entire menu are added bonus from my perspective ^_^
File in question is
footer.tmpl
to be placed in https://codeberg.org/Codeberg/build-deploy-gitea/src/branch/master/etc/gitea/templates/custom -- please check the gitea docs for detailed discussion of the template system.If we have a PR we can merge+deploy to codeberg-test, after due testing, to production.
@hw - Thank you :) I will try to have a look at this when being back on my development machine on Sunday (right now I'm travelling and I have limited free data traffic 😉)
Mockup for Footerto Redesigning the Footer 3 years agoAfter having a closer look at it now, I unfortunately couldn't find a way to remove the default footer for replacing it with an entirely custom footer as proposed above using only Gitea's custom template system.
As this now would require changes to Gitea itself, and as I'm not that knowledgeable about Gitea's internals and development process, I will leave this idea here for now and invite anyone who is knowledgeable about these things to pick it back up.
Please see Codeberg/Community#288 for an idea on how to simplify and speed up frontend development in the long run :)
@lhinderberger : as quick'n'dirty hack for a MVP: would it work to set "display: none" to disable elements that collide with the template?
@hw Yes I think that could work, the element to be hidden in this case would be the
<footer>
element fromtemplates/base/footer_content.tmpl
.That file also contains the source for the language selector. It might be worth moving that out into an individual template in the Gitea sourcecode, which could then be included from the custom footer.
I won't be able to have a closer look at this until at least next week though.
@lhinderberger @hw Is https://codeberg.org/Codeberg/Design/issues/23#issuecomment-80656 the relevant mockup? I'm thinking of working on this.
This would be great! The gitea templates are in https://codeberg.org/Codeberg/build-deploy-gitea/src/branch/master/etc/gitea/templates/custom, gitea supports a
footer.tmpl
template file.Looks like we are stuck with having no footer for some time now. Are we waiting on anything particular?
@mray - I'm not sure if @binyamin is working on this now, but I have stopped working on the issue a long time ago.
I'm considering this an abandoned issue. Won't close since I didn't open it.
@mray I didn't intend to abandon it, and I'm sorry that I gave that impression. I've had trouble deploying codeberg locally, so I can't really work on codeberg at all now. If there's a working docker image, that might help. If I have specific questions, I'll mention something in a matrix room.
Just checked my setup. I'm waiting on Codeberg-Infrastructure/deployment#3 (cc @momar)
@binyamin I don't know if the deployment repo works by now, but I propose not to use the templating system in build-deploy-gitea, but develop this directly in the gitea source code. (Edit: or check if this works #23)
Gitea also has more documentation on how to work on the code, just checkout the codeberg/gitea repo (current branch), read the Gitea guide on what you need (probably mainly npm and Go), and then run for example
make TAGS="sqlite" watch
to continuously rebuild Gitea while you are working on it.You could directly fiddle with the template files, maybe create a codeberg_footer.tmpl and replace the Gitea footer with an inclusion of that one.
You can also push non-working stuff and ask for help. I'm quite familiar with dirty fixes to the Gitea templates by now 🤷 🙈
The footer has been redesigned implementation pending or not going to be fixed. Design work can be considered done. Closing.