Reorganize music folders dialog

[etyarews]

Description

The "Music Folders" Dialog, while not bad, is rather weirdly organized. I will simplify how it currently works and is organized:

1. List of user selected folders
2. Mode: Segmented Button regarding how Auxio will interpret the folder list.
3. Add button on the bottom: Will add folders to the list.

Again, not bad, but weirdly organized, not sure if I can explain with words, but: #2 controls how #1 is seen, and #3 adds to #1

I would move the Segmented Button to the top of the dialog, and remove the "Add" buttom from the bottom of the dialog, the "Add" can translate to a big word in certain languages anyway which makes that area crowded. I would put the Add button on the list of folders, you could add a "+" icon as well

EDIT: Ah btw, the segmented button is lacking the checkmark

Problem solved

No response

Other implementations

Honestly, idk, the issue here is just a slight reorganization

Benefit

A better UI makes users less confused about features

Duplicates

• [X] I have checked this feature request for duplicates.
• [X] I have checked that this feature is not implemented in the lastest version.
• [X] I have checked the Why Are These Features Missing? page.
• [X] I agree to the Contribution Guidelines.

[OxygenCobalt]

Those are some good ideas, I'll see what I can do.

Actually, I was thinking about removing the segmented button outright and just having two "Included" and "Excluded" lists of directories instead. I really am not a fan of the current setting, as it feels much closer to "This is technically easy" rather than "This is the most sensible option".

[etyarews]

Actually, I was thinking about removing the segmented button outright and just having two "Included" and "Excluded" lists of directories instead.

Not exactly sure how the hell that would work, as they appear to be fundamentally opposite of one another:

• "Included" means everything outside the listed folders will be excluded.
• "Excluded" means everything outside the listed folders will be included.

Do you see what I mean?

[OxygenCobalt]

Yeah, that's the issue. I'll keep giving it some thought.

[etyarews]

Honestly, I fail to see how the segmented button isn't the right tool for the job. You can't use both options at the same time, and they both have a list of folders under them. The only thing your implementation lacks is the checkmark.

You even added a small text explaining what the current option does. The only other way to change this is to remove the Included/Excluded from the dialog and put it as a separated option on the settings page, which works, but I'm not a fan of.

Also, btw this is off-topic, but have you considered moving different sections of the settings page into their own sub-pages? Google hasn't updated supplementary guidelines to M3, but under M2 they state that you shouldn't have more than 15 options on a single screen, and I have to agree with them, as it makes it harder to "compartmentalize" those settings in your head.

[OxygenCobalt]

Honestly, I fail to see how the segmented button isn't the right tool for the job. You can't use both options at the same time, and they both have a list of folders under them. The only thing your implementation lacks is the checkmark.

You're right. I'm not quite sure how to add a checkmark, but I'd imagine it's possible.

Also, btw this is off-topic, but have you considered moving different sections of the settings page into their own sub-pages? Google hasn't updated supplementary guidelines to M3, but under M2 they state that you shouldn't have more than 15 options on a single screen, and I have to agree with them, as it makes it harder to "compartmentalize" those settings in your head.

I really should get to doing that. Mostly inertia and an unwillingness to having to wrangle the preferences API to get what I want.

[etyarews]

You're right. I'm not quite sure how to add a checkmark, but I'd imagine it's possible.

Not sure why you'd need to manually add a checkmark, it is a component of Material Design 3, it should already be available in whatever the hell you use to make Auxio

[KraXen72]

personally I would rather have a list of settings with headers, or just 1 level of categories, that are obvious what they contain. (+ a search if needed) big apps like twitter love to put 2-3 nested categories of settings, with a search that does not work properly, resulting in me spending like +40 seconds of time every time i want to access something like change my account from private/public (twitter: obviously, that settings is in Privacy & Security > User Settings > Account Settings > Profile preferences > Set who is allowed to access your account or whatever).

only app i've seen properly manage a lot of settings in categories is tachiyomi (manga reader) although sometimes even there people ask about where is what setting because they're too lazy to dig through 1 level of categories.

[KraXen72]

Not sure why you'd need to manually add a checkmark, it is a component of Material Design 3, it should already be available in whatever the hell you use to make Auxio

i checked the md 3 docs, and it seems it's ambiguous how to add a checkmark, it's only mentioned that you can somehow add a checkmark. but i only checked m3.material.io, there are probably? other docs too

[etyarews]

Not sure why you'd need to manually add a checkmark, it is a component of Material Design 3, it should already be available in whatever the hell you use to make Auxio

i checked the md 3 docs, and it seems it's ambiguous how to add a checkmark, it's only mentioned that you can somehow add a checkmark. but i only checked m3.material.io, there are probably? other docs too

It's pretty clear that:

1. You should replace an icon with the checkmark when the button is selected
2. It's not optional for selected items.

