Most of the time, I blog about bold, more or less revolutionary ideas for KDE software which may or may not be realized at some point in the future. I do that because I think those may be the most interesting for you, dear blog audience, to read about.
The majority of my time spent on KDE, however, is spent working on details. To illustrate that work, I picked two examples of where I think I made a difference by caring about the details.
One of my favorite little details where I could help was with the “Send Later Agent” in Kmail.
BEFORE: Original design for the Send Later Agent
When I saw the original design for the dialog for setting up a job for the agent, I was immediately reminded of what I often said about user interfaces in the web-based software I once worked on: “It feels like the database is staring right at me through the user interface!” I had this impression whenever the user interface merely exposed all accessible database fields, without any consideration of what may be useful to the user in which situation, which controls belonged together, etc. Developers are usually incredibly smart people, but many tend to see things from a technical perspective. As long as there’s a control for every field users should be able to change, and a button for every action they might want to do, it’s fine for them.
The original design of the send later dialog was pretty much like that: It was plastered with buttons for pretty much every action you could think of, date and time was set with a single edit field with a spinner where users would have to enter a formatted date/time manually, controls were placed in a way that would make it almost impossible for users to see which ones belong together. Plus, if users would have accidentally clicked the most prominent of the three (!) confirmation buttons, they would have sent an email which was meant to be sent later immediately, which might have lead to very embarrassing situations – or worse.
I liked the feature as such, as it allows you set up things like automatically sending birthday greetings every year or sending newsletters at a time where people are most likely to read them, but I knew the user interface had to change. After a little back and fourth with the developer (Laurent Montel) and Jos Portvliet via comments on the blog, we arrived at a much much simpler dialog with which users could still set up the same things, but in a much easier way.
AFTER: The dialog after our feedback was implemented
UPDATE: One anonymous commenter mentioned that the “Delay” checkbox in the released version (see below) doesn’t make much sense. I agree with him or her. That’s why above you see the version as it was posted on the developer’s blog after our iteration. As you can see, no “Delay” checkbox. However, that checkbox was put in there at some point between that screenshot was posted on the blog and the feature was released. I have no idea why. I’ll ask the developer and do another update when I have an answer.
AFTER 2: The Send Later Agent as it was released
Another overhaul I recently contributed to was the dialog for joining a Jabber chatroom in KDE Telepathy. At their sprint in mid April, the KTp team focused on their group chat experience, one aspect of which was the aforementioned dialog. Like the Send Later Agent dialog, it allowed users to do anything they might want to do, but wasn’t optimized for typical user workflows.
BEFORE: The Join Chat dialog up to KDE Telepathy 0.8.x
If users often joined the same rooms, they would either have to add them to the favorites (which would mean they had to enter the room address, click “Add Room” and then “OK” if they also wanted to join then, or else they’d have to change to the “Recent” tab every time they’d want to re-join the same room. The layout with the three buttons next to the listbox wasn’t optimal, either.
So we went ahead and streamlined it. I first thought “Okay, what are users most likely to want to do when they open the dialog?” We assumed that the majority of users have a few rooms they visit regularly or from time to time instead of joining completely new rooms very often. Therefore after selecting the account to use (which now also sports a label), users are now presented with a combined list of favorite and recently visited rooms (the checkbox next to the star will be gone in the final version) where they can just click a room and click “Join/Create” (now the button also has a label which says what it does instead of a generic “OK”). With this setup, users who don’t use too many different chat rooms don’t even need the Favorites feature because the list of recently joined rooms won’t get overcrowded anyway.
AFTER: The Join Chat dialog after the redesign
Only if they don’t find the room they want to join in the list, they have to enter it in the edit box below. And only if they don’t know the (exact) name of the room, users would have to change to the Search tab (which got a few improvements as well, such as a combined start/stop query button instead of two separate ones).
Here as well, no features were added or removed, but the user interface is now optimized for realistic user workflows.
Apart from these little before/after examples, I consider my work to be successful when I gained the trust of other contributors, because – due to a lack of organizational authority – trust is essential for usability work in a Free Software project.
That’s why I was very pleased when, for example, I heard senior members of the KDE Telepathy team tell newer members to “Just do as Thomas says.” when it comes to detailed usability questions. Not because they are obligated to do so, but because the senior members trust, based on their experience with me, that what I say usually makes sense.
Usability professionals not only have to work well with developers, though, but also with visual designers. Therefore I was equally pleased when Jens Reuterberg told me that he likes working with me because “you’re a usability guy who hasn’t told me to go fuck myself… yet”.