Playlist Usability Testing

Bart Cerneels bart.cerneels at kde.org
Tue Apr 28 13:00:15 CEST 2009


On Tue, Apr 28, 2009 at 2:43 AM, Dan Meltzer
<parallelgrapefruit at gmail.com> 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
>>
> 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..)

We can very easily reorder the toolbox "tabs", even make then hidden.
But it's probably better to respond to the user by opening the tab he
usually works with.
In fact, I commit a feature about 2 months ago to open "My Playlists"
by default and always restore the previously open tab on startup. I
guess this is actually broken ATM.


>
> 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
>
> 10) Sure.
".Consider using the name of the loaded playlist in the Save Playlist dialog as
the default name when saving an existing playlist."

Both these are contrary the design of Amarok. You have to realize that
The Playlist != playlist in the PlaylistBrowser on the left ("My
Playlists") and the Playlist view is not an editor for playlists (ref.
Leo's first reply and my response). For the point of clarity I will
call it the (playback) queue.

You can only load or append  *Tracks* of a playlist into the queue,
not the actual playlist. Once loaded any connection between queue and
playlist is lost. You can also append Tracks from a different
playlist, so there is no one "name" for the state of the queue.

The PaylistBrowser is however supposed to be an editor for playlists.
Here you should be able to add/remove/rearrange Tracks in a playlist.
It's because of limited developer resources this behavior is not
present in the beta. That you can actually view the tracks in a
playlist has been re-introduced a month ago. This feature was present
in the 1.4 series though.

This exposes the root cause for what is now a usability issue.
Instinctively people want to use the queue as an editor.
The question can be asked: when a fundamental design decision
conflicts with the results of a usability test, is that problem
solvable?

Bart


More information about the Amarok-devel mailing list