Therefore, selected items need to have an icon, and that icon should be a checkmark. It should be a component available on Jetpack or MDC-Android

[etyarews]

personally I would rather have a list of settings with headers, or just 1 level of categories, that are obvious what they contain. (+ a search if needed) big apps like twitter love to put 2-3 nested categories of settings, with a search that does not work properly, resulting in me spending like +40 seconds of time every time i want to access something like change my account from private/public (twitter: obviously, that settings is in Privacy & Security > User Settings > Account Settings > Profile preferences > Set who is allowed to access your account or whatever).

only app i've seen properly manage a lot of settings in categories is tachiyomi (manga reader) although sometimes even there people ask about where is what setting because they're too lazy to dig through 1 level of categories.

Issue with a single list of settings is that now the user is required to remember not only in what page the option is, but also in what part of the screen it is. More than 15+ in a single page means that in that single page there are at least 2 to 3 "screens" of content they have to scroll depending on the device.

Auxio currently has 3 and half "screens" that needs to be scrolled to find the correct option. For an end user it is far better to have the least amount of "screens" they have to scroll, so they can keep more stuff in view, hence why it is suggested to limit to move to nested pages.

Of course there is a limit to how much you can optimize, more than 3 levels of categories is absurd in my opinion (maybe 4 if the highest level has no actual options and is just a list of pages to open)

[OxygenCobalt]

Done. Here's the new UI.

[etyarews]

Hey, uh, just asking, but where did you find that divider with title? I didn't find it on the M3 website.

Gboard and System Settings (at least on Android 12) separate categories of options withprimary color and title-small font, no divider needed

[OxygenCobalt]

Personal preference. I feel as if headers are too "empty" without a divider.

[etyarews]

Huh, I feel full width dividers separate too much and run against M3 more seamless integration of certain elements in comparison to M2 and M1. Like how the top app bar now have the same background color unless scrolled.

[OxygenCobalt]

Reading the guidelines. It says this:

Dividers are one way to visually group components and create hierarchy. They can also be used to imply nested parent/child relationships.

I largely interpret this as allowing me to use divider-based headers, as they are meant to provide a clear visual separation between elements. That's just me though.

[etyarews]

I interpret that as they are meant to provide a clear visual separation between elements.... when it is necessary. As when the separation or the hierarchy can't be implied by other means, you are supposed to use dividers.

I personally don't think Auxio is using them right in most of the Settings Pages. For starters, most of the settings have some sort of relationship between each other (specially with #323), which means a full width divider is probably not necessary. And even then, an inset one also doesn't appear to be necessary, as the entire screen is made out of list items that change settings. A simple and small title with primary color is visually less distracting than a full width line and medium title, which is also what google has chosen to do.

I asked where you got the idea behind "Title+divider" because it is really weird with the rest of M3:

• The divider is saying: Things on top of me are separated from the things below me
• The title is saying: I represent things below me

When you mix the two in that way, it appears like the title is representing only itself and the things on... top of it...? This wasn't a problem in M1 and M2 because "title+divider" looked similar enough to the Top App Bar and its shadow. On M3 it just feels...weird, and I can't say I've seen something similar in a Google App that was upgraded to M3.

In short, I feel like Dividers are only supposed to be used when:

1. You can't separate items visually through other means
2. You can't imply hierarchy through other means
3. There's related elements that work fundamentally differently from one another, body text from selection chips, or interactive vs non-interactive elements in a card, and the difference isn't obvious.

[OxygenCobalt]

Okay, I guess those are some fair points, but I just can't accept a UI design like this:

It feels under construction. The perception of empty space is far too much.

[etyarews]

Alright three things:

1. You should really change the font to title-small and the color to primary, to not mistake it for one of the items
2. You... don't need to remove every instance of the divider, you know that right?
3. I think the padding is overkill

[OxygenCobalt]

1. Good point.
2. Which instances of the divider should I remove?
3. As far as I'm aware, this is the minimum amount of padding I can do.

[etyarews]

1. Remove it in the Settings. Except maybe in the main settings page to separate sub-pages and settings you can directly change. Might be worth to try with an inset divider and no divider in the main settings page.
2. I would also test moving the divider to be on-top of the title rather than below it on the cases where it is necessary.
3. Definitely keep the full width divider on the Album/Artists/Genres screen below the "Play" and "Shuffle" buttons, but you could get away with removing the dividers to separate the types of songs below it, or at least change it an inset one, as they are all songs under the Info

[OxygenCobalt]

Yeah, I can't do this. No matter how I structure it, it will always look overly empty and unfinished or asymmetric and jarring.

[etyarews]

....not even in the settings?

[OxygenCobalt]

I want the UI to be consistent. I'm not going to use divider + headers in some places and them omit it from elsewhere.

[etyarews]

Remove it everywhere then? The smaller font+primary color could look good enough, at least share a mockup

[OxygenCobalt]

Still too empty.

