✨ Home Screen

[Chaphasilor]

Finally had the time to work on this. Finamp will soon have an actual home screen!

This closes #612.

The home screen is based the design mockup proposed in #220 (comment).
It will be user-configurable content-wise. The two rows of buttons ("1-click play actions" - top row, and "library links" - bottom row) will be configurable, as well as the "sections" below the buttons.
1-click play actions start playing something right-away (possibly after choosing an option, like the decade to play).
Library links open a place in the library. They are not meant for linking to specific items (e.g. albums), but it's not off the table yet.
The sections will contain a dynamic list of items. The items within a section will not be explicitly user-configurable, they will always be powered by some kind of request to the server (or downloads). The sections do however support displaying collections, which could be used to "pin" specific items if desired, while integrating neatly with existing Jellyfin features and allowing to sync the content across devices.

The basic home screen already works, only thing not functional yet are the "show more"/> buttons and the "Decade Mix".
Customization is not there yet, but will most likely be added before this PR is merged.

The new navbar is used on (almost) all other screens, it already works but the navigation experience still needs improvements.

Feedback and suggestions welcome!

Screenshots:

TODOs:

• Get all buttons to work
• Show server name
• Replace the drawer with a new menu style (pop-up or bottom sheet). Currently, tapping the top bar (e.g. Finamp logo) will open the drawer. Possibly done in a follow-up PR
• Introduce some sort of caching. Content that's loaded on the home screen should stay loaded, and when clicking the "Show more" button the previously-fetched content should be re-used. Ideally it should also be reused across the entire app. Manually refreshing by dragging down should always clear the queue to avoid issues with cache invalidation. The cache should not be persisted across restarts.
• Improve navigation experience. Pages should stay loaded when navigating away. Navigation within sections (e.g. library) should be preserved when navigating away and back to it again. Tapping on the library button should return to the root of the library.
• Implement search page. Right now this just opens the library. Possibly done in a follow-up PR
• Add "surprise me" button

[lukaslindnermusic]

Wow, looks really good 😍
Thank you for your work 🙌🏻

Will there be a toggle to turn of the display of the server name?
As I and probably a lot of people only connect to one server in total, this info might be redundant or in some cases not wanted. What about adding an option to show the server name (default), replace the whole "Connected to xy" string with a custom string, or hide it?

And shouldn't it be "Track Mix" instead of "Song Mix"? ;)

All in all: It looks very nice 🙌🏻 Thank you!

[lukaslindnermusic]

What happens in Offline-Mode?
Would be good to replace the "Connected to" Text with "Offline-Mode", wouldn't it? Probably you have already planned this?

So msybe, when you don't wwnt to display the server name, you could just let it say "Connected to Server"?

[Chaphasilor]

Why would you want to hide the server name? There's no other use for this space at the moment. And yes, the text will show "Offline Mode" when that's enabled.
If privacy is a concern when showing the server name, then we could add an option to hide it. In the screenshots the ID is shown, because the server name isn't being fetched yet...

And the "Song Mix" thing was because I simply implemented the design mockup. It's a hard-coded string at the moment, so it will be replaced with the proper track-based name of course :)

[lukaslindnermusic]

Why would you want to hide the server name? [...] If privacy is a concern when showing the server name, then we could add an option to hide it.

Don't get me wrong 😊 I think its good to have it there and I personally will keep the server name there.
But I think the option might be good just for personal preferences. Maybe you prefer a cleaner look when you have a longer server name that does not get displayed in full, which might not look that good (and given that its the first thing you would see when opening the app).
Or maybe there are use-cases where you intentionally have more "technical" server names (idk, "rack_1_jellyfin_b" or something, not formatted for direct displayal) in a more complex environment with multiple servers etc., but you want to use Finamp just for one library on one specific server.
Or the privacy aspect.
Or maybe, you would like to add some custom greeting or whatever (but given that that space is dedicated to connection status and also displays offline mode, I think its best to not give the option to display custom text there).
It's just brainstorming, just a suggestion for another customizable setting. 😊

[Chaphasilor]

Okay. If I receive that feedback by more people, I'll add it. Your reasons sound compelling. But right now it doesn't have priority, and is easy to add later on :D

[e-v-o-l-v-e]

