Playlist Usability Testing

[Dan Meltzer]

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
>
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?

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.

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.

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.

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..)

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.

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.

9) Agreed.  This shouldn't be too difficult to do, and sounds more
like something that was forgotten rather than a deliberate choice.

10) Sure.

Regards,

Dan