Swiping is extra; should be additional to UI (for discoverability)
Ideally, swipe action should be hinted by content. If not, at least by icons or text (e.g. tabs)
When navigating with 1 hand, key actions should be within reach of thumb, and navigating should be possible
Four navigational approaches:
Swipe up (transcript)/left (description)/right (chapters), as per User feedback: swipe navigation from player screen (2.3 beta) → No. You don’t have a preview of what screen will come up, and only on bottom you can show a preview of the content.
One long screen with blocks that allow to navigate to sub-screens, as Spotify does → No. Looks cool, but you don’t have direct ways to jumpt to relevant screen (always have to scroll vertically)
Tabs on top & actions buttons on bottom, swiping left-right switches between tabs, swiping up opens special screen (e.g. queue). Like Podcast Addict does, and as ByteHamster suggested. → Can be an option
Tabs on the very bottom, action buttons just above (still below main player buttons), swiping up opens the tabs, swiping left-right can be used for chapter navigation (if present for episode). → Can be an option
We’ll further explore the last two by making wireframes for them.
Alongside this work, we can create a survey to ask input from users:
What do you expect to happen when you swipe left or right?
jump chapters
jump episodes
jump functional screens
Which actions do you expect to use most often? (sort most → least)
[list of actions]
Which screens do you expect to use most often? (sort most → least)
@Zehra_Rajnagarwala, @rauljimenez and I are ready to show the first wireframe of the approach we’re thinking of for the player screen. We’re hoping that the approach will make for a nicer design and makes some new episode features (like transcript) more visible (while accommodating space for all the Podcasting 2.0 stuff we might get in the future).
Before we will turn the wireframes into interactive mock-ups (that we’ll test with end-users), we’d like to show you the wireframe so we can make sure what we foresee is technically feasible.
We’d like to organise this in the week of 14 April. I’ve set up a poll to find us a date and time - hope you’re all willing & able to join!
Pay attention to the time zones - I only bothered to calculate two of them
Sorry for the late follow-up on the meeting. Here’s some notes of the comments and questions:
Swipe → do we allow endless swiping (circular; after last screen you jump back to the first) or do we implement hard ends?
How should the cover image be resized? It’s relevant in case of smaller form factors, or additional bar in case of insufficient boost budget, or long episode or podcast title. Keeping the cover horizontally centred while scaling down would look weird.
What if the podcast or episode title is really long? Episode detail screen is limited to 5 lines has vertical scrolling; could be similar here. We can also have different limits for episode (e.g. 3 lines) and for podcast title (e.g. 2).
Maybe better to move elements in top bar (Chromecast icon + overflow menu) to the action rail (overflow button there)?
Gives more space to screen names
We might also make a hard cut (or at least shorter fade) between tabs & overflow dots/Chromecast.
Accessing the sleep timer is now behind an overflow menu, while it’s more important/frequently used than some of the actions in the action rail. At the same time, some of the items in the action rail we might want to push more than the sleep timer.
Moving elements around would also break the logic of separating time-sensitive actions on the episode and non time-sensitive / actions not applied to episode.
Maybe allowing users to reorder action rail items could help; everyone can prioritise their own thing. (Adding an additional option like we did for bottom nav, but using iOS-style drag & drop, though complex to implement.)
What to do with empty screens, e.g. episode a) that doesn’t have comments or b) doesn’t support commenting)?
hide: empty screens without actionable paths aren’t great
keep: screens disappearing if an episode doesn’t have it might confuse users (where did functionality go?) and would break muscle memory
Confirmed that when clicking on the chapter title, you switch to the chapters tab.
We should add current speed indicator (actual number). We have to see how to do this; we’d want it to align nicely with jump back/forward numbers.
We should make a landscape version. Technical implementation: should be all or nothing approach; manually created version (rebuild layout) or let Android do it. Current manual, automatic would require revision throughout the app. However, we got few complaints from end-users on current state (which isn’t great…), so probably low priority.
We should still show playback controls on other tabs
initial phase: keep player controls and everything below on-screen
after: implement animation (controls could pop out with shadow, while progress bar & actions rail fade out, and controls block moves down) to reach state as per Raúl’s mock-up
Notes from our UX meeting on the points raised by the devs:
Hard ends
It doesn’t actually look that weird, we will horizontally centre it.
Another option could be horizontal scrolling like in Spotify. That could also work in other places (e.g. in episode detail screen). However, there are some accessibility downsides (and we can’t use hold to pause because that is already used for copying the episode title).
We’ll probably go with 2 lines max base, with a tap-arrow-to-expand like Pocket casts has on the Episode detail screen in case the title goes beyond 2 lines.
We move options in top overflow to the action rail
TBD if we have overflow button in the action rail or if we have horizontal scrolling like the tabs
Two options for the Chromecast icon: keep it in top bar consistently or have in the action rail in full player and on the right side for the mini player (like Spotify)
Action rail: disabled buttons (if tapped, there should be a snackbar saying ‘not available’)
Screens (tab): keep the tab but empty state screens