Hey !

Firstly : huge thanks for your work, this app is amazing, and your investment in it is really cool.

second : a few questions

• will the current way of "doing things" still be available ? like in the library will I be able to swipe to go from the track pages to the playlit page etc ? or will the "swipe to ad to queue" take over ? (I like both haha)
• will we still be able to chose our own first tab ? I'm a real fan of just opening the app, seeing random tracks and choosing one to start a mix, or just starting random play

thirdly : I agree with Lukas on the server name, even though I lean more towards hiding it

fourthly : thank you again ! I intend to learn and try to help as soon as possible ! this app is really cool and I would be proud to participate

(not English native, sorry if I made some stupid mistakes)

[Chaphasilor]

Thanks!

1. For now, the "library" tab will contain everything you had before the home screen. It won't stay like this forever though, but we haven't really decided how the library should be structured.
2. I guess we could have a "random tracks" section on the home screen for that? And there's a "track mix" button as well, which will shuffle all tracks :)
3. Noted. Definitely won't be happening initially, maybe later on :)
4. Let me know if you need any help <3 You can also always ask for good beginner issues, and I'm sure we'll find something that suits you!

[e-v-o-l-v-e]

1. nice !
2. that would be cool ! and track mix is also great, so many big software don't even have this - i find - basic feature.
3. nice 2 !
4. yay, I actually already tried taking the shuffle button to notification, Shuffle Button To Notification #291 , but i was completely overwhelmed by all the files haha, my biggest project as of now is a java program with no more than 10 files and i already had some trouble managing that 😂.
   for example, i found things related to the shuffle :

rg ShuffleOrder -.
lib/services/queue_service.dart
75:  late final ShuffleOrder _shuffleOrder;

'
but i was not able to find where the heck does ShuffleOrder come from, i suppose it is imported at some point, but i didn't find it in the repo 🤷
and I'm not even talking about the notification screen, i have absolutely no idea where that is haha, i think i need to do a little dart/flutter project on my own to really grasp the concepts before being able to participate without messing everything up haha

[Chaphasilor]

@e-v-o-l-v-e so for the shuffle button all that's needed is to uncomment this section here (and the lines below):

finamp/lib/services/music_player_background_task.dart

Line 1112 in 3c3e4c6

//!!! Android Auto adds a shuffle toggle button automatically, adding it here would result in a duplicate button

Just do that and open a PR? 😁

[Komodo5197]

I'm firmly against the navigation changes introduced here. For one, the usage of multiple floating bottom bars just seems kind of silly? I also don't like the packaging of all the apps current main screens into a single subcategory. I have basically no use case for either the home and search screen, so this is just hiding away everything I actually care about, and adding a constantly present menu bar pointing to them to boot. This bar is also a bit irritating in places like the album screen, which already feel a bit cramped on smaller screen sizes. My preference would probably be something closer to just adding the home and search screens to something closer to the existing tab bar?

Anyway, a couple small oddities I noticed:

• Switching to library tabs via the home screen buttons versus the bottom bar behaved inconsistently regarding going back. What's the end goal here? Should the back button be able to reverse these navigations? Also, it doesn't update the navbar state to library.
• You've made the side bar open by clicking the logo, but I feel that isn't really that intuitive? How would you ever know that it exists? Also, showing the name finamp doesn't seem like a great use of screen space? There has to be something actually useful to say there instead of the name/logo of the app that you just clicked on, right?
• Would the new navbar allow swiping between tabs? How would that work with the library?
• You've implemented the navbar in a way that messes up the background by making the now playing bar a bottom sheet, which draws the full bottom sheet shaped background. You need to package both widgets together in the bottomNavigationBar or something. Also, the navbar is too short to show its text for me.

[Chaphasilor]

This is still a draft for a reason :)