[etyarews]

On my desktop it doesn't even look like it is the primary color

[OxygenCobalt]

I'm using the secondary color as that seems more correct in this case.

[etyarews]

I don't want to put Google on a pedestal, as fundamentally we are allowed to do what we want with our designs, but eeeeh? In this case I really think you should stay close to default Google-made M3 design:

System Settings:

Gboard:

Furthermore, on the official Material 3 Design Kit, there is a divider type with a subhead. The Text is set to title-small, the color is strangely set to "on-surface variant", but the divider is on top of the subheader, and it is also an inset one rather than full width

[OxygenCobalt]

I don't really consider the settings app "canonical" M3 (see: Switch styles, accent choices, etc.). As for the figma kit, it's hard to say whether "subheader" is referencing extra information below something, or the beginning of new information.

[etyarews]

Fair, but that style of header is present on other google apps, like Gboard, Sheets, and I think pretty much every google app that I have on my phone, except Youtube. I don't think there is a pure "canonical" google M3 app that we can definitely point out as a solution to the subheaders thing.

It's not easy to see in the image I shared because of the Figma borders, but there is a middle inset divider on top of the subheader:

I think the Figma Kit is pointing and fixing the issue I mentioned with your dividers+headers:

In your case, the header says it separates things above it from below it, but the divider is also saying the same thing, which results in the Header being separated from the its contents due to the divider. Just moving it to the top would fix things, and maybe changing it middle inset dividers would also help

[OxygenCobalt]

You're right, actually. I think I've settled on a divider design that would work okay.

I'm going to meet you in the middle and use the secondary color. For my M3 theme, the primary color is too vibrant. It ends up drawing too much attention to the header. The secondary color is more subdued and will work better as header text. However, it won't be like the surface variant color, which is hard to distinguish from text.

[etyarews]

I think the secondary color is too subdued? Might be different on an actual smartphone with the rest of the UI matching the color, but on the desktop it is too subdued. And I thought the whole point of the subheader was to draw attention to itself.

Anyway, I'm glad with this result, but would suggest trying using a middle inset, just to see if it looks ok.

[OxygenCobalt]

I'm using an actual smartphone. In general, headers should try to make themselves known without being the center of the show.

As for an insetted header, seems like those are for "related" content. Albums and Songs aren't exactly that related, so I don't really believe an insetted header is necessary.

[etyarews]

That's fair, but my suggestion is more because you previously stated you want every header to look the same, even when it makes no sense for it to have a full width divider, like in the settings

[OxygenCobalt]

It does make sense, actually, given that I'm separating different categories of settings with the divider.

[etyarews]

But they are all list items that represent changes to the app, they are all... settings. They are the same thing, they behave the same way, they look the same. They are not separated because they are completely different from one another, but rather because it is more convenient for humans to organize in categories for us to not be overwhelmed.

It is a fundamental different beast from separating Albums and Songs those are completely different things, one being a collection of songs and the other being songs.

[OxygenCobalt]

Here's a counter-example in the M3 guidelines for the divider:

The full width divider is separating items that are contextually the same (people), but different in category. My usage of the divider to visually split up settings categories makes sense then.

[etyarews]

Here's a counter-counter-example:

The use of full width dividers in that picture is explicitly said to separate hierarchy from a list that already uses inset dividers.

And the guidelines are pretty clear, you shouldn't use dividers if the separation of elements can be done through the use of white space:

https://m3.material.io/components/divider/overview#aa02ccce-0a34-49ca-9bdf-d5e4f77972bd

[KraXen72]

the m3 guideline discourse 🍿 (by all means, please do continue)

[OxygenCobalt]

I would argue that "elements" in that context could refer to when whitespace is used to refer to another context. In Auxio, whitespace is already used to separate list items, so re-using it to separate groupings is confusing.

[etyarews]

Very unlikely, as the same terminology is used in the entire M3 documentation, and whitespace is not treated as an element or anything similar to that.

Furthermore, there are examples on Google products and on random exemples throughout M3 guidelines where it doesn't support your idea of being unable to re-use whitespace to separate different groupings.

The whole transition to M3 puts a focus on things using whitespace constantly, without the need to explicitly state the boundaries when context clues, font and color choice are enough. In M3 there's absolutely nothing separating the Top App Bar from the body of the screen until the user scrolls, which is a very deliberate and noticible change from M1 and M2.

And despite the divider guidelines stating a full width divider can be used to separate interactive from non interactive elements, M3 considers the font change is enough to separate the top app bar from an list.

[OxygenCobalt]

You know what, google is just bad at specifying things. Nothing about the style guidelines is consistent even across google's own products. The settings menu in the phone app has a divider, but not in the settings app. The play store also has a divider in settings, but this time it's inset. There is no one way to do this. This argument could be lengthened into eternity. I'm locking and just going to stick with my interpretation since I like how it looks.