Please enter your password October 29th, 2006

Sure, why not?

 

Like this, LikeBack October 15th, 2006

As you may know, there are several factors that define the usability of a user interface. Aside from quantatively measured data to indicate characteristics such as error frequency or time to complete a task, user satisfaction is also very important. The means for communicating this feedback from the users to the developers has been somewhat problematic.

Jan Muehlig and Celeste Lyn Paul wrote an article (pp. 18-21) about usability in open-source projects, where they mentioned a few issues concerning the communication between users and developers. They described the current ways of giving feedback to developers. Common communication channels in open-source projects are: IRC (chat), mailing lists and bug reports. These channels may be fine for technical users, but they are not well suited for the average user. In effect, the feedback gathered from these channels give a distorted picture of the userbase.

How to address this problem? Sébastien Laoût (the developer of BasKet Note Pads) is working on a very simple yet effective solution, it’s called LikeBack. It gives users an easy way to send feedback, whether to report a bug or to send a thank you-note.



How can this help you? Here are a few advantages:

In short, more users will be able to give feedback which can be very helpful, especially in the early development stages of a project. While LikeBack is already in a usable state, there’s always room for improvement:


At the moment, LikeBack already works great and although Sébastien does not get much positive feedback on his other project BasKet, there is apparently evidence that users will be more likely to share their thoughts. This brings us to the question: why would you (as a KDE developer) want this? Knowledge of your user is essential for usability and if you choose to actively improve the user experience, this will be one thing you cannot get arround. :)

Get to know your user. ;)

 

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.

 

Imitation is the sincerest form of flattery July 12th, 2006

A few months ago, I did a short usability review of KOffice most precious application: KWord. The report never got finished unfortunately, but I decided to submit my findings in a raw state to the KDE Usability folks nevertheless.

Why I am bringing this up? Well, this got more interesting after I had read an article about Pages, the word-processing application of the Apple iWork suite, on ThinkSecret:

Apple’s Pages software is set to receive a number of significant improvements when version 3 rolls out early next year as part of iWork ‘07, sources have told Think Secret. Among the most notable will be the introduction of two new modes, Word Processing and Layout, that will each be optimized for their respective tasks as opposed to Pages’ current handling of both types of documents with one common set of templates and tools.

Compare this to my findings on KWord (I wrote this on February 19th):

KWord has lots of small issues, but most of them can be easily fixed. The biggest problem is the fact that KWord is aiming for two totally different types of users. A solution to this problem could be introducing “UI modes”. For instance, a “Write Mode” and a “Design Mode”. Switching between should be made easy, and then the mode will represent the UI that is suitable for the user.

I wonder how Apple got their ideas… ;)

 

Hajime! July 12th, 2006

This is my first blog post ever, so I’m very excited! Let me introduce myself:

My name is Chi Shang Cheng (first name: Chi Shang), I’m 20 years old and I’m an Information Science student at the University of Utrecht (Netherlands). I’m involved in the KDE Usability project and the OpenUsability project.

I started this blog, because I wanted to show the KDE community what usability is all about. Also, I wanted to have a medium to address usability issues in an easy to read format.

To kick of this blog, I have just finished a usability report on Kaffeine. Here’s the abstract:

After a short heuristic evaluation of Kaffeine, a total of 40 usability issues were found. Only 5 issues of high severity were found, 20 were marked medium, and the remaining 15 issues considered lowly severe.

Most of the issues were related to unnecessary complexity of the user interface. The application was not tested for task-oriented usability. Even though the application functioned properly from a technical perspective, attention should be given to a more aesthetic user interface design in the future.

Download PDF

Quality-wise, I think the Amarok usability report I wrote earlier is a bit better, mostly because of the use of literature/references. But don’t worry, I have lots in store for the future! ;)

Feedback is always welcome, since I’m too, still learning. :)