player UI is abysmal

[mcepl]

I have created my own fork of Podcast so I have imported my own OPML file (yes, forking of the repo is probably not a good end-user UI ;))

It seems like whole app works reasonably well. Except for the player UI.

Podcast player UI should have these functionality:

1. Start/Pause/Stop playback
2. Hopefully, start a playback from the moment where we left (because app have crashed, switched off, or phone has been switched off)
3. Show the position of the player in whole episode
4. Allow short skipping of some part of the episode

I believe that the best solution for this moment is using a regular

[colinfrei]

Thanks a bunch for your comments! I've been playing around with different UI ideas for the player, the main restriction always seems to be space.

1. Start/Pause works at the top right. What would you expect a stop button to do? Stop playing and reset to the beginning of the track? I'm not sure that's a common enough use-case for podcasts to warrant a button
2. That should work most of the time for single episodes. I agree that the play button at the top right should be able to start playing without having to select a single episode. That may need some logic to decide if it should continue playing the last track, or just start at the top of the queue (since the track you last played may be outdated by now...). Also, having the app crash is hard to catch - if that becomes an issue then we may need to save the playback point continuously while playing, but I don't think that's ideal.
3. Yep. Maybe a line along the top of the app, like Youtube has at the bottom (once the controls disappear).
4. You can already jump a bit by swiping the header bar left and right. One thing I'd like to add at some point is some basic instructions along the lines of http://usablica.github.io/intro.js/

[mcepl]

On Sun, Sep 22, 2013 at 11:48:38PM -0700, Colin Frei wrote:

1. Start/Pause works at the top right. What would you expect a stop button to do? Stop playing and reset to the beginning of the track? I'm not sure that's a common enough use-case for podcasts to warrant a button

I agree. I have added the first step more in order to make the description of the desired UI complete.

1. That should work most of the time for single episodes. I agree that the play button at the top right should be able to start playing without having to select a single episode. That may need some logic to decide if it should continue playing the last track, or just start at the top of the queue (since the track you last played may be outdated by now...).

I was thinking even for resuming individual tracks in the last place. If we ever get Gpodder Client API (which would be awesome!) then it can store moment in the track where it is being played, so different Gpodder API supporting clients can start to play from there. So, yes such API expects periodic signal storing the place where the track is being played right now.

And yes, meanwhile, I would vote for "play the last track you played" ... given The Principle of the Least Surprise I don't to switch tracks behind the users back.

1. Yep. Maybe a line along the top of the app, like Youtube has at the bottom (once the controls disappear).

Hmm, and wouldn't be just the most simple way (which is most often than not The Right Thing) just to show element somehow? E.g., in the middle of the column of the currently played track? Of course, heavily stylized and squeezed to fit the area?

1. You can already jump a bit by swiping the header bar left and right.

OK, but this I would definitively classify as "Simplification of UI by its hiding" ... discoverability of such UI is virtually zero.

Matěj

[colinfrei]

Added a progress line to cover point 3

[mcepl]

Thinking about it, I came to the conclusion that the only real solution how to press all those requirements into given space of phone, is just to do the same what for example Podax did: add new special page which would work solely as player. If you want to crammer all the player functionality in the queue page, I think you get only something subpar. Just my €0.02

[mcepl]

Let’s put here some screenshots of Podax:

1. List of all podcasts. That's functionally very similar to our Feeds page, and I don’t think there is much need to do any changes.

   

2. This is basically our Queue page, and I again I don’t think there is much need to change anything. One difference is that [Download] button is not each individual podcast, but there is only centralized [Download] button to get all missing media files for episodes in the queue. On the other hand, each episode, has its own equivalent of HTML5 progress element so it is obvious how far we are in dowloading media files.

   

3. This is what I've meant we are missing. Dedicated player page. Suddenly there is enough space for reasonably visible (and discoverable) controls for playback, shifts, etc.

   

4. Application menu (wouldn't it better to have something like this; more description of this drawer construct is described at http://buildingfirefoxos.com/building-blocks/drawer.html). But this is the least of all Podcast problems, your current menu is working well enough.

   

[colinfrei]

Thanks alot for your detailed feedback! There's definitely room for improvement, and a separate player page makes sense. I'll look at adding that soon.