Redo desktop nav, add options for site name and favicon #83
No reviewers
Labels
No Label
a11y
Bug
Bug fix
Critical Priority
Documentation
Feature
Feature request
Held for next release cycle
High Priority
Low Priority
Medium Priority
Minor change
Translation/Locale
WIP
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: AkkomaGang/akkoma-fe#83
Loading…
Reference in New Issue
No description provided.
Delete Branch "eris/pleroma-fe:desktop-nav-redo"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Changes include:
-Favicon being added to the nav bar
-Router links for the timelines, interactions, lists, and bookmarks
-Active indicators for which timeline you're on, similar to the timeline menu
-Change bell to bolt for interactions (the bell for notifications is in tact, don't worry)
-New user option to hide favicon in top panel
-New user option to hide site name in top panel for desktop and mobile nav, making the admin setting unnecessary
Why:
-The current desktop nav is a lot of useless empty space! This makes use of that, so you don't have to have the timeline menu stickied or scroll to the nav panel menu.
This PR is complete and ready for review
d83fb00a24toa0de673cc0this looks nice, one nitpick might be that the icons are a tiny bit too close together, a margin of 0.7em (currently 0.15em) might make it easier for, say, tablets to not misclick
difference:
0.7:
0.15:
Done
I like this idea, but what if we were to move the timeline links to the timeline panel header? (similar to how misskey has it)
This would free up the left side of the top bar in case people want to do something more elaborate with the logo without it having to fight for space there.
Edit: also keep in mind that pleroma-fe has an option to move the logo to the left side; perhaps having the favicon there too might be too much clutter. Maybe better if the favicon is an option?
there's plenty of space. if the window gets any smaller than what FG screened, it's going to switch to the mobile nav anyway which uses its own nav panel
Does it? I don't see that option in akkoma at all
I was also going to implement options to make both the favicon and the instance name hideable by the user, and then the admins could set the default for that option, but figured i'd wait until this PR went through unless we want it as part of it.
See
static/config.json, line 15:This setting moves the logo to the left where the instance name is. I think it can also be set from admin-fe. Anyway if the favicon will be an option, I don't think this will be much of a problem.
hmm that may be a remnant of upstream pleroma-fe, or a feature they decided not to implement, as the option isn't present in akkoma-fe in
src/modules/config.jsonor admin-fe here, but I see the line in thestatic/config.jsonfile you mention. Pleroma unfortunately has lots of little ghosty remnants like that with how many people work on itI'll add the site name and favicon options into this PR in a bit
Alright ready for re-review @floatingghost
I added user options for site name and site favicon. In the screenshot, I have the favicon enabled and the site name hidden
19f7d24d8dtof7222c9c83Sorry ignore the above commits, I fixed it. Was trying to address the
This pull request has changes conflicting with the target branchbut I figured that out in the next commit here:Redo desktop nav and change bell to bolt for interactionsto Redo desktop nav, add options for site name and faviconthe basis is ok, but i think i agree with fristi that moving to the timeline panel feels slightly more natural - otherwise we have 3 different ways to get to the same page
looks like this:
diff @ alt-nav
thunks?
Only thing I would change is to swap the title and the buttons around, but I guess that's just a minor detail. Either way is fine for me.
ehh, timeline name overflows on mobile for this variant
will have to scale
Dont think I'm a fan of that one, this would mean having to have two top panels basically, requiring the stickied headers and leaving the top panel mostly empty space.
hm, whilst yes the top panel is empty space, i don't think switching timelines is massively used as a regular activity once scrolling
my "market research" shows people are about 50/50 split on it as well
suffering
might just have to make a call here :notlikeblob:
i'll use my in-panel headers for a bit and see if i prefer them but it's a toss-up for sure
ok, i think i prefer the on-panel nav
but i'll patch over it to let you run a branch without the commit for minimal messing, so i'll merge this - maybe we can make it a config thing in the future since the poll i ran was darn near 50/50
any chance the locale conflict can be resolved and then i'll hit ze button?
I don't mind adding the option into this PR and letting admins/users choose if you'd rather do it that way? Your way looks good for mobile users, and more options never hurt. I try to err on the side of "let users decide everything" with disqordia anyway.
if you wanna, go for it
i was thinking that it might be a big change
but if you want to give it a shot, i've pushed my changes to the alt-nav branch, so you shooould be able to interpolate between the two branches
I could also just add an option for the left-side timeline shortcuts in this PR, and then for your timeline panel patch you can make that optional as well.
that would work as well, that sounds like the easiest way to do it
I'll take a look tonight. We can make everyone happy~
For the mobile nav, actually, should we just keep the timeline menu list and have the shortcuts option for the timeline panel be specific to the desktop view? My phone is a fairly hefty Pixel 5a, I'd imagine smaller phones wouldn't have room for the timeline name and the shortcuts unless we made it just the shortcuts only
ah yeah actually i bumped into this, check IHBA on mobile - the timeline name disappears on smaller screens
Ah yeah that's really hard to use on mobile, I keep misclicking and scrolling to the top lol
I didn't want to keep dealing with the logout button, which, regardless of gap, is always in the way and I rarely if ever click it intentionally but /often/ misclick it... This placement made sense to me, because putting it in the settings modal means when I do click it, it's intentional.
I also decided instead of maintaining one margin for my site, and a larger tablet-friendly margin for this PR, that others may also appreciate that option to either have
.2emor.7emAnd of course, as we discussed, I made all the new top nav shortcuts totally optional. Users can easily configure it to look how they're used to if they don't like it.
I hope that you like this PR, I think I've covered all the bases and my testing has been just fine.
The only thing this PR needs I think, is a check to see if an instance has a favicon at all.
However, I'm not quite sure how to do this.
Perhaps another way to solve this is to add a favicon by default, such as the Pleroma logo. Mastodon and Misskey both have this by default. But I also don't want to accidentally overwrite anyone's favicons if we go that route.
FG: Whenever you get a chance, I could use your input on this.
I'm gonna say that the favicon thing should be addressed in a different way, ie FG adding a default favicon if she wants to, and say this is ready to merge
Part of this is because, 1 they can disable the option and nbd, and 2 instances that insist on not having a favicon federate broken images to every instance that loads instance favicons, with every post they make, and should be addressed with a default favicon outside this PR
works nicely now! thank