1. I'm aware that the navbar doesn't behave correctly yet.
2. The drawer is supposed to be replaced with a new menu (pop-over or bottom sheet). While the drawer works, it's outdated, doesn't work well with gesture-based navigation, and is an oddity on iOS.
3. Space usage is something we could discuss for sure. With Prefer Local Address when in Home Network  #1162 merged we could show the current URL there, maybe in addition to the server name. Or we only show the URL. Or just the URL type as "Local" or "Remote"? The space could also be used for the notification stuff mentioned in Improve Notification System #1204
4. Swipe gestures for switching between home, search, and library wasn't something I planned. For now swiping between library tabs should still work though. But the library section eventually needs to be properly redesigned too, we can't keep cramming in features which it was never designed for. And I don't think we want to be stuck with the current functionality forever either.
5. Hmm, I would've really preferred for the now playing bar to not be a pseudo-navigation bar any longer, even without having an actual navigation bar. Couldn't we wrap it into a ConstrainedBox or something similar to force the correct height?
6. I keep fighting with default paddings, font styles, and margins in Flutter. Unstyled components would really be nice to have. I'll try to fix it.

I'm very sorry to hear that you hate the proposed changes. I do have to say that a lot of users have expressed their excitement about a "proper" home screen in the recent weeks, so I don't think we should ditch it. Selecting a default tab wouldn't be a problem, but the additional nav bar using up screen estate is (for people like you who are focused on the library at least).
I think we could shrink both bars further in height without too much issues, would that (and the default screen) work for you? Shrinking could involve making the navbar stick to the bottom instead of being floating.

The search overhaul is long overdue, having to switch between tabs to find something is strange and inefficient. And the way the search bar hides other controls also isn't ideal. A separate screen seems to be how most other apps do it. If we find a way to get rid of the navbar we could theoretically move the search button to the top, but with the navbar we have enough space to include it there.
Having search separate also frees up space on the music screen AppBar and simplifies the logic in both music_screen and music_screen_tab_view. We don't even need to implement a lot of new code for the search, since all the logic is already implemented for Android Auto.

About the home screen, are there any sections or other functionality that would make the home screen more worth-while to you? It's meant as a quick access to things you listen to frequently, and not as a burden or inconvenience. I'd like to know how you usually start playing music in Finamp, and how you find/select it!

[Komodo5197]

I do understand the desire for the home and search pages, even though I don't actually care about them myself. The existing per-tab search definitely sounds clunky, and I have seen quite a few messages across this PR and the various issues asking for a home screen. This PR includes both the addition of the home and search screens as new ways to access your music, and also a initial step towards an app navigation overhaul, and its the latter that I'm mostly concerned about. I think I basically have three concerns - the demotion of the music screen, the space usage and mental model of the navbar, and the future of the sidebar.

With the current app design, on startup you are immediately presented with five ways to browse your music - by album, by genre, and the other main tabs - all of which are immediately available and can be freely reordered or even hidden. This PR presents two new ways to browse - via the new centralized search, which elevates search from a mere filter of the tabs to its own independent browsing method, and via the home screen. But then these two methods are put directly onto the navbar, which is more omnipresent than any other UI element we have, while every existing browsing method is crammed into the library section, promoting the home screen as the main way to browse with all others secondary. I strongly disagree with this, and feel that the home and search screens should be treated as equal to the existing tabs. This has two aspects, navigation accessibility and control availability. For navigation accessibility, the most straightforward way to implement this would be to have all seven browsing methods availible on a single bar. If this is considered unwieldy and you want something more like your navbar implementation that never allows scrolling, one idea would be to extend the current tab customizability so that the navbar has two or three 'highlighted' sections of the user's choosing, which would default to home/search but could be changed to any of the existing tabs, and then the library section would be an overflow section for all the remaining browsing methods, potentially including the home screen or search if the customization dictates. By control accessibility, I basically mean that I'm concerned about the home screen gaining important control functionality unrelated to its use as a browsing hub which would be absent from the existing tabs and necessitate switching to that screen for non-browsing reasons.

