Playlist Usability Testing

[Leonardo Franchi]

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.

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. 	

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