Active Topics
-
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (3)
to SailfishOS by edp17 - 9 hrs, 53 mins ago -
The N900 is now 15 years old! (6)
to Nokia N900 by Macros - 1 day, 13 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 2 days, 2 hrs ago -
n770 youtube video (0)
to General by nmdv - 6 days, 1 hr ago - more...
 |
|
2010-11-22
, 12:27
|
|
Posts: 282 |
Thanked: 120 times |
Joined on Nov 2007
|
#2
|
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.
|
|
2010-11-22
, 12:30
|
|
Posts: 237 |
Thanked: 193 times |
Joined on Feb 2010
@ Brighton, UK
|
#3
|
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.
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.
 |
|
2010-11-22
, 12:32
|
|
Posts: 2,121 |
Thanked: 1,540 times |
Joined on Mar 2008
@ Oxford, UK
|
#4
|
Originally Posted by icebox
I agree that speed is important, as I don't want to slow down users who just want to click on an ep and play it. I would very much hope that the proposed stacked window could be made to appear as quickly as the current dialogue takes to slide up, or at least make the buttons appear just as quickly and be usable immediately even if the shownotes take a couple of seconds to fill in.
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.
Originally Posted by mr id
That's a good point, although there's no particular reason to limit the toolbar in my proposal to just one line, so it could be made two lines or more to accommodate more options. Obviously that will make the space for the shownotes smaller, though, so there is a limit to this.
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.
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.
Last edited by pelago; 2010-11-22 at 13:29.
| The Following User Says Thank You to pelago For This Useful Post: | ||
 |
|
2010-11-22
, 12:41
|
|
Posts: 2,448 |
Thanked: 9,523 times |
Joined on Aug 2010
@ Wigan, UK
|
#5
|
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:
Results in the video info window:
For the record, I am happy with the current approach used by gPodder.
Last edited by marxian; 2010-11-22 at 12:49.
Results in the video info window:
Originally Posted by mr id
A valid point. Which option is most convenient for the user will depend upon the desired operation. For viewing info, the stacked window is more convenient (one click vs two), for playback it is the same. Delete/edit operations may be less convenient using the stacked window approach.
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.
For the record, I am happy with the current approach used by gPodder.
__________________
'Men of high position are allowed, by a special act of grace, to accomodate their reasoning to the answer they need. Logic is only required in those of lesser rank.' - J K Galbraith
My website
GitHub
'Men of high position are allowed, by a special act of grace, to accomodate their reasoning to the answer they need. Logic is only required in those of lesser rank.' - J K Galbraith
My website
GitHub
Last edited by marxian; 2010-11-22 at 12:49.
| The Following User Says Thank You to marxian For This Useful Post: | ||
|
|
2010-11-22
, 13:14
|
|
Posts: 237 |
Thanked: 193 times |
Joined on Feb 2010
@ Brighton, UK
|
#6
|
Originally Posted by pelago
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.
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.
Originally Posted by pelago
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.
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.
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
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.
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.
Thanks for the performance obsevations comparing the two approaches.
Last edited by mr id; 2010-11-22 at 13:15. Reason: Typo
|
|
2010-11-22
, 13:41
|
|
Posts: 2,121 |
Thanked: 1,540 times |
Joined on Mar 2008
@ Oxford, UK
|
#7
|
Originally Posted by mr id
Thanks for the comments. I've just edited the bit you quoted, to say that the shownotes scrollable area could also show other metadata (in a smallish font) like dates when the content was published or downloaded, so I am expanding things a bit.
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.
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! ;-)
Last edited by pelago; 2010-11-22 at 13:46.
| The Following User Says Thank You to pelago For This Useful Post: | ||
|
|
2010-11-22
, 13:54
|
|
Posts: 2,448 |
Thanked: 9,523 times |
Joined on Aug 2010
@ Wigan, UK
|
#8
|
Originally Posted by mr id
You hit the nail on the head. That is why I chose the stacked window approach, and why I'm happy with the dialog approach used by gPodder.
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.
__________________
'Men of high position are allowed, by a special act of grace, to accomodate their reasoning to the answer they need. Logic is only required in those of lesser rank.' - J K Galbraith
My website
GitHub
'Men of high position are allowed, by a special act of grace, to accomodate their reasoning to the answer they need. Logic is only required in those of lesser rank.' - J K Galbraith
My website
GitHub
 |
|
2010-11-22
, 22:44
|
|
Posts: 1,030 |
Thanked: 792 times |
Joined on Jun 2009
|
#9
|
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.
Last edited by hawaii; 2010-11-22 at 22:49.
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.
Last edited by hawaii; 2010-11-22 at 22:49.
| The Following User Says Thank You to hawaii For This Useful Post: | ||
|
|
2010-11-24
, 14:42
|
|
Posts: 2,121 |
Thanked: 1,540 times |
Joined on Mar 2008
@ Oxford, UK
|
#10
|
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.
More comments and votes welcome, although of course at the end of the day it's thp's app to do as he pleases.
Currently when you click on an episode, a dialogue pops up from the bottom of the screen that looks like the following:
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:
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.
Last edited by pelago; 2010-11-22 at 12:26.