View Single Post
Posts: 237 | Thanked: 193 times | Joined on Feb 2010 @ Brighton, UK
#6
Originally Posted by pelago View Post
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. within the shownotes scrollable area) with the actions available below.
Treating the episode as an object certainly helps me to understand your POV, very insightful. Although, for me your approach is to put the show notes 'front and centre', I guess as this itself isn't compelling to me I'm still unswayed. If this approach brought some other benefits in terms of information or functionality exposed I'd personnally be more interested.

Originally Posted by pelago View Post
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.
For the podcasts I follow, the title and knowing that they are in date order means I wouldn't need to leave the list window to find what I'm after.

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.

Originally Posted by marxian View Post
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.
Funnily enough, Pelago's comment about treating the episode as an object brought your app's approach to mind. It also highlights a subtle difference that I see between the two use cases (gPodder vs. cuteTube). With gPodder (for me at least) I am familiar with the content already - I have subscribed to it after all - I don't necessarily see the immediate need for detailed information; whereas cuteTube (even when you view a channel) can essentially always be seen as a search result, therefore the user probably needs confirmation that they are interested in the particular video.

Thanks for the performance obsevations comparing the two approaches.

Last edited by mr id; 2010-11-22 at 13:15. Reason: Typo
 

The Following 2 Users Say Thank You to mr id For This Useful Post: