Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Demote the playback history to sub-screen of queue or full player screen #6874

Open
4 tasks done
keunes opened this issue Jan 13, 2024 · 5 comments · May be fixed by #6854
Open
4 tasks done

Demote the playback history to sub-screen of queue or full player screen #6874

keunes opened this issue Jan 13, 2024 · 5 comments · May be fixed by #6854
Labels
Needs: Decision Proposal and most arguments are clear, but needs a verdict. Type: Feature request

Comments

@keunes
Copy link
Member

keunes commented Jan 13, 2024

Checklist

  • I have used the search function for OPEN issues to see if someone else has already submitted the same feature request.
  • I have also used the search function for CLOSED issues to see if the feature was already implemented and is just waiting to be released, or if the feature was rejected.
  • I will describe the problem with as much detail as possible.
  • This request contains only one single feature, not a list of multiple (related) features.

App version

3.2.0

Where did you get the app from

Google Play

Problem you may be having, or feature you want

We need to start working towards a smaller list of 'top-level screens' ahead of #4376.
At the same time, we want to make the playback history accessible from a logic place.

Suggested solution

  • Disable the History by default in the menu for new installs.
  • Add a 'Playback history' item with icon in the app bar of the Queue screen.
  • Add a 'Playback history' item in the overflow menu (i.e. never an icon) of the Player screen.

Screenshots / Drawings / Technical details

Appropriate icon: https://fonts.google.com/icons?selected=Material%20Symbols%20Outlined%3Ahistory%3AFILL%400%3Bwght%40400%3BGRAD%400%3Bopsz%4024

@keunes keunes linked a pull request Jan 13, 2024 that will close this issue
@keunes
Copy link
Member Author

keunes commented Jan 13, 2024

Alternative to having the icon in the app bar of the Queue screen, I thought about having it in the full player screen. It makes sense there maybe even more, but it's already quite full.

Replying to #6836 (comment) from @ByteHamster:

The history button somehow breaks the conceptual hierarchy of the screens. To me, the history is a top-level screen, not a sub-screen of the queue.

I don't see why playback history would need to be a top-level screen. It is not a main feature, but a supporting feature. Main feature: playing an episode. Supporting feature: finding back what I played yesterday, so I can share it with colleagues when discussing in the office kitchen.

@keunes keunes added the Needs: Decision Proposal and most arguments are clear, but needs a verdict. label Jan 13, 2024
@ByteHamster
Copy link
Member

Currently the app hierarchy is "flat", eg there is no second-level episodes list. Moving screens to be sub-screens of others would break that. There are users who hide screens (a friend of mine hides the queue and only uses the "all episodes" screen). These users would then not bee able to get to these sub-level screens. That's like with people being confused about not finding the Echo screen, just that it's an actual app screen, not just a promotional thing.

I would vote to not make any screen a sub-level thing because that reduces configurability

@keunes
Copy link
Member Author

keunes commented Jan 14, 2024

Currently the app hierarchy is "flat"

This is not entirely true: the Statistics screen is already a sub-screen under Subscriptions. So this proposed change doesn't 'break' a full-flat architecture.

There are users who hide screens (a friend of mine hides the queue and only uses the "all episodes" screen). These users would then not bee able to get to these sub-level screens.

And for that reason we need to be very careful what screens we put where in the hierarchy.

But as noted in the first post, the playback history provides secondary functionality, thus can be demoted in hierarchy.

Moreover, the proposal is to also make it accessible from the player screen, which cannot be disabled. So this argument is not relevant in this case.

@keunes
Copy link
Member Author

keunes commented Jan 14, 2024

Currently the app hierarchy is "flat"

This is not entirely true: the Statistics screen is already a sub-screen under Subscriptions. So this proposed change doesn't 'break' a full-flat architecture.

There are users who hide screens (a friend of mine hides the queue and only uses the "all episodes" screen). These users would then not bee able to get to these sub-level screens.

And for that reason we need to be very careful what screens we put where in the hierarchy.

But as noted in the first post, the playback history provides secondary functionality, thus can be demoted in hierarchy.

Moreover, the proposal is to also make it accessible from the player screen, which cannot be disabled. So this is an irrelevant argument in this case.

I would vote to not make any screen a sub-level thing because that reduces configurability

This is true to a limited extent. But where the functionality concerned is supporting rather than main functionality, I think a slight loss of configuration in favour of general usability is justified.

(And as mentioned, this will contribute towards bottom navigation, where configurability would be decreased slightly anyway.)

@Matth7878
Copy link

Regarding bottom navigation it doesn't really matter how many screen there is in lateral bar. IMHO bottom navigation should be limited to the 4 top items and have an additional "..." button opening a menu to access other screens in lateral menu.

About quick access to history I agree it could be nice being able to access it from your default screen, so I would say queue, inbox, episodes drop-down menu.
I don't think it should be in full player view. There I would keep only settings to current playback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs: Decision Proposal and most arguments are clear, but needs a verdict. Type: Feature request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants