Re: Kaffeine usability report July 15th, 2006

I was happy to see that Jim Burns, one of the developers of Kaffeine, commented on my usability report. He mostly agrees with the issues I addressed, but I would like to openly discuss some disagreements.

First of all, let’s start with the cause of most disagreements. It lies within the definition of ‘user’. My scope was limited to ‘advanced beginners’: users who are impatient with needing to learn concepts (like novice users), but without the fear of failure and are even willing to experiment with accessing new functions. These users have no technical background whatsoever, whereas Jim assumes that the average users knows what ‘multimedia engines’ are.

Let’s face reality for a second, most Linux users are quite competent in interacting with software in general. Even without the data to back this up, I could say the majority of the Kaffeine users knows what ‘Xine’ and ‘Gstreamer’ are. The question is however: should a user know this when playing their favorite music video? I think the user interface should be designed that it’s accesible (in terms of usabilty) a larger user group: both the novice/beginners (non-technical) and the technical (Linux) users. How do we realize this? Simply, by applying ‘progressive disclosure’, where the main interface is kept simple and the advanced options are hidden into seperate dialogs. It’s the best of both worlds: beginners won’t be overwhelmed with sophisticated functions and advanced users will maintain flexibility and control over the program.

Discussion of several other disagreements:

> 3.25 Unnecessary display of Player Window thumbnail in Playlist tab> […] view is extraneous, since it is not relevant to [playlist] tasks

I say it IS relevant. A preview is always relevant. Besides which, you can resize these elements - thubnail, browser, and playlist.

Is a visualization from an mp3 relevant?

> 3.30 Unexpected pausing behavior [by default] when minimizing Player Window
> Change the default behavior to not pause playback on window minimization.

I suppose he’s getting at the default ‘Pause Playback when windows is minimized’ setting. Complains this is not industry standard. Doesn’t bother me, but I’m glad it’s configurable.

The reason it doesn’t bother you, is because you are aware of the fact that it is an option. Since other multimedia players don’t show the behaviour of pausing playback on minimizing, users couldn’t have acquired this knowledge from experiences with similar applications. By the way, if users would read the manual, usability engineers would be out of a job. :p

> 3.34 Unnecessary explicit notion of Xine engine

Complains this knowledge is too technical, and causes separation of Xine and Kaffeine settings. He again is not aware that you can change engines, and by doing so, you get different config options. Granted, Xine config is technical - that’s just the nature of the beast.

I am aware of this, but I am also aware of the consequences for the UI. So to me, from a usability perspective, I do not see the added value for the user (again referring to non-technical users). On a side note, Totem succeeds in using both GStreamer and Xine as a backend, while this is totally invisible/transparent for the user.