I'm also not really that enthused about the navbar from a space usage perspective. This would be alleviated if the more advanced customization scheme I mentioned above was implemented, but I really do not want to be dealing with two separate navigation bars taking up space on my most used screen in the app. We already have the fairly large now playing bar taking up space in addition to the music-screen specific controls and navigation. I have a similar space concern about the album screen and its like. On a multi-disc album, adding another bar would bring me down to eight visible tracks, which is certainly usable but its still low enough that every additional one counts. On my old phone, losing a song to the navbar would have taken 20% of the available space and brought me down to four visible tracks. Showing the navbar on screens like this also brings up an additional concern, which is how it interacts with the stack page route model. If I've drilled down from the library to a genre to an album, and then I hit home on the navbar, what happens to this stack? Is it dumped, or preserved in the other tab, or is the home screen now on top of it? All of these options seem strange, and would cause me to lean towards only showing the navbar on the main browsing screens to avoid mixing the tab and stack models like this. Shrinking these bars down would at least partly help with these space concerns, although I'm not sure how far we can really shrink them and still keep everything readable and clickable. Making them non-floating would reduce some padding, and also avoid the fact that I think stacked floating bottom bars just looks a bit dumb. I'm already not a fan of the way we have the floating instant mix button over the floating now playing bar, and if that stays then we would end up with three floating elements, which is absurd.

My final big concern is with whatever is planned with the sidebar design. I don't think I'm strictly opposed to replacing it with an equivalent bottom sheet or pop-over, although with the popover option I'm a bit concerned about the border padding reducing usable UI space on small screens. I'm not entirely sure what you mean by sidebars being outdated, and I don't know how it might be interfering with gesture navigation, but whatever. A large part of my concern in this area is functionality getting removed from the sidebar, which is easily accessible from all the music screen tabs, and being consigned to the home screen instead, or other less accessible locations. All the functionality should remain quickly accessible from the music screen tabs, and if you're messing with the access maybe even some of the other screens, if that can be fit in. Also, as I mentioned before the way you access it on the homescreen does not seem intuitive as all. I don't think I ever would have tried clicking it if I hadn't seen its functionality in your description, and even if it looked more button-like I wouldn't have guessed its functionality. It would also be nice if we kept a gesture-based way of accessing the new sidebar, because the upper left corner is just out of reach on my new phone and there's a lot of important functionality in there.

Other minor points:

• The ability to control the apps default screen is a key piece of functionality that does ease a few things and is vital to keep.
• With the bottom bar widget combining, I'm looking at the way that the scaffold seems to be adding a background color in the shape of a standard bottom sheet when you have the now playing bar up, blocking the visibility of content through the gaps beside and below the nav bar. I don't know how avoidable this is when the scaffold thinks it has a bottom sheet, but I haven't messed with it. What were you planing to do with the now playing bar to make it not a pseudo-navigation bar?
• We probably should be leveraging the existing theming controls more. There's a bunch inheritable styles that control colors, sizes, fonts, and the like automatically, and our widgets generally aren't that specialized so we could probably eliminate a lot of widget specifications by just setting these correctly. But I haven't dug into this, because I don't actually care very much about most of these small UI details. I focus on layout and things not flickering or otherwise looking buggy.
• You mentioned redesigning the music screen - what are your current plans for that?
• When browsing, I generally just select an album or playlist and shuffle the whole thing. Then I choose another one. I'm not sure there's much you can add to the home screen that would really appeal to me. One of the things I like about the the album screen is the density. In text-free grid view, I can fit twenty four easily readable albums on screen at once, even with the now playing bar up. It also feels very clean, or maybe minimalist, with just wall-to-wall album covers and nothing extra. The home screen, with all its different subsections, is fundamentally both significantly less dense and notably messier.

[lukaslindnermusic]

I think, Komodo mentioned a few valid points there. While I still like the idea of having a home screen and I like the way you structured the screen itself, the navigation and type of integration in the screen flow bugs me a little bit as well... especially the bottom navbar with Home, Search and Library, that takes a lot of space that most of the time is unused and just blocking the view.

Also, I don't know why the side drawer is an oddity in iOS. What's the problem with it? 🤔

And the way the search bar hides other controls also isn't ideal.

When I'm searching, I dont care about the sort order, I want the results that match most, for quick access. Maybe the only thing that would be nice to have access to is the favorite filter...
So I don't think that this is too dramatic. But I think the search button can stay at the place where it is, but instead of replacing the header on the MusicScreen, just open a popover which lets you type and maybe shows recent searches or something in a list underneath the input field? And then it can take you to a separate screen that combines all item-types in the result set. Or, the search button directly opens that screen with the input active, and recent searches or suggestions directly underneath the input as long as you're not typing anything?

4. But the library section eventually needs to be properly redesigned too, we can't keep cramming in features which it was never designed for. And I don't think we want to be stuck with the current functionality forever either.

