Settings menu & UX improvements

[kommunarr]

Settings menu

Pull Request Type

• [x] Feature Implementation

Related issue

closes #4387

Description

• Implements a menu in settings for more easily navigating the sections
• Currently scrolled-to section is marked as active
• Mobile and tablet version of settings uses "fake pagination" implementation
• CHANGE: Removes "Settings expanded by default" setting and <details> / <summary> tags (now inapplicable to current design)
• CHANGE: General Settings is now always the top setting, regardless of sorting preference (read comment on e9c527a5d399416334aead62215cd201f84f0de8)
• CHANGE: Other settings sections style changes, including rounded corners, external section titles, and removal of <hr> tags (for a sleeker aesthetic)
• CHANGE: Removes experimental removing of underlines on links pre-hover with the Hot Pink theme (breaks menu link styling, and was not ever noticeably beneficial)
• CHANGE: moves settings sections from data to computed because it's needed for short title to long title fallback logic

Screenshots

Suggested Design
Live Design

Testing

• Confirm that Settings Menu works intuitively
• Confirm that General Settings is always at the top of the settings, even after sorting
• Confirm that "long" version of settings label is displayed in the Settings Menu if no "short" label exists (i.e., as of now, with any non-EN-US locale)
• Test tablet & mobile views

Desktop

• OS: OpenSUSE
• OS Version: TW

Additional context

Remaining action items

• Use SponsorBlock icon instead of generic shield icon for SponsorBlock Settings (this icon is not supported by font-awesome-icon)

Aspects open for discussion When a top banner is present on desktop view, the General Settings menu item is too low to be active, so no tab is shown as currently active if you scroll to the top. This is a very minor visual nitpick, but I just figured I would get it out of the way and say that having no active items until you scroll down a bit more in this exceptional case is fine and makes sense.

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions[bot]]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[PikachuEXE]

1. Not a breaking issue but why rounded corners FT has square "back plates" in other places

2. (I am not a mobile user so I am guessing here) The old UI is faster for user to get to lower sections (find section, open, do stuff) The new one requires plenty of scan time due to all expanded settings

[kommunarr]

Not a breaking issue but why rounded corners

Short explanation: This was admittedly a subjective design choice that I think makes for a sleeker look here.

Longer explanation: In design, you want to maximize the alignment of elements, such that if you were to draw a straight horizontal or vertical line from the start of each page element, you would have page elements line up as much as possible such that there are the fewest amount of lines present. This makes visual scanning easier. And so if we have straight edges, we would be inclined to align each settings section title along the edge exactly. But having the headings non-indented also makes their importance in the visual hierarchy less clear. So rounded edges here hit a sweet spot where there's an indentation for the titles still, and also alignment with the top edge.

The old UI is faster for user to get to lower sections (find section, open, do stuff) The new one requires plenty of scan time due to all expanded settings

Are you referring to the removal of the "Settings expanded by default" setting? That's a fair note. If Emma and/or other mobile-savvy folks think mobile navigation will be harder without that setting and without having some form of accessing the new menu, I can try to get a mobile version of the Settings menu included in this PR rather than in a later one.

[PikachuEXE]

I am fine with rounded edges due to your explanation

General better for desktop (me) but ya mobile side might be well...

[kommunarr]

@efb4f5ff-1298-471a-8973-3d47447115dc This was something that took a lot of work to hit a sweet spot for. The main problems we want to solve are 1) that the active Menu section appears to be the current section you're on, 2) that clicking on a section makes it actually show as the active section, and 3) that clicking on a section actually takes you to that section. The problem with choosing the top of the viewport below the top nav is that it it doesn't work for 1, as the last section that's just peaking through the top of the screen often appears as the active one, seeming pretty odd / not useful. I tried with other solutions like the exact midpoint of the viewport being the "current section line", which has the problem of either 2 or 3. I decided on using the top 1/4th of the viewport height as the "section line", which ends up being a decent compromise for all 3. Let me know if you have any better solution in mind, but this is the best I could find.

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions[bot]]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions[bot]]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[absidue]

[Needs further thought/discussion/refinement] Find way to integrate Settings Menu with the mobile view (currently, we're just hiding it)

For mobile I think a good approach would be to fake paginate the settings. When you open the settings page all you would see is the menu (would of course have to be redesigned a bit so it looks good taking up the whole screen) and then when you click on one of the items, it hides the menu and shows just that section, as well as a back button that takes you back to the overview. That would make it behave more similarly to the way native apps behave on mobile devices. The toggling could be handled by the menu component emitting an event when a section is clicked, allowing the Settings component to "navigate" to the section.

[kommunarr]

Updated now with your suggestions:

[MarmadileManteater]

I realise this was discussed above, but I want to talk about it because it bothers me: rounded corners. I understand that there may be well founded reasons for this design. However, my counterpoint would be that this design doesn't exist in a vacuum. Next to the other views, this one is very different. There is nothing inherently wrong with the rounded corners cardless look, but it doesn't look anything like the rest of the app.

What if the settingsSection had ft-card directly under it instead?

[kommunarr]

Thanks for the feedback, that's fair. Does this look okay now?

[PikachuEXE]

One issue becomes more obvious in this PR is the inconsistent casing of the section titles (in English)

No need to fix in this PR (can be a separate one), up to you

But also the fixed width makes the title truncated and I am not sure how troubling this would be to users with language set to one of those with longer setting section title text

e.g. español (Argentina) - Which is which?

Food for thought: How removing overflow-x: hidden; white-space: nowrap; looks

[kommunarr]

I'm personally not as much visually a fan of the wrapping. Maybe I can make it a bit wider to accommodate these edge cases. My hope was/is that the short label translations can circumvent the issue after enough time.

[PikachuEXE]

Maybe use a smaller font-size? 16px:

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions[bot]]

Conflicts have been resolved. A maintainer will review the pull request shortly.