UI/UX changes

[OxygenCobalt]

This issue is a megathread for general UI/UX changes that I'm working on regarding Auxio.

Feel free to request things, but keep in mind the following:

• All rules from the Addition Guidelines apply here.
• Some things might not be feasible due to limitations with the android framework, such as:
  • Swipe gestures not from the playback menu [Navigation restrictions]
  • Swipe-to-queue [Too many conflicting touch events]

[itsmusictomyears]

Just updated to 2.0.1, very nice work!

Some suggestions (please tell me if you'd rather I open up separate requests for all of these):

• [ ] Use more swipes. For example, when you open an artist or album page, you could swipe to the right to go back to the previous page. On the 'now playing' page, you could swipe up on the album art or the playback buttons to show the queue, and swipe down again to go back to 'now playing' (I suppose the swipe down from the queue should only be activated if you're at the top of the queue, or if you swipe from the title 'Queue'). You could also add left/right swipes on the playback screen to move to the previous or next song, though I'm personally not a fan of those because accidentally triggering them is pretty frustrating when you're really into the currently playing song.
• [ ] Genre pages currently only show songs. Although you can sort them by artist, album, etc, it would be nice if you could also or alternatively display artists and/or albums. I often want to listen to a specific genre and choose a specific album or artist, but that's a bit cumbersome to do if you need to scroll through all of the individual songs. Basically, I'd like to pick 'Trip hop', then scroll to 'Massive Attack' and hit play.
• [ ] 'Add to queue' actions for artists/genres.
• [ ] On artist and album pages, the artist name or the album title is displayed below the cover art with an empty bar above the art. The name/title moves up to the empty bar when you scroll down. Maybe it could always be in the bar above the cover art? Or, alternatively, perhaps the bar could be removed when there is nothing to display, with the back button overlaid on the cover art, and then show up again when you start scrolling down?
• [ ] Would it be possible to squeeze the library tabs inside the top bar (with the menu icons)? It would save a little screen space on small devices, though I'm not sure if it would look good or work well.

[OxygenCobalt]

Use more swipes

Let me go over the feasibility of each thing here:

• Swipe-to-queue is something I am planning for 2.1.0. I held it off for 2.0.0 because I was still working out how I wanted the UI flow to work. It's extremely likely it will be like you suggested.
• The navigation component does not support swiping between detail views. This is something I'd wish google would add, but I guess the closest we'll get is the new swipe navigation gesture that's in Android 9-onwards.
• Even if I wanted to implement swipe-to-next-song I can't as the queue system makes managing the such a UI's state impossible. The swipe-up system already adds enough shiny animations.

Genre albums/artists

Fun Fact: This was actually in older versions of Auxio, albeit because of a loader quirk. I removed it in favor of songs. I could definitely do it though. Depends on how I want the UI flow to work.

Add to queue for artists/genres

I've considered this, but I think it would be more aggravating than useful with the transient queue. You would skip a song, and then you couldn't skip back to it. Let me re-consider this after I receive more queue feedback.

Toolbars with detail views

The detail UI has easily gone through the most changes out of all of Auxio. I settled on this UI because I thought it balanced information density, emphasis on the cover art, and friction-less scrolling. I'm personally happy with the detail UIs currently and I'm not looking to change it.

Smaller tab view

I could work on this. I'm also planning add the ability for the shuffle button to shrink/grow depending on the screen size so it looks natural.

Thanks for these suggestions. I'll try to work on them when I get the time.

[itsmusictomyears]

Thanks for taking the time to reply to all of my suggestions! I'm eager to see what the future holds for Auxio.

[OxygenCobalt]

Quick update: Swipe to queue is not happening. There are too many conflicting touch events to get it to work in a way that isn't horribly clunky and buggy, especially with dragging items. The most I can do is add a simple swipe gesture that results in a queue navigation, but that feels extremely inconsistent and I would rather not do that. Maybe someone else who knows more about android view black magic can do it.

[OxygenCobalt]

Auxio's tablet UI seems to be in a good place now, so I'm closing this issue. Still keeping the other suggestions in mind.

[OxygenCobalt]

I'm going to upgrade this issue to one an on-going megathread for UI work, not unlike the megathread for music loading issues.

A big change coming in Auxio 2.2.0 [not 2.1.0] is the migration from the Inter typeface to the native Roboto typeface. This cuts down the APK size by a couple hundred kilobytes, and it generally makes Auxio feel more native compared to other apps. The new typeface is also more compact, which I imagine would improve UI on smaller devices.

Before:

After:

Hopefully the transition isn't too jarring.

[OxygenCobalt]

Quick update on the previous post: I decided to keep the bold inter font, which is used on buttons, headers, labels, etc. I feel like that helps provide some flair that differentiates Auxio from other apps, similar to how google uses their own font for similar UI elements but uses the native typeface for other elements. This is also allowed by Material Design 3, which actually encourages combining a unique typeface for major UI elements with the native typeface for less important UI elements.

[foldfree]

I noticed something with the repeat and shuffle button. I am on A12 with material you. There is no visually cue if they are on are off. I think material you offer 3 accent colours so there must be something possible?

[OxygenCobalt]

Hm. I imagined that the active color would stand out more than the inactive color. Can you toggle them and then show me the other state?

[foldfree]

Quick update on the previous post: I decided to keep the bold inter font, which is used on buttons, headers, labels, etc. I feel like that helps provide some flair that differentiates Auxio from other apps, similar to how google uses their own font for similar UI elements but uses the native typeface for other elements. This is also allowed by Material Design 3, which actually encourages combining a unique typeface for major UI elements with the native typeface for less important UI elements.

I am not graphic design expert, I only had an introductory course while I was in art school but I'd consider combining Inter and Roboto a breaking of design conventions. Both are Neo-grotesque sans-serif with very subtle differences. It is discouraged to use too similar fonts as it would make it look like the subtle letters variation are more of a mistake rather than a design choice. Considering the little amount of text in the app, I'd recommend to have a single font for the design.

[OxygenCobalt]

Thanks for that advice, actually. I'm not an expert on UX at all and really just rely on a "well, it looks okay to me" mindset when working on the UI. Personally, the roboto typeface looked really uncanny when I used it for bold text, so I may as well just switch back to Inter for everything.

Plus, completely relying on native fonts would result in:

1. Total style breakages if OEMs override the font.
2. Auxio looking same-y compared to other music players.

[foldfree]

Hm. I imagined that the active color would stand out more than the inactive color. Can you toggle them and then show me the other state? I can see now with the screenshot that there is indeed a colour difference but it is too subtle to be visible in normal usage (i.e. low brightness, on the move, etc) or if the user is visually impaired.

[OxygenCobalt]

Okay, that is interesting. I'm also running Android 12, but since my theme is tinted blue the colors are far more distinct. Let me try some other wallpapers to see if I can reproduce a similar palette.

Edit: I really can't seem to reproduce it. I'll look at how the Material3 color roles should be used and see if I can pick out one that's more visually distinct from the ambient control color.

[foldfree]

Okay, that is interesting. I'm also running Android 12, but since my theme is tinted blue the colors are far more distinct. Let me try some other wallpapers to see if I can reproduce a similar palette.

Edit: I really can't seem to reproduce it. I'll look at how the Material3 color roles should be used and see if I can pick out one that's more visually distinct from the ambient control color.

I'm using solid colours for my wallpaper with darkmodelivewallpaper app to have wallpaper adapt like MacOS dynamic wallpaper. It might have broke something somewhere at some point. I tweaked a bit the colours and I have a high contrast again in the app. So maybe it's just a bug on my phone. Not a problem with the app 👍

[OxygenCobalt]

Oh. Sounds good then. I know that the Android 12 color extraction system tends to favor pastels over more distinct colors, so I would imagine there would be cases where the active color is too similar to the control color simply because of how bright it is. Hopefully Android 13 remedies that.

[OxygenCobalt]

I've actually changed my mind on the roboto migration for two reasons:

1. I want Auxio to have some visual distinction compared to other music apps, which Inter accomplishes.
2. Google doesn't even follow their own rules regarding Roboto, so it's not like a custom font is bad design.

[dhishkyaon]

having same issue as @foldfree mentioned. I think toggles need to be more darker when disabled. i just edited a screenshot for reference.

Before: After:

[OxygenCobalt]

@dhishkyaon @foldfree This issue is more widespread than I thought. The issue is that I use a darker control color to signify when a UI element has been disabled, and I don't want users to think the shuffle and repeat mode options are disabled at any point.

Something I might do is borrow the design from the new Material You navigation bars. Use the current control color when inactive, and then color the background when it's active. So, something like:

I'd imagine that this would still increase contrast to a sufficient level. Thoughts?

[dhishkyaon]

@OxygenCobalt i think one of these will look much better (1st one is best imo) -

[foldfree]

Would it be possible to set the signs to 'bold' when active? Otherwise I like the new material you buttons.

[dhishkyaon]

imo these material you icons look good only with tabs. It will not go well with the UI if we use them for shuffle & repeat toggles.

[OxygenCobalt]

i think one of these will look much better (1st one is best imo) -

@dhishkyaon Looking at your proposal, I think the dot would actually work quite nice. It would also be a bit easier to implement as it simply means tacking on a dot to the icon. I'll try both approaches and see which one I like more.

[illdeletethis]

as i"m switching away from samsung music since only their godawful redesign is compatible with my new phone, there are two sorting/appearance options that made the old versions of it good and would be great additions here:

3 (or more) wide grid for the album and genre tabs, displayng more items on screen than the list

option to sort the genre tab by song count or, if possible, duration of everything in the genre

[OxygenCobalt]

3 (or more) wide grid for the album and genre tabs, displayng more items on screen than the list

I don't see myself adding this sadly. The issue is how cards (the material design term for a grid item) have rounded corners, which would by extension force me to round album covers as well. I would prefer to keep any sort of cover art unrounded unless the user specifies that they would prefer it as such. This does not rule out such a display option in the future, but currently I'm happy with the standardized way items are shown.

option to sort the genre tab by song count or, if possible, duration of everything in the genre

Both of those could feasibly work, and not just for genres. I'll look into it.

[illdeletethis]

while i don"t like the rounded corners either, to me they"d be easy to ignore for the advantages of the grid, but i get you not wanting them at all.

and awesome

[OxygenCobalt]

Yeah, I can still see the appeal. Perhaps I can just ignore the guidelines by default and give the grid items hard corners, maybe extending the "Rounded album covers" option into a general "Round" option that actually rounds those cards. I'll take another look if other people start requesting this.

[OxygenCobalt]

I've implemented the improved indicators that we've discussed previously. However, due to technical limitations, I've had to make some compromises:

• In the app, the on/off status of shuffle/loop will be indicated by an indicator dot, as I've said before.
• Outside of the app (widgets and notifications), the on/off status of shuffle/loop will be indicated by a darker color. This is mostly because we can't customize the UIs on those views as heavily as we can in the main app without fragile workarounds.

[OxygenCobalt]

I want to get some feedback on another change I am considering. I'm considering removing the album name from the song items and just showing just the artist name. I'm doing this for two reasons:

1. The way the artist and album names are packed probably results in truncation on small screens, which I doubt is very helpful.
2. All other items in Auxio have only one specific "subject" per line, which makes the song items a bit of an outlier since it has two (the artist and the album)
3. The empty space available could be used for another UI element, such as a duration.

Here's a before and after comparison, if desired.

As it stands, I'll be pushing this change for now and will revert if there is sufficient criticism.

[dhishkyaon]

i really like it.

[OxygenCobalt]

I'll be re-closing this issue so that I can get more reach on individual changes. I'll be spinning off the next change into a general "Menu feedback" issue.

[KraXen72]

Hi, not sure if i should put this here or make a new issue. Also maybe it was already suggested. UI:

• [ ] please add swipe cover in playback screen to go back and forward (in playback). only the cover tho, not a full screen swipe. (the actual cover would move back and forth, not just a random swipe animation)
• [ ] please move the queue button down so it's easier to reach / make a side menu (like old android) but right for the queue.

UX:

• [ ] maybe considcer bottom nav instead of top nav? you can go to other screens from any detail view that way
• [ ] clicking a song in queue should play it

thanks.

[OxygenCobalt]

Hey @KraXen72, I closed this issue as I felt like it wasn't resulting in enough reach. If you want to propose a bundle of suggestions, please make a new issue.

please add swipe cover in playback screen to go back and forward (in playback). only the cover tho, not a full screen swipe. (the actual cover would move back and forth, not just a random swipe animation)

I can add this, but I will not make the cover move back and forth. This is because there is no real way for me to implement the view in a sensible manner without either sacrificing RTL support, creating annoying state issues, or dealing with insane UI flickering. This is not to say that I wouldn't add an indicator for the gesture, it just wouldn't move the cover.

please move the queue button down so it's easier to reach / make a side menu (like old android) but right for the queue.

I'm assuming you're asking about adding another row of buttons to the bottom of the view (like spotify), but I don't have a companion button to put alongside the queue button if I were to move it there. I also can't add any gesture navigation towards the queue fragment, as there are too many pre-existing touch events on the current UI. I like the way the queue looks currently and I have no plans to change it anyway.

maybe considcer bottom nav instead of top nav? you can go to other screens from any detail view that way

Not adding. There is no elegant way to cram all navigation destinations (including a future playlist addition) into a bottom navigation bar without having to drop some part of the current UI.

clicking a song in queue should play it

Not adding. Too many conflicting touch events for it to be sensible.

[KraXen72]

ok, i understand the reaasoning. but the queue is kinda useless without tapping to play no? currently it's really impractical, you have to move the song up and then skip. I can't imagine how are there too many touch targets in the queue, there's sort, remove and then swipe to hide. tapping shouldn't interfere no?

i've seen multiple music players written in kotlin pull this off

[KraXen72]

swipe to next eith some custom visualization is fine.

also, i noticed the queue is kinda wierd, when you do loop queue, it still removes from the queue and after you go through all songs it fills it up again. shouldn't it just keep the songs and indicate which one is playing?

[KraXen72]

anyway thanks for replying and i will put any further suggestions not related to these discussed above in new issues

[OxygenCobalt]

you have to move the song up and then skip. I can't imagine how are there too many touch targets in the queue, there's sort, remove and then swipe to hide. tapping shouldn't interfere no?

Oh. I was assuming that you wanted a whole new queue to be created from a song, not just for the queue to jump to a position. There might be a way to add this.

also, i noticed the queue is kinda wierd, when you do loop queue, it still removes from the queue and after you go through all songs it fills it up again. shouldn't it just keep the songs and indicate which one is playing?

The issue with this is that such a system would make it quite easy to put the queue into an invalid state unless I were to put in certain restrictions regarding how items should be moved (i.e no moving an item before the currently playing item). If I were to do that though, it would result in a much worse user experience. As a result, I decide to just show all items that are after the currently playing item, which is more sensible.

Anyway, I want to cut off the discussion from here. I'll focus on the queue playing eventually.