Quick Queue Access / Maintain Library Position

[Toucan Stubs]

I didn't know this project was being worked on to this degree, so I'm just now jumping in. Along with Winamp, GMMP has been my core player for years. I've looked through Trello and have explored the app since the 3.0 update, so I hope I'm not touching on topics that have already been covered.

One of the most important aspects of GMMP for me has always been quick access to the queue, and jumping back and forth between the queue and where I am in the library, without losing place.

Currently, the queue is in the nav drawer by default, and can be customized to open from Now Playing and as a library tab. When exploring the library, you can add to the queue. However, to see the queue, you either have to back out to the top-level of the library, losing your place, or you have to click on the Now Playing access bar on the bottom, click on a customized queue button, and then press the phone's back button until returned to the library.

I'd really like quick access to the queue, and preferably the nav drawer, wherever I am in the app, and keep my place and scroll position in the library.

Additionally, when scrolling down an artist's albums, selecting one, and then navigating back to the album list, it'd be great if the half-screen artist art didn't reappear full-size.

Hopefully that all makes sense. This may be 3-4 feature requests, but unless requested, I'm trying not to solution it.

Thanks for all the great work!

[GoneMAD]

so your best bet is to use the split view (advanced settings -> split view). This will keep the side navigation and now playing always visible which would let you jump back to the queue from a artist/album/etc detail view, then press the back button to go back to your detail screen. That "cool" feature in 2.x of being able to dig down into selections within a tab was an abomination code wise which is why 3.0 was designed to have every view be a standalone view. This allows things like split view or adding a view as a tab to be very little work since its just placing that standalone view into another "container".

Thinking about what i could add to make this easier.. the way 3.0 is built doesnt really allow access to the side navigation in the detail views.. however technically the mini player does support up to 3 buttons behind the scenes that just isnt configurable yet. I think your best bet would be a jump to queue button right on the mini player. Here is a super old screen from pre-alpha with the multiple buttons 1.bp.blogspot.com/-tmfbdqio7j0/WXzhLkvRq9I/AAAAAAAAFBw/wE6FMDgONuwJh70w-Qasvumg0DKdRq_ZQCEwYBhgL/s1600/device-2017-07-29-151441.png

Another capability that was in my original 3.0 plan but never materialized was another drawer on the right that basically had a list of recently visited locations to allow you to quickly navigate to it (along with maybe some other quick actions). I honestly forgot about this idea until reading this post.


"Additionally, when scrolling down an artist's albums, selecting one, and then navigating back to the album list, it'd be great if the half-screen artist art didn't reappear full-size."

I'd have to see if there is some code in there that is resetting that positioning because pressing the back button should just swap back to the previous view in its old state. you can also disable the art work on the detail views from the customize menu.

As always 2.x will always be available to go back to if 3.0 doesnt meet your needs: gonemadmusicplayer.blogspot.com/p/downloads.html

[Toucan Stubs]

Thanks for the detailed reply. I hope you're hanging in there after such a big release.

After the launch, I switched back and forth between 2.x and 3.0 a few times, but I started to get interested in the vision and potential I was seeing in 3.0, so I decided to give it a shot and see if I could help with feedback.

I'm understanding the design and limitations better now, and I've been browsing the Material Design specs. I'm finding the Material design restrictions a bit challenging.

For the Queue, given the current state, it seems like the "better" short-term solution would be adding a button to the Mini Player, though it's clearly out of place.

Long-term, I think keeping the Queue accessible, as a top-level destination, would be ideal - something similar to or alongside the Mini Player / Now Playing shortcut.

There should be persistent access to the Queue because it's constructed in all levels of the library, but is independent of navigation and therefore should not reset or alter it. It's also the active playlist processed by Now Playing, and files can be played while the Queue can be edited independently.

This seemed to be pretty core to GMMP's identity, and I'm understanding more why things need to be redesigned for new features and maintainability, but assuming it's doable, aside from technical challenges, is this aligned or compatible with the goals for GMMP 3?

