Fix top bar cutting off item details content

[seadowg]

Just a quick one after I noticed the top bar cutting things off on item details:

Now it's like this:

I've made this an optional feature of our TopBarLayout (the Composable formerly known as Screen), so other screens are all unaffected as they use a solid rather than a transparent top bar.

[formatBCE]

I mean, now the top bar is transparent, so it will overlap items, while we're scrolling down, without communicating it to user?

P.S. I understand UI value, bot don't we make UX worse in advantage of better UI?

[seadowg]

I mean, now the top bar is transparent, so it will overlap items, while we're scrolling down, without communicating it to user?

I don't understand. The bar still collapses and expands when scrolling down and up content respectively.

[remon1496]

I don't understand. The bar still collapses and expands when scrolling down and up content respectively.

Back- and 3dot menu will overlap items on long lists:

I think it one way it could be solved os by adding background to these buttons (like with the 'play now' button. This way it won't cut off the coverart and item details.

Tidal:

[seadowg]

Back- and 3dot menu will overlap items on long lists:

Right, that's the intention. The bit I didn't understand was "without communicating it to the user". Maybe that is all @formatBCE meant though.

I think it one way it could be solved os by adding background to these buttons (like with the 'play now' button. This way it won't cut off the coverart and item details.

I've seen that a few places. Interestingly though, it's more common on iOS. Tidal on Android for instance has a sticky transparent app bar - the back and overflow buttons always overlap the list. Another thing we could do there if the overlap feels too problematic is to extend the shade we use to protect the status bar overlap.

[remon1496]

I've seen that a few places. Interestingly though, it's more common on iOS. Tidal on Android for instance has a sticky transparent app bar - the back and overflow buttons always overlap the list. Another thing we could do there if the overlap feels too problematic is to extend the shade we use to protect the status bar overlap.

Indeed personally I don't mind the overlap, as long as it doesn't flow into the text below it without being able to clearly seperate them.

Do you have some visual examples of how they solve this on android?

[seadowg]

Do you have some visual examples of how they solve this on android?

1. Button backgrounds (like the iOS screenshot but with gradient shade rather than glass effect)
2. Gradient shade from the top
3. Bar becomes more opaque (but still partially transparent) while scrolling

I'm happy to experiment with a few options until we're all happy on this, it's just a small bit of polish as a side quest!

[remon1496]

I like where this is going! I feel like my order of preference would also be 1 > 2 > 3. :)

A bit of really nice polish.😃

[formatBCE]

I really hate this. And yes, that's what I meant ..

I feel like we're trying to make something that's not really needed here.

[remon1496]

I really hate this. And yes, that's what I meant ..

Ouch, yeah, yuck. That's ugly.

I feel like we're trying to make something that's not really needed here.

Agree it's not really needed, but the details not being cut off would be a real sweet UI improvement. Still think a button background would be good.

[formatBCE]

I don't understand. Top bar is showing, it overlaps the content - but as user scrolls down, it all is shown, nothing is cut off. And it comes to nice gradient once it's all the way to the top. Why kill the background? Those round backgrounded buttons aren't material3 way - we will break graphical language.

[seadowg]

Why kill the background?

The intermediate state where your scrolling back up and the solid bar color overlays the album art looked off to me, but honestly the more I'm playing with it as part of this discussion, the more it feels OK. I'm convinced that the trade-offs of transparency here aren't worth it - good job!

I'll close this and maybe just open another PR with the rename - I still like that.