Bugzilla – Bug 11502
Fix design issues with Podcast Player
Last modified: 2011-11-06 23:25:01 UTC
When clicking on a podcast, the description should show up as the last item in the list, and as a multiline text field. Currently, its single line only, and not scrollable. This is preferable (to me anyway) over another right motion to see the full description.
Noah: do we have a screen design for this?
Created attachment 4979 [details] Guideline - iconlist (albums) As a default I would use the albums guideline for the Touch/Remote Skin. This template features a stacked text approach. Do we currently have artwork or is there plans to develop icons for top Podcast services?
Created attachment 4980 [details] Ref artwork - iconlist (albums)
I think that the issue here is that Podcasts can have descriptions that are paragraphs long. How would we present this?
That's right, they are sometimes the whole transcript of the podcast! That's why I suggested they appear as a multiline text field at the end of the list that can be scrolled down.
Caleb, are you referring to an individual podcast file/episode? When the context menu feature is completed, clicking on an individual podcast episode will start playback. Other information would reside in the context menu (press+hold or "+" button on remote to access), with a "more info" area that would display the podcast description. CM menu for the NP screen itself could also contain this info. If, on the other hand, you are referring to a parent directory (the podcast name, not the individual episode) (do we have this? in a coffee bar, don't have the device in front of me), then I could maybe see something like this working, with the description living at the TOP of the screen and the list of episodes underneath (we already sort-of have a template for this type of screen). Still, though, the description in this case would be truncated after a certain point.
I'm talking about looking for new episodes I want to listen to. The information should obviously also be available in now playing too. This is useful for example to get links the podcaster puts into the episode info. (And we need a browser embedded on the device so we can click on the links... but that's a different enhancement request :-) If they context menu's easy to get to, I think that's a fine place for it. But it should not be truncated, either in the CM of the podcast browser, nor in the now playing screen CM. Could we use the already extant information browser for this content? -C
Matt- reassigning over to you. Once you reach a consensus on the direction I can develop screen mock-ups or go directly into asset delivery for engineering.
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.
*** Bug 12689 has been marked as a duplicate of this bug. ***
Moving these bugs to P4 to make room for moving P1.5 bugs to P2
Administrative move of 7.5 bugs. All P2, P3, P4 being downgraded one level. Will then split P1s.
Moving Matt Weldon bugs
Unassigned bugs cannot have a priority.