Sure, there are things that are not ideal, but in general: What are the features that it was never designed for? I actually like it, that you can very quickly swipe between item types and have everything at your fingertips. Sure, maybe we could redesign the styles a little bit, and maybe update the sortBy at some point (I don't know how you can sort genres or playlists by AlbumArtist or PremiereDate :P And what about that Community and Critic Rating? Isn't that a film/series library thing? Is actually someone using this for music?), but in general, I like the structure.

Suggestion:
To solve both the space problem with the bottom navbar as well as the hid-away library tabs, why not make the Home Screen the first tab? and it should always be the first in the list, no matter how you order the other tabs. the homescreen tab gets appended prepended. And on Appstart, it opens Home right away. However, you should be able to define a different starting-tab if you want.
Then, on the Home-Tab, you are replacing the MusicScreenTabView embed in the body with the HomeScreen Content.
Also, you are replacing the space above the tab bar with a custom header (maybe, when switching, there could be a fade out animation, it could slide away to the left with the content or another smooth way to switch from the Homescreen header to the default one... maybe make a different background-color for the homescreen header and then let it slide upwards (or left) out of the screen, revealing the default one?).
And as said, search could stay where it is, but opens a dedicated search screen or search popover.

What do you think? 😊
Or were you refering to stuff like this with "features which it [the Music Screen] was never designed for"?

[lukaslindnermusic]

In the Mockup, I added all of the sidedrawer options (except logs, you don't need that unless you have a bug) on the top right instead of having the drawer button on the left.
But of course, you could still have the button on the left, move over the Servername and Connection Status, and then have space on the right for eventually other buttons (in addition to search, which I think should definitely stay there).

Regarding the ServerName: When you have multiple libraries, I think it makes sense to default to displaying the current library name instead (or was your Home Screen concept planning with a screen that combines all libs?).
When you only have one lib, I think it could default to the server name. But you should be able in both cases to manually use the other option.
The Connection status can become blue for offline mode. yellow for trying to connect.
It could also specify (Public) or (Local) after "Connected" if different adresses are defined.

[lukaslindnermusic]

Something like that:

[lukaslindnermusic]

Regarding the "Listen Again": Unfortunately, SortBy.datePlayed seems not to work on items other than tracks -
at least for me. I'm currently doing some bug fixes and while doing that, I thought it might be a good idea to include datePlayed as a sort order on the MusicScreen as well. for albums, I get the same items no matter the sortOrder.

We could still include that section on the HomeScreen but with tracks instead of albums, or we could load limit x tracks but then extract the albums and only use the latest 3 to display. However, we don't know how big limit x has to be in order to really get at least 3 albums, because there could be an album with 20-30 tracks or more, or 5 albums with only 5 tracks or something like that.

[lukaslindnermusic]

Two more ideas.

Idea A)
Just put "Home" and "Library" in the side-drawer and make the library-selection a dropdown of some sort.
Then, users could decide if on app start, Home or Library should get opened.
Can look like this:

