yonlu/yellowjacket
1
1
Fork 0
Code Issues 55 Pull Requests 6 Actions Packages Projects Releases 12 Wiki Activity

Android: the transport controls are far too small #56

New Issue
Closed
opened 2026-08-18 05:59:09 +00:00 by logan · 1 comment
logan commented 2026-08-18 05:59:09 +00:00
Collaborator
Copy Link
Copy Source

Report

The playback controls are the most important thing in the mobile app and they are tiny. They should be clear, front and centre.

Findings

  • player-controls is shared between desktop and phone; the phone layout currently shrinks the bottom bar's contents rather than re-laying them out.
  • The touch-target floor is ~44-48px; the reference device is 424 CSS px wide, so four 48px targets plus the art and metadata is already tight — which is the argument for the separate issue slimming the mini player to play/pause + prev/next + favourite.
  • now-playing-view composes the same component, so sizing must be per-context (a size property or a host-set custom property), not a global bump.

Direction

Give player-controls an explicit size mode. On the mini bar: large play/pause, adequate prev/next. On Now Playing: much larger still, centred, with the secondary controls (shuffle, repeat) below at normal size. Sequence with the mini-player-slimming and small-screen issues.

**Report** The playback controls are the most important thing in the mobile app and they are tiny. They should be clear, front and centre. **Findings** - `player-controls` is shared between desktop and phone; the phone layout currently shrinks the bottom bar's contents rather than re-laying them out. - The touch-target floor is ~44-48px; the reference device is 424 CSS px wide, so four 48px targets plus the art and metadata is already tight — which is the argument for the separate issue slimming the mini player to play/pause + prev/next + favourite. - `now-playing-view` composes the same component, so sizing must be per-context (a size property or a host-set custom property), not a global bump. **Direction** Give `player-controls` an explicit size mode. On the mini bar: large play/pause, adequate prev/next. On Now Playing: much larger still, centred, with the secondary controls (shuffle, repeat) below at normal size. Sequence with the mini-player-slimming and small-screen issues.
logan added the Area/PlayerKind/EnhancementPlatform/Android
Priority
High
2
 labels 2026-08-18 14:36:13 +00:00
logan self-assigned this 2026-08-21 03:08:47 +00:00
logan added the
Status
In Progress
 label 2026-08-21 03:08:48 +00:00
logan commented 2026-08-21 03:08:48 +00:00
Author
Collaborator
Copy Link
Copy Source

Taking this with #59, on one branch (59-slim-the-mini-player) and in
one PR. Argued on #73 before starting rather than batched silently.

Your Findings and Direction already ask for this sequencing — "which is
the argument for the separate issue slimming the mini player", and
"Sequence with the mini-player-slimming and small-screen issues" — and
#59's Direction asks for "the larger targets from the control-size
issue". Doing them apart means laying the same row of pixels out twice
and shipping an intermediate state neither issue wants: three controls
still at 25px, or five at 48px in 424 CSS px, which is the overflow this
issue measured.

Following the Direction as written: an explicit size mode on
player-controls, per context rather than a global bump, because on a
phone the bar wants three controls and Now Playing wants five larger
ones at the same viewport — so the host says which context and the
viewport says which size band, and neither alone can express it.

Taking this with #59, on one branch (`59-slim-the-mini-player`) and in one PR. Argued on #73 before starting rather than batched silently. Your Findings and Direction already ask for this sequencing — "which is the argument for the separate issue slimming the mini player", and "Sequence with the mini-player-slimming and small-screen issues" — and #59's Direction asks for "the larger targets from the control-size issue". Doing them apart means laying the same row of pixels out twice and shipping an intermediate state neither issue wants: three controls still at 25px, or five at 48px in 424 CSS px, which is the overflow this issue measured. Following the Direction as written: an explicit size mode on `player-controls`, per context rather than a global bump, because on a phone the bar wants three controls and Now Playing wants five larger ones **at the same viewport** — so the host says which context and the viewport says which size band, and neither alone can express it.
logan closed this issue 2026-08-21 04:14:41 +00:00
gitea-actions bot removed the
Status
In Progress
 label 2026-08-21 04:14:54 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Area/Design
Area/Downloads
Area/Explore
Area/Library-UI
Area/Metadata
Area/Packaging
Area/Player
Area/Queue
Area/Settings
Area/Shell-Nav
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
 Platform/Android
Platform/Desktop
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Medium
3
The priority is medium
Priority
Low
4
The priority is low
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
In Progress
Somebody is actively working on this right now
No labels Area/Player Kind/Enhancement Platform/Android
Priority
High
2
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
logan yonlu
No Assignees logan
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yonlu/yellowjacket#56