[GoneMAD]

I"m open for ideas other than what i've already suggested. There is not going to be any significant redesign tho. Im a hobby android developer and im quite burnt out from the last 4 years of redesigning the app

[Toucan Stubs]

Gotcha. I fully understand that and I've been there myself. I wasn't sure if you were the only developer; It's quite an accomplishment. I've used GMMP extensively for several years, and I wish I could have offered support had I known about the beta testing.

I was presuming GMMP was re-written and 3.0 was launched to facilitate continued development.
So regarding other ideas, I was hoping to run a couple questions by you first, if you're willing.


As a note, I understand that Material design components and features were being introduced after you already began rewriting GMMP, and some could require substantial effort to implement.

However, I was curious if you considered integrating the Bottom Sheets component? material.io/components/sheets-bottom

I suspect you have, as the relevance is pretty obvious. GMMP 3's mini player and upwards animation for the full screen player certainly resembles the design, though the Bottom Sheet would allow the mini player to expand and collapse the full screen controller without creating a view that interferes with library navigation.

But it seems like it would work especially well for the Queue. On the page, there's even an example of a mini player that expands to display the song queue, and is always displayed when browsing the library without interfering with navigation.

So yeah, I was just curious to get your feedback on that. I have ideas for how it could work well with GMMP, but it was presuming continued development.

[GoneMAD]

Feb 4, 2021 7:54:02 GMT -5 Toucan Stubs said:

Gotcha. I fully understand that and I've been there myself. I wasn't sure if you were the only developer; It's quite an accomplishment. I've used GMMP extensively for several years, and I wish I could have offered support had I known about the beta testing.

I was presuming GMMP was re-written and 3.0 was launched to facilitate continued development.
So regarding other ideas, I was hoping to run a couple questions by you first, if you're willing.


As a note, I understand that Material design components and features were being introduced after you already began rewriting GMMP, and some could require substantial effort to implement.

However, I was curious if you considered integrating the Bottom Sheets component? material.io/components/sheets-bottom

I suspect you have, as the relevance is pretty obvious. GMMP 3's mini player and upwards animation for the full screen player certainly resembles the design, though the Bottom Sheet would allow the mini player to expand and collapse the full screen controller without creating a view that interferes with library navigation.

But it seems like it would work especially well for the Queue. On the page, there's even an example of a mini player that expands to display the song queue, and is always displayed when browsing the library without interfering with navigation.

So yeah, I was just curious to get your feedback on that. I have ideas for how it could work well with GMMP, but it was presuming continued development.

yea.. i had thought i had mentioned bottom sheets but i must have removed it while typing up my responses. I plan on having a navigation mode that uses that instead of the side drawer as the main navigation. I built 3.0 very modular and in a way that i can rapidly build new views and a reuse existing behaviors/code really easily to allow for quickly adding new capabilities.. as that capability falls under the same paradigm. Every view is standalone and the current UI actually will nest a bunch of views together to create the current look.

Example.. i have the base views that only hold the content.. for example the artist list and the album list. There is also a mini player view which contains the toolbar at the top and the mini player at the bottom. It allows me to nest a base view inside there and now we could get a standalone view with an artist list, toolbar/menu at the top, and mini player at the bottom. Another example would be the library view.. which is basically just the toolbar/miniplayer/tabs. The tab content is just one of those base views mentioned before. Anyway this is how some of the standalone views on the side navigation drawer can easily be placed as library tabs with basically a single line of code.

The folder and now playing happen to be one of the first few views created before i started modularizing things.. so they need some refactoring before i can add them as tabs

ANYWAY.. my point being that bottom navigation wont be a huge undertaking since every other component can be reused. As i type this i realize you said bottom sheets which is different from the bottom style navigation but i will leave up what i said earlier anyway.

lh3.googleusercontent.com/db95TJ0Rq1ng7sDvp4Z76n2oCTYyvjwE52ZyyHkFV4zQe2GayEVH5zi7XJ2GFECcWsWhHRELPQLcoYDcPk9jqNZn10BO4C0f5ikM=w1064-v0