Idea B)
Just add a big "My Library" Button at the top of the Home Screen, and add a setting "Enable Home Screen".
Then, on the splashscreen, when homescreen is enabled, we route to the home screen, otherwise directly to the MusicScreen.
When the Home Screen is enabled and you tap on "My Library", the sidedrawer button on the top left becomes a back button (similar as we use it for genre-Filtered Lists already.

[felix920506]

I don't think a dropdown to select libraries works from a UI/UX perspective . Many people likely have their music libraries simply named "music", and a dropdown in a music player app that simply says "music" could mean literally anything. I prefer the current design on the redesign branch over the dropdown

[lukaslindnermusic]

I don't think a dropdown to select libraries works from a UI/UX perspective . Many people likely have their music libraries simply named "music", and a dropdown in a music player app that simply says "music" could mean literally anything. I prefer the current design on the redesign branch over the dropdown

The Library-Selection-Dropdown is actually completely irrelevant to my idea. It was just a suggestion to have some more space in the drawer and split the functions (because the other menu options are not a selection but navigation to a Screen). We can also keep the current library selection there and make the side-drawer-menu scrollable, or find a different place for the library selection that is as accessible as the current one. We could also not display the current Library Name there but call it Select Library. Or we make it a button right on the right side to the "Library" menu entry. Or put it somewhere completely different. All options would be on the table.

The important part of that idea is to put Home and Library there, because (as pointed out in previous messages on this thread) a bottom sheet styled menu (that's always present) for navigating between Home, Library and Search is a bad idea.
Putting those two options there would keep the Screen-hierarchy in tact, because other screens that are on the same level as the Music Screen (like Settings, Downloads etc.) are also accessed via that menu.

[Chaphasilor]

As you can probably tell, I've been procrastinating taking another look at this issue for a while now. But now that some time has passed and I'm not as attached to the proposed design any more, it's about time to get on with this.

Thanks for all your honest feedback and suggestions. I was honestly a bit scared when I saw your reply @Komodo5197 - so long that it didn't fully fit on my laptop's screen without scrolling. But of course, it was (as always!) well thought-out and sensible, and I'll try to address it below.

The initial idea for the revised navigation stemmed, as so many other ideas, from other popular music streaming apps. Those usually divide navigation in some kind of browse view (usually a home screen) and a library view. Examples for this include Spotify, YouTube Music, Deezer, and even Jellyfin clients like Jellyfin Web/Android or Symfonium.
However, as you've correctly pointed out, in the case of personal music streaming where you only have and always browse your library (be that divided into multiple virtual libraries or not), the home screen is just another view for browsing that library. If we treat tracks as atomic units and "leaf nodes", then their ancestors are albums, followed by artists, followed by virtual (Jellyfin) libraries. Genres and playlists are alternative ancestors for albums and tracks, respectively. The home screen in this case would be yet another ancestor - but in this case for all other item types. It tries to support multiple item types by adding some kind of structure that offers alternative grouping and ordering for items.
But that's enough esoteric theory...

What I'm trying to say is you're right, there's far less need for a home screen for personal music streaming. There's no new music to discover, so "feed" of new releases or posts that you need to catch up with. If you've bought the music, you're already aware of it.
The home screen does have some semantic differences though: It can present different item types at the same level, akin to what the new album and genre screens already do, just on a larger scale. It's, in a way, both opinionated (curated sections that may or may not interest you) and not opinionated (it doesn't assume which item type you prefer to browse. maybe you don't have strict preferences anyway?) at the same time. This makes it, in theory and if properly customizable, a good default screen. Which of course doesn't mean that this default can't be changed. It was always the plan to support choosing the existing tab view (music_screen.dart) as the default screen, I just didn't get to that yet for the implementation.

But let's be more concrete:
As pointed out, there is probably no need to fully separate the home screen from the existing library tabs, especially since it's just another view of the same library. I was never a fan of the tab bar myself, with how it overflows and requires horizontal scrolling by default, but there are many users who really like it and I admit that it does offer some unique and practical functionality. Maybe there's a way to make the tab bar more modern and compact (these two are often at odds with each other), while re-distributing the AppBar and drawer contents in a sensible way. The mockups by @lukaslindnermusic look promising, and I'm sure we can improve upon that further.
I'm fine with getting rid of the navbar. Regarding navigation, the plan was to keep the navigation stack between the navbar locations (e.g. you'll stay in the current album you browsed to on the library tab after switching to home and back), but a second tap on the navbar location when it's already active (tap library while already on the library tab) would reset the stack to the root of the view. That's how most apps handle this from what I've seen. If we don't use a navbar then this becomes mostly irrelevant though.
Regarding search, I don't have any strong feelings about how it's implemented. It could be a separate screen or a bottom sheet, it can have recent searches or suggestions. But one thing that irks me is that the current "search" is just a filter. You need to know where to search, and you need to know exactly how it's called (in part). It doesn't really help you find something, it's more of a tool for faster navigation. That's fine, but a proper search could be so much more. It could be fuzzy, allowing you to misspell things but still find them. It could search by metadata like lyrics (though a plugin like JellySearch). It could search for occurrences, showing you in which playlists a track is present. It already powers Android Auto's voice commands, which are arguably not a filter. Most of this is not feasible with a tab-specific "search". But I think we're all agreeing here anyway.
The home screen also shouldn't hide away controls from other screens. While I think showing more detailed status indicators there would be fine (those aren't needed anyway), having a way to quickly get around the app from anywhere is definitely a good feature to keep. I'm not particularly certain that a side drawer is a good way to deal with this, but in principle I want to keep things accessible. I'm actually quite annoyed that I can't quickly get to the settings from anywhere, but I'm not yet sure if that problem can be solved in a sensible way. Moving more controls into some kind of app bar could be one way to approach this issue, reserving the menu (as a drawer or otherwise) as an advanced panel for rarely-used functionality such as viewing logs or viewing server and app information. We could also duplicate certain functionality in the menu, so that things can be discovered more easily or properly labeled even if we don't always have the space to show a full label. The menu (or rather, a menu) could also be a way to expose functionality that is by default shown or accessible via the home screen in other locations. Instead of cramming the same buttons into every part of the interface, we could have a universal way to open this menu, sacrificing a single tap for improved accessibility.
The side bar / drawer is mainly outdated in it's appearance. The version we use is the design from 2014, and is just an ineffective use of space as the pop-over solution would be. It likely wasn't designed to be scrollable, but we've added so many items to it at this point that it often does end up overflowing. The issue with gesture navigation is that the swipe-to-open gesture doesn't work on modern phones anymore, since that gesture is now used by Android to go back, leaving only dedicated buttons to open it, which removes the benefit of it being a drawer. I've since learned that drawers to also exist on iOS, so that point seems to be moot.
Regarding density, I see no reason why the density of the home screen couldn't be configured with the rest of the app. We should be using the same grid items on the home screen and music screen anyway.
About the changes to the library / music screen: Some advanced features like additional filters (not just favorite), sorting and multi-select, playback controls (to get rid of the floating shuffle/mix button), more info about the tabs (item count, duration, other things shown by Jellyfin Web), enabling swipe gestures for individual items, downloading entire views (playlists, favorites, latest albums), etc. simply don't work on the current tab view. You're rightly concerned about losing display space for the actual media, that's why I was trying to re-think how the library views work, to add more capabilities while still keeping things usable. That's probably even more controversial than the home screen though, so it might be out of scope for the entire redesign for now. I'm also not trying to make it harder to switch between different tabs/views, but finding a solution that enables both doesn't seem trivial.

