Hi @pkrasicki, I think this looks really cool! My only thoughts are these:

1. Would it be possible to keep the same HTML structure and more treat the tabs as anchor links in a fixed/sticky container? This would allow users to still scroll through. You could still de-emphasize the section headers with this implementation as you suggest.
2. Given that the same structure is still intact (under 1), I think it would be fine/preferable to keep the mobile behavior the same, perhaps just styled differently.
3. The no-background look does look cool on this theme, but it will have color contrast issues on many themes, especially with things like disabled or certain controls (example: Light Mode with a disabled ft-toggle). For that reason, I would suggest that any implementation keeps the same --card-bg-color background.
4. If 1) is implemented, I think it would be logical for this to tabs to appear when the "Expand All Settings Section" toggle is enabled. That, and we may have to revisit enabling that setting by default and/or removing the option altogether.

Toggle switches are usually located on the right side, so maybe that should be changed too.

I think it would be good to change, IMO this could make FT feel more familiar to other applications

@jasonhenriquez if you want users to be able to scroll through, then I think something like this would be better :)

Looks really good! The icons are a great touch.

This looks really cool @pkrasicki !

Looks cool but extending the layout like that will only work when FreeTube is full screened, many users including me never use FreeTube like that, so you'll have a tough time fitting the tabs into the tiny margin that is left.

Yeah, the tabs would have to wrap horizontally like the design in the OP at some width breakpoint (if we do want them to be vertical above that breakpoint, that is), and possibly disappear at another. We'd have to do some testing with the mobile UX and maybe consider emphasizing the section titles to their current glory at the lowest viewport sizes.

On mobile it would probably be best to either keep the existing layout or have multiple pages.

If we go with the second design, then on smaller screens it would work exactly like this:

So on mobile the app would just have to:

• first hide the content and display only categories
• when a category is clicked, hide the categories and display the content instead
• add an extra button to let the user go back to categories (by hiding the content)

Looks cool but extending the layout like that will only work when FreeTube is full screened, many users including me never use FreeTube like that, so you'll have a tough time fitting the tabs into the tiny margin that is left.

On smaller desktop resolutions we can display the content as one column. There is already a breakpoint for this set to 680px. We can move it to 1000px and that would solve the issue.

This implementation would remove the need for #1739

Hi @pkrasicki just checking in to see what the current status is of this

@efb4f5ff-1298-471a-8973-3d47447115dc I don't plan to implement this. I just wanted to help with the design and I think that part is finished.

@pkrasicki Could you share the file or link with which you made the design?

One issue with this design is that the --bg-color on most themes does not provide enough contrast with the color of our controls, particularly ones with false and disabled states. This is a concern I pointed out earlier, but it didn't seem to get considered in your later revisions. We will have to either use the --card-bg-color as the all-encompassing color or keep our sections with the --card-bg-color but greater stylization (similar to the design referenced here).

One implementation detail is that if we're adding 14 new short labels, we will most likely also need to have manual logic with $te to fall back to the long label if no short label exists. The set of resultant labels will have to be the ones used for sorting the sections if A-Z sorting is enabled.

I still want to consider the possibility of having the vertical menu become a fixed short-height horizontal scroll menu on mobile devices. I have doubts about the ease of use of the "click section and go back" pattern.

@jasonhenriquez I drew those in Gimp by editing screenshots, so there isn't anything useful I can give you other than the list of icons, but you already figured that out. The only difference is the icon for proxy - I used network-wired. I couldn't find an svg icon for SponsorBlock, so I just resized their png logo and changed the colors.

One issue with this design is that the --bg-color on most themes does not provide enough contrast with the color of our controls, particularly ones with false and disabled states. This is a concern I pointed out earlier, but it didn't seem to get considered in your later revisions. We will have to either use the --card-bg-color as the all-encompassing color or keep our sections with the --card-bg-color but greater stylization (similar to the design referenced here).

You are right. In my current design I added a background for the settings section like you did in your implementation:

One implementation detail is that if we're adding 14 new short labels, we will most likely also need to have manual logic with $te to fall back to the long label if no short label exists. The set of resultant labels will have to be the ones used for sorting the sections if A-Z sorting is enabled.

I don't understand what you mean by this. I also don't get why there needs to be a sorting feature.

I still want to consider the possibility of having the vertical menu become a fixed short-height horizontal scroll menu on mobile devices. I have doubts about the ease of use of the "click section and go back" pattern.

That seems to be the standard in mobile apps (Android and iOS settings, GNOME settings, NewPipe), but at one point I considered something like this:

Other notes:

1. You should decide if you want the switch label to be on the left side like it is in most applications. If yes, then it would probably be a good idea to change that now.
2. Consider removing the experimental section and moving it to a config file. The change itself can be done later.
3. Consider removing Match Top Bar with Main Color and Hide FreeTube Header Logo from theme settings. The change itself can be done later.
4. This is unrelated, but:

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)

I would remove underlines from all links everywhere and show them only on hover. The only exception could be channel name.

The only difference is the icon for proxy - I used network-wired. I couldn't find an svg icon for SponsorBlock, so I just resized their png logo and changed the colors.

Thanks for your review @pkrasicki, I didn't know what to search for that icon; I'll update that. As for the SponsorBlock one, this will most likely take some individualized code to load it from a non-fontawesome icon alongside the others, so I'll intend that for a follow-up PR.

I also don't get why there needs to be a sorting feature.

This was added in #5010 as a convenience feature for users who want to scan the menu alphabetically.

You should decide if you want the switch label to be on the left side like it is in most applications. If yes, then it would probably be a good idea to change that now.

I'm open to it, but again, will prefer if you have a source or knowledge relating to design principles as to why it's better rather than just different. Please create a feature request with the rationale and specific suggestion.

Consider removing the experimental section and moving it to a config file. The change itself can be done later.
Consider removing Match Top Bar with Main Color and Hide FreeTube Header Logo from theme settings. The change itself can be done later.
I would remove underlines from all links everywhere and show them only on hover. The only exception could be channel name.

Please open up feature requests for each of these with rationales for tracking purposes.

This was added in #5010 as a convenience feature for users who want to scan the menu alphabetically.

Wasn't it just a workaround for the original design? Kinda like the previous switch, which allowed to expand all sections.

@efb4f5ff-1298-471a-8973-3d47447115dc

This implementation would remove the need for #1739

Wasn't it just a workaround for the original design?

I'm not sure, but having it synergize with the Menu was my intent when I released that PR. I'm fine with removing it if it's not something people want, but my hunch is that it's nice to have the settings arranged in a more visually scannable order (i.e., if you don't remember our built-in section order, but might know what the name or starting letter of the section is that you're looking for).