yeah i like the idea of turning the mini player into something that could be dragged up to show the queue. Id have to play around with it and see how gestures interact with each other as i'd still like a tap to open now playing.. but a drag up showing the queue below it would be pretty cool.. although that would be pretty funny in the actual queue view to scroll up from the mini player to bring up another queue haha

[Toucan Stubs]

(Please ignore. This message was a mess.)

[Toucan Stubs]

Thanks s very much for your response, and I'm glad you like the idea and think it would be cool.

This led me to another thing worth mentioning, and I'll respond soon.

[GoneMAD]

Fyi your deleted response was fine. I just didn't have anything to add to the topic at the time. Trying to enjoy the weekend after a hellish 7 days (working full time day job + hammering out 5 patches to gmmp in a week is certainly stressful)

[Toucan Stubs]

Feb 6, 2021 23:58:08 GMT -5 GoneMAD said:

Fyi your deleted response was fine. I just didn't have anything to add to the topic at the time. Trying to enjoy the weekend after a hellish 7 days (working full time day job + hammering out 5 patches to gmmp in a week is certainly stressful)

Hey, understood. Sorry for the delay. The deleted response was me thinking through the problem out loud while brainstorming suggestions, and it confused the matter.

Accessing the Queue from the mini player alongside Now Playing would be nice, but when thinking through the solution, I realized that there's a more fundamental issue in 3.0 that really should be addressed. I got a little weary about getting into it because I think it's a high priority for the fundamental usability of GMMP 3.0, but I didn't want to sound rude or callous towards the work you've been putting into this, and with the need to fix launch bugs and address everyone's personal feedback, I didn't see this fix happening soon, if at all, so I backed off to using v2.x. But I sincerely hope to use 3.0 again.

Though I started this thread by requesting "quick access to the Queue", my major point was that there should be persistent, intuitive access to core features like the Queue and Now Playing independent of, and without altering, library Navigation. So again, I seriously appreciate the work you've put into this, and respect how you handle yourself as a developer, but just to put it clearly, I believe this isn't a 'bug' or a 'feature request', I believe this is a design flaw. But it's one that can be fixed without any substantial redesign.


As I was familiarizing myself with Material Design, I looked into the basics of Navigation, and this is the very first article about it: material.io/design/navigation/understanding-navigation.html

The first part of the article (using a music app as an example) explains a core principle that GMMP 3.0 is technically restricted by but currently not abiding. Simply, when navigating the library, the hamburger menu is replaced with a back button that returns you to the previous level in the hierarchy, and the menu button only returns once you return to the top-level of the hierarchy. But in GMMP 3.0, if you navigate a few levels into the library, then navigate to Now Playing or the Queue, the nav controls disappear and you can go back to the top-level without reversing through the navigation hierarchy, without a persistent and without clear distinctions between what is top-level or nested.

As mentioned earlier, Now Playing scrolls up by swiping up from the mini player, which is convenient and would be nice for Queue access too, but it gives the impression that Now Playing can be swiped back down into the mini player to return to your position in the Library. However, Now Playing and the Queue are full screen views that act as a navigation, and returning back to the library is not intuitive or consistent with in-app navigation. This causes confusion about where users are in the app, and can lead to several repeated and unnecessary taps to return to previous locations.

However, also as mentioned earlier, I brought up the "Expandable Bottom Sheets" Material Design component as a solution for this, where the mini player can actually stay in front of the library view, expand into Now Playing and/or the Queue, and then collapse back down to the mini player with the library view remaining "beneath" it and in the same location.

Anyway, I hope I didn't over-explain that or come across patronizing in any way... I just legitimately think it's important, especially with how GMMP 2.x was known for being so intuitive and easy to navigate. It was a huge feature / design principle that currently doesn't exist in GMMP 3.0, but I would love it if it did since I know 2.x won't get these cool new features.

[GoneMAD]

