![]() |
gPodder users - dialogue or window when click on an episode?
I have a suggestion for a change in how gPodder for Fremantle (N900) behaves when you click on an episode. Please read the explanation below then chose an option in the poll above.
Currently when you click on an episode, a dialogue pops up from the bottom of the screen that looks like the following: https://bugs.maemo.org/attachment.cgi?id=3212 The above is when the episode has already been downloaded. See variations when an episode has not yet been downloaded or is currently downloading. You'll notice a "Shownotes" button which brings up the text associated with the episode. My proposal is that instead of a dialogue popping up from the bottom, a "stacked window" (i.e. one that and has a back arrow in top-right) slides in which contains the shownotes immediately, and has the remaining buttons at the bottom, like the following mockup: https://bugs.maemo.org/attachment.cgi?id=3213 Also see mockups for when an episode has not yet been downloaded or is currently downloading. This has the advantage that the shownotes are immediately available without having to do a separate click. In case it isn't clear, my proposal is that the buttons at the bottom of the episode window will be in a toolbar anchored to the bottom of the screen and won't scroll with the shownotes, so they should be just as easy to reach for the user as the current dialogue implementation. For the sake of honesty, one downside I can think of with the stacked window proposal is that it is a little harder to go back to the list of episodes, as the user will have to click on the top-right arrow rather than anywhere in the blurred area above the dialogue in the current implementation, but I don't think that is too much of a hardship. Also, translations into other languages may use longer words than in English, so may not easily fit onto one line, in which case maybe the font could be smaller or the toolbar moved back to two lines. I have made this suggestion to thp using bugs.maemo.org (see the feature request at https://bugs.maemo.org/11501), and he suggested setting up this poll to see what the rest of the user population prefers. It is worth reading that bug report for more information. If you use gPodder, please vote in this poll for your preferred behaviour when clicking on an episode. If you like the stacked window idea, you could also vote for it on https://bugs.maemo.org/11501. Feel free to comment in this thread to say why you prefer one behaviour over the other, or if you have any other suggestions for what should happen when you click on an episode in the list. |
Re: gPodder users - dialogue or window when click on an episode?
I preffer the now implemented methon - it's faster. I usually know what podcasts I follow - if I want the show notes I can click to get them.
|
Re: gPodder users - dialogue or window when click on an episode?
For me it's about what user interface paradigm you are modelling with the click - is it select (think mouse single / double-click) or is it options (think mouse right click).
For me as there isn't a single action I always want to perform when selecting an episode - I need a context menu to present options to me. Can't remember the last time that I even read any shownotes. I would also like to see the options available extended in the pop up as well (e.g. mark episode as played etc). Displaying the show notes limits the number of options that can be presented - which is likely in turn to push extended options into a menu on this new stacked window. Before you know it you've brought one action one click closer and pushed several others one click further away. I haven't tested it but I would expect that the context menu will pop-up quicker than a new stackable window with shownotes would. Just my opinion of course. |
Re: gPodder users - dialogue or window when click on an episode?
Quote:
Quote:
As you say, it depends on the paradigm you are going for. Personally, I see the episode as an "object" and so it makes sense to have a stacked window being part of the back/forward navigation and showing more information about the object (which could include file size, duration etc., dates published/downloaded etc. within the shownotes scrollable area) with the actions available below. Another idea I had which I mentioned in the https://bugs.maemo.org/11501 report is that once an episode is represented as a window rather than a dialogue, there is the possibility of adding extra functions. For example, a swipe left/right (and/or hardware keyboard cursor left/right) within the window could move to the previous/next episode in the list, which could be useful for flicking through eps to find a particular one. This isn't possible with the dialogue implementation. |
Re: gPodder users - dialogue or window when click on an episode?
The stacked window approach is the one that I chose for my own application, cuteTube. I don't believe that there are any performance implications as a result. For example, clicking on an item in the list:
http://img541.imageshack.us/img541/8...1618200.th.png Results in the video info window: http://img823.imageshack.us/img823/9...1618204.th.png Quote:
For the record, I am happy with the current approach used by gPodder. |
Re: gPodder users - dialogue or window when click on an episode?
Quote:
Quote:
I think it would be all to easy to take a media library approach to this screen (showing coverart, artist info etc, even cover flow etc) - I know you aren't suggesting this btw - which could get a little too 'form over function'. Also needs to work well in both portrait and landscape modes. Still, I'm just another regular user and don't expect my experience to be any more correct than anyone elses. Still, it leads to an interesting discussion. Quote:
Thanks for the performance obsevations comparing the two approaches. |
Re: gPodder users - dialogue or window when click on an episode?
Quote:
Maybe we should move away from thinking that the proposed scrollable information area is the "shownotes" and instead think of it as a general information and metadata area for the ep. For example, when downloading an ep it could also contain a progress bar and estimated download time (maybe removing the need for the separate download manager view). The title of the ep could be made blue and underlined and clickable to view the website for the ep (if the ep provides that info). You mention cover art. Yes, I think it would make gPodder more attractive if I could see the cover art as part of this scrollable information pane in the ep window (it might need scaling so that it isn't too large, and again, it is important that this is implemented such that the displaying of the cover art should not slow down the user who just wishes to click Play or whatever). If people dislike the white background of the current shownotes implementation and my mockups, I'm sure a dark background (or whatever the user's theme says) could be used. I think marxian's screenshots of cutetube look great, and that's the sort of thing I would like to see in gPodder. This is a very interesting debate, in any case, even though I don't seem to be persuading many people! ;-) |
Re: gPodder users - dialogue or window when click on an episode?
Quote:
|
Re: gPodder users - dialogue or window when click on an episode?
I voted for stacked window. It's about interaction reduction, displaying the show-notes is not intrusive, and it reduces the amount of actions required.
As it is, if you want to view show-notes and then download, it's 5 input actions. Select episode, view show-notes, return, select episode, play. With the proposed method it's reduced to 2 possible input actions. Select episode, show-notes are displayed, select play. It's more efficient and streamlined, and more importantly - it's not invasive at all, as displaying the show-notes is completely passive and does not require any input or thought from the user. |
Re: gPodder users - dialogue or window when click on an episode?
Thanks for replies and votes so far. At the moment, the votes are about 2:1 in favour of the stacked window, although few people who prefer that method have actually commented - do they want to comment why they prefer that method?
More comments and votes welcome, although of course at the end of the day it's thp's app to do as he pleases. |
All times are GMT. The time now is 20:37. |
vBulletin® Version 3.8.8