Weird screen resolution February 8th, 2007

I have to broadband connection, but not the preferred screen resolution…
bikkembergs.png

 

Find the links February 8th, 2007

I would love to click on the “install” links, but I only see three links…

dell-installation.png

 

Default window sizes… December 1st, 2006

This is how Ubuntu 6.10 looks like when you run the installation disc. What happened to the buttons?

ubuntu-install.png

So I decided to try to change the screen resolution:

ubuntu-install2.png

Ubuntu: linux for people that can get a decent screen resolution to install it

 

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

 

OK? October 11th, 2006

But where’s the OK button?

 

Fax machines don’t talk August 9th, 2006

It’s been a while since I posted my last blog entry. I have been very busy with my job lately, so I haven’t had much time to work on usability stuff. Researching and reviewing usability is not yet my day-to-day job, since I’m still studying of course, but I got a part-time job by a employment agency during the summer holidays. My main tasks consists of assisting the IT helpdesk, so I get to see lots of users struggling with the computer. :)

I have to fax a form declarating the hours that I have worked to my employment agency. I have never used a fax machine, so it was quite an experience for me. In some way… It’s a pity I don’t have a picture of it, but I’ll try to describe just how usable the fax machine was.

The first thing I had to do was to insert the paper face down. After my sheet of paper was magically scanned, I had to dial the fax number. The tiny screen was displaying the number I dialed, and beneath it, there was some text commanding to press either the ‘Yes’ or ‘No’ button. Well, I wanted to sent the form to the employment agency, so I guess that’s a ‘Yes’. What happened? I had to type another number onto the screen?

I asked the friendly receptionist what I should do, and she told me I had to hit the ‘Start’ button instead. Sounds obvious, but the fax machine misled me with another option. The screen was now displaying ‘Ready 98%’ (it started to count from 98%, guess the designer skipped some elementary classes…). I figured that I probably had to wait till it reached 100%. I was waiting a few minutes till the machine beeped. The beep was quite useless, because what did the beep mean? It was a sharp high tone that sounded for approxmimately one second. To me, it sounded more like an error: this fax machine sucks rather than you have succesfully faxed a document. But the screen was now saying ‘Ready 100%’. Why did it still say ready? So both the visual and audible feedback was not clear, while I had to be sure that the document was really sent, otherwise there would not be much salary this month!

I decided to have lunch to supress my frustation and while lunching, I had a discussion with a colleague about my first experience with the fax machine. He told me he also felt somewhat uncertain when he faxed a document. And he got the same feeling when sending an email. How do you know whether the other party received it? To overcome this uncertainty, he called the recipient to check whether it had been received. Which he too, find ridiculous, because he could might as well deliver the message over the phone…

Feeling somewhat silly, I called the employment agency and they confirmed they had received the proper documents. Me + fax machine lived happily ever after…

 

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