Playlist Usability Testing

Tue Apr 28 12:41:29 CEST 2009

On Tue, Apr 28, 2009 at 11:34 AM, Leonardo Franchi <lfranchi at kde.org> wrote:
> On Tuesday 28 April 2009 01:43:20 Dan Meltzer wrote:
>> On Mon, Apr 27, 2009 at 8:20 PM, Celeste Lyn Paul <celeste at kde.org> wrote:
>> > Hi Everyone,
>> >
>> > Last weekend I (along with CALUG and MD Ubuntu LoCo) conducted a small
>> > usability test on the playlist feature in Amarok Beta 1. I hope the
>> > comments in the report can be helpful.
>> >
>> > http://weblog.obso1337.org/2009/amarok-playlist-usability-testing/
>> >
>> > ~ Celeste
>> >
>> > --
>> > Celeste Lyn Paul
>> > KDE Usability Project
>> > usability.kde.org
>> > _______________________________________________
>> > Amarok-devel mailing list
>> > Amarok-devel at kde.org
>> > https://mail.kde.org/mailman/listinfo/amarok-devel
>
> Celeste---thanks so much for this report. This is really helpful and seeing
> Amarok from a new user point of view is something that is very hard for us to
> grasp.
>
> I'm going to bring it up at our sprint this weekend and we'll see if we can't
> hash out some of the harder decisions.
>
>> In response to "Reccomendations":
>>
>> 1)  Up until recently, the behavior for all levels of the tree has
>> been double clicks appends to playlist, single click selects, and
>> clicking the "+" expands the node.  This behavior is familiar to most
>> (if not all?) current users of Amarok.  Using a recent behavior change
>> to justify more behavior changes seems silly to me... wouldn't another
>> logical conclusion to take from the observation be that
>> click-to-select should occur everywhere?
>
> I've just been playing around with the collection browser, and I kind of agree
> with celeste here. I double click the header, it opens. I double-click an
> artist or album, and it adds to the collection. Having to move the mouse
> carefully to the + to the left of the small items is really a pain, at least
> here.
>
>> 2) I tend to agree with the PUD.. I don't think it has much value in a
>> standard environment. (Using it is much slower than a context menu or
>> a zoom-zoom drag+drop) However, I hear that it's very helpful on
>> touchscreens.. and because we are actively making a bastardized
>> stepchild that tries to work everywhere, the PUD will probably remain.
>
> I disagee. The PUD allows us to add songs to the collection *without* dragging
> them all the way across the CV.  She does make 2 very good points:
>
> 1) Append vs. Queue. Really this re-opens the can-of-worms that has already
> been discussed before (The Playlist as a Queue or The Playlist as a list of
> tracks). But regardless of that, we need to make the naming clearer.

Good thing to discuss at the sprint. But in any case we have proof now
that the confusion is a real problem for users.

>
> 2) Length of text on small screens.  Jeff--maybe shrink the sizes if required,
> or break into multiple lines? Truncated text is ugly and impossible to read.
>
>> 3) Agreed.  We need to take a look at the actions in the menus, and
>> the layout of the menu's themselves.  This hasn't really been done
>> since pre2.0, at the latest.
>
> Indeed. I think the menus were built ad-hoc during the 2.x process as features
> were added. Something to add to the to-do list at the sprint I think.
>
>> 4) Not sure I agree with this.  The vertical tabs function as tabs
>> when one selects a tab different from the active one.  The toggle only
>> occurs if the active tab is selected again.  The only reason why I can
>> think of that participants would click the active tab is that it is
>> unclear to them that it is the active one.  If this is the case, then
>> maybe the fix is coming up with a method to clarify which tab is
>> currently shown.
>
> She does have a point about the tabs acting like a normal tab toolbar---and in
> a tab toolbar, if you click the current tab, the window doesn't disappear but
> rather nothing happens. So it can be a source of confusion.
>
> Also, if Amarok is acting up (and is slow) sometimes i go to change browser,
> it's laggy so doesn't respond, and I click again, which then when Amarok
> responds again makes it disappear. Not fun.
>
>> 5)  Debatable.  In my experience, static playlists are not all that
>> necessary.  I think that they could be made more visible, but I'm not
>> convinced that Static Playlists are more commonly used by Amarok users
>> than Dynamic Playlists, and I'm not convinced that the "My Playlists"
>> tab (which is useless to anyone that doesn't have static playlists) is
>> more frequently accessed/more important than the "Dynamic Playlists"
>> tab (which is still useful to people that have static playlists,
>> especially if we can work on improving the interface..)
>
> I disagree with the "static playlists aren't that necessary" I personally used
> them a lot in Amarok 1.x, but have not really used them at all in 2.x because
> it's been such a PITA. I know, I should just fix it, but i'm sorta busy with
> other Amarok stuff and the PlaylistCategory/Provider foo is a little
> overwhelming.

SqlPlaylistProvider is implemented no. You should find it easier to
hack on. And 2 other pair of eyes need to look at it anyway.

The PlaylistProvider/manager foo will pass design review this weekend.
But anyone that can handle Collection/CollectionManager should find
the playlists stuff silly easy.

>
> Definitely the use-case of "making a new playlist from The Playlist" (gah the
> terminology sucks) needs some work. And it is impossible to find the playlists
> sub-category in the playlist browser.
>
>
>> 6) I can agree with this... although one could then make the arguement
>> that we should also label the center area "Context View" and the left
>> area ... "Browsers"?  This might make sense if we can come up with a
>> method of doing it that isn't an eyesore.  As far as using the
>> currently named playlist... perhaps, although I think that a lot of
>> the time the playlist isn't named.  I guess this would be easy enough
>> to handle, though
>>
>> 7) This is an option in settings.  "Fade out on stop" defaults to
>> true.  Did the participants not recognize that the sound was fading
>> out (or did the sound not fade out properly?)  Maybe we need to add
>> some visual feedback when the fadeout begins, and maybe as the fadeout
>> occurs, to improve this.  I think this would be a more general fix
>> than making sound not fade out by default.
>
> We could also make the fade out be a bit faster---2 or 3 seconds takes a bit
> for it to "sink in" that it is fading out.
>
> What sort of visual do you think would work? I'm not sure how to make it
> present to the user visually.
>
>
>> 8) There was a SoC project about this (that didn't get accepted)..
>> maybe it'll be a SoK project instead, or it'll happen on it's own at
>> some point... I do think that there is some desire for this, however.
>> Maybe as a temporary fix we could make it more obvious that the widget
>> pane can be hid.
>
> Haven't heard from enrico unfortunately, after he we couldn't accept him for
> the SoC.
>
> However the plain rearringing-by-drag-n-drop of components is something we've
> been talking about for a while, it should be really easy to add some
> QDockWidgets to see how it would work (as a technical experiment).
>
>> 9) Agreed.  This shouldn't be too difficult to do, and sounds more
>> like something that was forgotten rather than a deliberate choice.
>
> +1
>
>> 10) Sure.
>
> +1
>
> Leo
> --
> -----
> lfranchi at kde.org                Tufts  University 2010
> leonardo.franchi at tufts.edu                The KDE Project
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>