"As mentioned earlier, Now Playing scrolls up by swiping up from the mini player, which is convenient and would be nice for Queue access too, but it gives the impression that Now Playing can be swiped back down into the mini player to return to your position in the Library."

There is no swiping up or down on the mini player. a click on the mini player opens now playing and the back button will go back to the previous view. Now playing has the hamburger view because its probably the most important view in any music player and shouldnt be gated through a single point. Also keep in mind that GMMP allows you to start on any single view so in order to support that i had to be a bit flexible on what can be accessed where. I am pretty sure i didnt object anywhere to having quicker access to the queue, any response i made would have been in relation to what was possible in the current design. I am not redesigning the app for a 3rd time so any future changes have to fall in line with how things currently work

[Toucan Stubs]

Whoops, I think there's a potential miscommunication here. I was worried about that with my message, since the language probably makes more sense in development meetings, but probably comes across more abstruse when it’s from a stranger on the internet. :-) Let me see if I can clear this up and state my suggestion very clearly. This’ll be my last post unless there are any follow-ups or I can be of help.

I am not remotely saying the app needs a redesign, much less a rewrite. A UX design flaw can be hard to spot when it's not a clear-cut bug, but it can still cause a number of usability issues, but the severity of the issues correlates to the importance of addressing it, not to the difficulty or complexity of the solution.

When I discussed the scope of the usability issues that myself and other users experienced with 3.0 navigation, I tried explaining how they are legitimate UX issues that should be acknowledged. I was *not* saying there are several technical or design issues with the app. I was justifying why I thought it was something that should be addressed as a priority alongside existing bugs and feature requests, if not more-so since it is stopping people from using the app.

Regarding "swiping up" on the mini player, I just misspoke, as I've definitely tapped it hundreds of times. :-) That comment was meant to focus on the expand up animation, which, as is typical in mobile UX design, intuitively seems like it should collapse down to return to the library using a similar gesture, be it a tap or a swipe.

But I am saying I *like* the idea of it actually expanding up for quick access and collapsing down to return to the library.

I also wasn't saying that Now Playing shouldn't have a hamburger menu. I was explaining how it currently breaks expected Navigation flow.

And finally, you’re right that you never objected to faster access to the queue, but although that was my original ask, I realized it would still be a problem if it navigated away from the library navigation, so it wouldn't solve the core problem.

So with that, I thought I identified a pretty straight-forward fix, one that I thought you said was doable and that you really liked in your reply back on February 4.

I am suggesting that Now Playing and the Queue should expand from the mini player and collapse back into it, while the library navigation view remains in the background, using the Material Design Expandable Bottom Sheets component:

material.io/components/sheets-bottom

Example pictures from that page:
1. lh3.googleusercontent.com/db95TJ0Rq1ng7sDvp4Z76n2oCTYyvjwE52ZyyHkFV4zQe2GayEVH5zi7XJ2GFECcWsWhHRELPQLcoYDcPk9jqNZn10BO4C0f5ikM=w1064-v0
2. lh3.googleusercontent.com/22M7ktDIYF6lOqYwJw5pPDf0eWFjaQhDi9QDDaSj0QQlGWH_2ek08-4gE4cNuLy3VlELkYe_cyG5_WpZgCcSY3amrL1pTuazqtenpWM=w1064-v0

So that's it. As a last request, I'm curious if you acknowledge the navigation issues I described, if the suggestion is technically feasible, and if you think it would be an improvement even if it's technically too difficult. You have my best wishes either way, and thanks.

[GoneMAD]

yea what you suggested is doable but not something i can just turn around in a day. its something i plan to address at some point. my focus at this point is bug fixes.

"So with that, I thought I identified a pretty straight-forward fix, one that I thought you said was doable and that you really liked in your reply back on February 4."
i did like your suggestion..

maybe its not apparent from here but I have a massive workload already: trello.com/b/JCyp2kas/gonemad-music-player-development while i'd love to get to ever request in a reasonable amount of time, thats just not going to happen