Regarding selecting items for playback - do you have any heuristic for how you decide what to play? What's your preferred sort order? Do you use the favorite filter? Or is your library small enough to be browsable in its entirely quickly enough?

I'll try to brainstorm a few more ideas this weekend. Thanks for the suggestions (from everyone)!

[lukaslindnermusic]

As you can probably tell, I've been procrastinating taking another look at this issue for a while now.

Good that you are back on it now <3

I was honestly a bit scared when I saw your reply @ Komodo5197

Understandable :P

[...] and even Jellyfin clients like Jellyfin Web/Android or Symfonium.

I know that you're now already convinced that that bottom menu is bad, but just as a side-note to add my personal opinion on the Jellyfin Web/Mobile thing as it triggers me since I use the app :P
Honest opinion: I don't know if this is the same to the Android app, but the Jellyfin App on iOS has such a bottom menu as well, and all it has available is "Home" and "Settings". "Home" basically is everything. It just feels like an iFrame to the normal Jellyfin Web. And "Settings"... well, you only need it for the connection, which of course is already set up once it works, and a few Playback and Appearance settings that you only need to set up once, maybe not even once. Still, the menu with "Home" and "Settings" is always there and takes up space... it is absolutely TERRIBLE design!

But let's be more concrete: As pointed out, there is probably no need to fully separate the home screen from the existing library tabs, especially since it's just another view of the same library. I was never a fan of the tab bar myself, with how it overflows and requires horizontal scrolling by default, but there are many users who really like it and I admit that it does offer some unique and practical functionality. Maybe there's a way to make the tab bar more modern and compact (these two are often at odds with each other), while re-distributing the AppBar and drawer contents in a sensible way. The mockups by @ lukaslindnermusic look promising, and I'm sure we can improve upon that further.

Nice 😊
Suggestion:
You said later that you don't like the side-drawer, so let's just assume for now the home screen becomes the first tab.
I think, one thing that we could do is to move the sorting and filtering options from the top right to another place. (I think you suggested some things there already?)
Then, the search icon could always stay on the top right (of the Home/Music Screen) and open a dedicated search screen or popover.
In addition to that, we can add icons for Downloads, Playback History and Library Selection. These four options stay there on all tabs and the home screen.
"Library Selection" can be its own popover then. (I found it always odd how it currently is part of the side-drawer menu, as it semantically does something different to the rest in the side-drawer.)
On the left side, I suggest we do what I suggested in the first two mockups... library name (or server name), and in a second row the current connection status.
But we can make this clickable (it should also be visual clear that you can click it), which opens the menu that previously was the side-drawer, but it doesn't have to be a side-drawer now... (just as you suggested later in your reply). it can be just a normal screen with additional options such as "restore now playing", "logs" and "settings". and of course the Online/Offline settings can go there.

I'm actually quite annoyed that I can't quickly get to the settings from anywhere, but I'm not yet sure if that problem can be solved in a sensible way. Moving more controls into some kind of app bar could be one way to approach this issue, reserving the menu (as a drawer or otherwise) as an advanced panel for rarely-used functionality [...]. We could also duplicate certain functionality in the menu [...]. The menu (or rather, a menu) could also be a way to expose functionality that is by default shown or accessible via the home screen in other locations.

I personally don't have to go to the settings that regularly that I would miss that option when I'm "down a stack" aka. in an album via Artist Screen or something.
We of course can argue if maybe - on the Music/Home Screen - instead of Playback History, there should be an icon for Settings in the App Bar on the top right. But I like your idea. I think as well, maybe it's a good idea to duplicate these options in the side-drawer-replacement-menu.
Or maaayyyybeee, we could have the menu containing all these options:
(Online/Offline Switch)

• Search
• Downloads
• Playback History
• Restore Now Playing
• Logs
• Settings

And then, we have 4 slots on the top right of the app Bar, and you can customize these up to 4 buttons yourself, from the options of the menu. So if you only care about search and Downloads, you can only display those two.

And when you are on an Artist Screen or something, we could add a shortcut button to open the entire menu, if thats important.

Regarding selecting items for playback - do you have any heuristic for how you decide what to play? What's your preferred sort order? Do you use the favorite filter? Or is your library small enough to be browsable in its entirely quickly enough?

My personal listening habits / decisions:

Most of the time:
Browse by Genre (alphabetical) -> Shuffle Genre | Browse Albums of Genre | Shuffle-Play only favorited tracks of that genre

Sometimes:
Browse/Search by Artist (normally sorted random by Album Artist) -> Play specific album of that artist
Albums (normally sorted with latest additions first) -> Play latest additions
Shuffle-Play a specific playlist (Playlist Tab sorted alphabetical)

I rarely use the "Tracks" Tab. And the favorite filter I only use when I play favorited tracks of a genre.

My Curated Item Sections on Genres are:
Random Albums
Favorited Artists (fallback random)
Favorited Tracks (fallback Random)

Artist Top Tracks:
Favorites (fallback Random), with Recently Added next to it.

[Chaphasilor]

TODO:

• Show connection indicator (icon/dot)
• Show offline mode indicator (gray Finamp icon) [requires Dynamic Accent Color & Colored Monochrome In-App-Icon #1419]
• Show current library
• Show app name in drawer (e.g. "Finamp Debug")
• [-] Implement sort bar on tab view (with bottom sheets)
• Show feedback when trying to search on home screen (for now)
• Implement "Instant Play" actions
• Implement (basic) home screen customization
  • Add section name setting
  • Add new settings page
  • allow adding new sections
  • allow picking item type per section
    • implement picking item (e.g., collection) from list
      • use plain DropdownMenu for that (supports searching/filtering available options, just fetch all collections and add them as items)
  • allow picking sort order and direction per section
  • allow reordering sections
  • allow having separate home screens per library? or combining content from multiple libraries on the home screen (although that probably won't work with Finamp's reliance on "currentView")?
• Rework "Show All" screen, re-use music screen like on genre screen?
• Adjust section spacing
• Fix skeleton loader?
• Consolidate fetching server and user info
• Fix overflow when searching
• Fix clear text button (should clear first, then close, maybe changing the icon)
• Fix contrast on tabs text

Optional:

• Add sync/download indicator
• Add "surprise me" button