Simple by Default, Powerful When Needed

KDE (back when it was still the name of the desktop environment) and our applications historically stood for powerful features and great flexibility and customizeability. This is what our users love about our software, this is why they choose Plasma and KDE software instead of one of the other Free desktop offerings. And it is also something they would fight tooth and nail for if we wanted to take it away (as many a KDE maintainer who dared to remove a feature he thought was unnecessary can tell).

On the other hand, this power and flexibility at times leads to user interfaces that intimidate especially new users if they expose all the features they have to users at once, leading them to avoid our applications altogether. This keeps them from ever experiencing the power which they might enjoy later on, as they use an application for more advanced tasks.

With KDE4 (back then, Plasma as a brand was not born yet), the aim was to keep the power, but do away with the scariness, as the KDE4 Vision states:

“Anything that makes Linux interesting for technical users (shells, compilation, drivers, minute user settings) will be available; not as the default way of doing things, but at the user’s discretion.”

In the design vision and principles section of the KDE HIG, we condensed and evolved this goal into a simple guiding principle:

Simple by default, powerful when needed.

How do we reach that goal?

As the first step, it is necessary to define the target audience and use scenario for an application. Only if we know that, we can define which goals users should be able to reach using the application.

The next step is to define for each goal how likely our target users in the target scenario are to actually have that goal, and how regularly. As an example, when we planned KMail Active (aimed at tablet computers) a year ago, we categorized the tasks we wanted to support in three groups: common, uncommon, and rare.
Only the common actions would be accessible directly in the main user interface. Since the usage scenario we had in mind for KMail Active was “Quickly checking up on new mails on the go or at home on the sofa and occasionally reply”, only those functions relevant to that scenario were planned to be placed in the main UI.
This is how we achieved the “Simple by default goal”:

Tablet email client mockup

Early-stage mockup for an email client for tablet computers, to be used in Plasma Active, applying the “Simple by default. Powerful when needed” philosophy.

We optimized KMail Active for users who would rather use KMail Desktop to actually organize their emails by sorting them into folders, or try to retrieve old emails in any folder. However, we recognized that sometimes users may need to retrieve an email from some otherwise rarely used folder or tag or move an email to a certain folder in order to find it more easily later, but don’t have access to a desktop or laptop PC. Therefore a UI to browse through the whole folder hierarchy and the tags (not mocked-up yet) was included in the design, though only visible if users scrolled the view to the left.

The same goes for writing new emails. The default UI for that won’t include things like HTML formatting or adding attachments (since writing longer and more complex emails is not convenient on a device without a keyboard, and users are less likely to have documents they want to send to people on their tablet), but they, too are only presented on demand, not by default. This is the “powerful when needed” part.

This philosophy will guide the designs provided by the VDG, so you will see more examples coming up, soon!

UPDATE: As I’ve seen in some discussions of my post on the Internet (not the comments here) that people apparently thought the screenshot represented the next KMail desktop UI, I’ve updated the screenshot and the caption to make clear what it is.

UPDATE2: Now that this post has become quite popular (2.394 unique visitors so far today!), I felt the need to make clear that – as always with Free Software – all this is a team effort. The original version of the design principles Wiki page was written by Andrew Lake, the user stories for KMail Active were co-written with Heiko Tietze and Michael Bohlender, the design of the mockup was done by Michael Bohlender with my help, and Michael also contributed to the philosophy tagline, by replacing “complex” with “powerful”.

Tagged with: ,
Posted in KDE, User Experience

Sitting on the Shoulders of Giants

I could write a whole series of blog posts about my Akademy 2014 experience, but

  1. I’m not motivated to do that
  2. You might get bored half-way through

Therefore I’ll try to summarize some of my impressions (and provide insight into the “rusty trombone conspiracy”).

The Talks

First of all, the talks: The two keynotes were both awesome!

Sascha Meinrath told us about the strong connection between Free Software and political activism in the opening keynote, and how crucial our work in Free Software is for a future where citizens are still free instead of constantly being watched and manipulated by companies and governments. I found it very inspiring, because its political implications are one of the major factors that draw me to Free Software.

Cornelius Schumacher‘s community keynote taught us how we all benefit from our involvement with KDE and why he and other long-time KDE contributors are doing what they’re doing. It’s always great to hear the stories of “the elders”. It’s a bit like grampa telling stories from WWII. ;)

Of course there were countless other great talks, too (see also the summary of day 1 and day 2 on the Dot, and the program for video recordings and slides).

The Story Behind the Rusty Trombone

Those of you who have attended Akademy or watched the talks by Àlex Fiestas, Björn Balazs or Jens Reuterberg and myself may have wondered why a certain term came up in each of them: rusty trombone. This sounds innocuous at first, but a quick trip to your ever-helpful Urban Dictionary will reveal that, while “harmless”, it isn’t a term you should utter at a dinner party if there is a chance someone at the table might know what you are referring to.

So how did this term enter our talks? Well, it happened as follows: On Thursday morning, yours truly boarded a train in Langen, suspecting nothing. I had read about a group of Akademy attendees organizing a trip from Berlin to Brno that day, but since my connection did not go via Berlin itself, I thought I’d have nothing to do with them. Therefore I was – of course pleasantly – surprised when I saw Mirko Boehm and Patrick Spendrin at Dresden train station. I then learned that there were quite a few more fellow KDEians on that train, among them Paul Adams. Paul always has an odd story or two to tell, one of those was about a contest which was once held to find a combination of two words which, when entered into Google, would only yield Urban Dictionary or pages linking to it as the top results. One of those was “rustry trombone”. None of the other people in the cabin new what it meant (or at least pretended not to know), so Paul explained it to us, in a vivid-enough way.

Fast forward to Saturday night. We had planned to have dinner together with everyone from the visual design and usability groups (namely Andrew Lake and his husband, conveniently also named Andrew, Jens, Björn, Heiko Tietze and myself), and Àlex decided to join us, too. When I told the others about my trip to Brno, the “rusty trombone” story came up, too. Nobody had heard the term yet (or at least pretended not to have heard it) and of course they wanted to know what it meant. I found just telling them to be too easy, so instead we turned it into a quiz. It took the group quite a while to find out what rusty trombone means, and of course the most fun part were the ideas people came up with what it could be.

After the mystery was solved, someone from the group had the idea that since most of us were giving a talk the next day, we all should try to incorporate “rusty trombone” into it. Andrew chickened opted out because – as his husband confirmed – he would not be able to continue his talk afterwards with even the least amount of seriousness. All the rest promised that all our talks would contain the magic words at least once.

I don’t want to spoil the fun for you by telling you how we (or actually everyone but myself, because I thought that having Jens mention it in our combined talk would be enough, to Björn’s utter disappointment) managed to integrate “rusty trombone” in our talks. Just watch the talks (linked above) and look and listen carefully. Àlex, Björn and Jens really mastered the art of injecting the words into their talks in a way that people who didn’t know what they meant (there were fewer and fewer of those with each of our talks, of course) probably wouldn’t have noticed anything suspicious.

Tales from the User Interface Design Room

For Monday and Tuesday, we had booked a room specifically for user interface design topics. The idea was that anyone could come to us to get input on their user interfaces from visual and interaction designers.

Three people used that opportunity: Jan Grulich for the Network Management System Settings module, Michael Bohlender for his email client which we now codenamed “NextMail”, and Friedrich Kossebau for “Workspace-wide services on non-file objects”. All three design sessions were very productive. In all of them, we aimed at striking the best balanced between “as simple as possible” and “as complex as necessary”, which isn’t easy when dealing with complex matters such as setting up a VPN or dealing with multiple email accounts each with a complex folder hierarchy or with mailing lists vs. regular email conversations, or with a theoretically unlimited number of services which can be offered for dealing with any object (such as an address in a text, or an image in a PDF). More details about the results of these sessions will surely pop up somewhere on Planet KDE over the next weeks.

Another very interesting session was “Human-Centered Design for the KDE HIG”: In that session, we applied one of the standard methods in human-centered design, the usability test, to the KDE Human Interface Guidelines. We had two developers (Frederik Gladhorn and Kai Uwe Broulik) test the HIG as its users. They could choose a task for which they would consult the HIG and then try to complete it live, while the HIG team observed them and then discussed with them why they got lost at a given point and which information they could not find. Friedrich Kossebau offered additional input.

The results from this are very helpful for optimizing the usability and usefulness of the HIG for developers. Some of the findings were that our users would prefer visual examples for first orientation, and text only for details which cannot be well communicated visually, that the structure of the main page should be optimized, and that more cross-linking between related articles would be helpful.

Community from the Perspective of a Temporarily Walking-Disabled Member

One of the most memorable experiences from this year’s Akademy has to do with an injury I suffered there. At some point during my travel to Brno, I got a small graze at the back of my right foot. Nothing serious, I thought, so I didn’t pay much attention to it. Unfortunately, some germs must have entered the blood stream through that graze, causing a serious inflammation. The foot got more and more swollen and walking started to hurt. It got better with each night, but worse during the days. On Sunday evening, I decided to stay in the hotel and visit a doctor the next morning. When I told Dan Vrátil about my inflamed foot the next morning, he had to laugh at first, because the exact same thing happened to Jan Grulich during last year’s Akademy. Last time, Jan had to be taken to the hospital and elsewhere by car, now he was the one driving me around.

At the hospital, the foot got bandaged and I was told not to walk. Not the ideal condition for a conference. This is where I experienced first-hand the helpfulness of our wonderful community. Whenever someone from KDE was near, I was supported while hopping about, and Àlex even carried my through the venue like like a bride over the door sill. We also found that office chairs can be repurposed as makeshift wheelchairs (including the fun of pushing someone around on one, of course).

The most difficult part, though, was the day trip to the water reservoir on Wednesday. Originally, I had thought I’d stay at the hostel during the day trip because I couldn’t even get to the reservoir without walking too much and Jan was not available to drive me there.

When asking on the mailing list whether it was possible to get there without much walking, I got two replies from people willing to give me a ride (Martin Klapetek and Teo Mrnjavac). In the end, it was Martin who took me to the reservoir (and also to the tram station the next morning). I was happy that I could take part in the day trip and take the ferry together with the group, but I had already accepted that I wouldn’t be able to get up to the castle we were visiting (castles are not exactly known for being easy to reach, right?).

When the ferry landed and I said I’d wait there for the group to return from the castle, Frederik Gladhorn said something along the lines of “No, we won’t leave you behind, we can get you there!”. I couldn’t really imagine how, until I found myself first on Frederik and Martin’s arms, then on Friedrich Kossebau’s and then Frederik’s shoulders. There are some KDE members which, due to their compact size, might be relatively easy to carry on one’s shoulders. At about 1,85m in height, though, I’m not exactly one of those, so it must have looked really funny when a fully grown man sat on another’s shoulders. I’ll add a photo as soon as I get one. The foot is now better, though it will take a few more days of rest and antibiotics to fully heal.

This was an example of what KDE means to me (and surely many others): We always help each other out, and even if something seems impossible, together we find ways to make it happen.

Thank you all for making Akademy 2014 such a wonderful experience!

UPDATE: As promised, here is a photo of me sitting on Friedrich’s shoulders and trying to avoid being slapped by a branch

Tagged with:
Posted in KDE

KDE Usability @ Akademy

I’m always excited to go to Akademy, but this year even more so than in previous years!

The reason for this is that I’m going to finally meet at least two guys whom I consider friends by now (Jens Reuterberg and Andrew Lake) in person for the first time ever!

But not only I m excited, everyone who is interested in usability should be, because we have quite a few things planned for you:

  • Björn Balazs will be doing a lightning talk Sunday morning about how to bridge the gap between the KDE community and our users.
  • In the afternoon, I will sneak into Jens Reuterberg’s talk on “The Designer and its habits” to present my idea of integrating one designer into each KDE project (I call them “resident designers”).
  • From Monday through Thursday, I’ve declared Room 3 as the “User Interface Design Room”. There you will find at almost any time at least one usability expert and one visual designer who will help you with all steps of human-centered design for your project, from the first step of creating a vision for your project, to creating a user research profile, down to the details of how to design a specific part of the user interface. Come to us, we’re all yours!
  • On Monday morning, we will also discuss how to proceed further from the ideas Björn presented during his talk, and in the afternoon we will discuss what developers and designers want and need from the KDE Human Interface Guidelines, so come join us to provide your input!

You can find all the details in the conference program and BoF schedule.

I am sure that Akademy will be crazy productive as always, looking forward to meeting you all in Brno!

Tagged with:
Posted in KDE

It’s Aliiiiive!

On February, I wrote a blog post entitled “Leveraging the Power of Choice“, in which I described an idea I had discussed with Àlex Fiestas about making it easy for users to choose between different Plasmoids for the same task (e.g. different application launchers, task managers, clocks, …). At the time of my writing the blog post, Marco Martin already had ideas about how to implement the feature, though he said that he wouldn’t have time to implement it before the Plasma 5.0 release. Shortly after Plasma 5.0 was released, Marco started implementation as promised. We decided it would make sense to start a thread in the VDG forum to collect ideas for the UI’s design. Together with several other forum users (most notably rumangerst and andreas_k) we fleshed out the design, which currently looks like this:

Image of Plasmoid alternatives switching UI draft

Plasmoid alternatives switching UI, latest draft

Fast forward to today, when Marco announced on the Plasma mailing list that “now the alternatives config ui has landed.”. It always feels great to see one’s ideas come to life thanks to the collaboration with developers and designers. Even now, though, input is still welcome in the forum thread!

Everyone who wants to switch between Plasmoid alternatives easily, look forward to Plasma 5.1!

Posted in KDE

Changes

I’m at a crossroads.

My scholarship runs out by the end of September (and my PhD thesis will be at least almost finished by that time), so now I’m at the point where I’ll have to decide what to do in the future.

There are plenty of jobs in the usability / user experience sector, but all which I’ve found mean working on proprietary software. However, when I compare my motivation for doing work which serves only a company and their customers with my motivation for working on Free Software which benefits potentially everyone, the differences are immense!

When doing work on proprietary software, I do what I’m asked for and I apply high quality standards (I’m still German, after all ;) ), but when I work on Free Software, I’m really excited and feel that I’m contributing to something bigger, which feels so much better!

Therefore, I’m not really eager to take on a job where I work on proprietary software, only being able to spend my spare time on what I really care about.

So I thought to myself “Hey, I have that blog which is read by a few hundred Free Software enthusiasts, maybe some of them know someone who might make my dream of working full-time (or at least part-time) on Free Software come true?

That’s why I’m asking you, dear reader: Do you happen to know of any organization which might hire (full- or part-time) or contract me for work on the usability of Free Software (preferably KDE software, but other Free Software would be okay as well)?

An alternative to working on FOSS would be working in the area of Open Access / Open Science, because that’s just as important to me as FOSS. Any pointers in that direction would be appreciated as well.

Thank you in advance!

UPDATE:  This is why I love the Free Software world: In other contexts, people help those they know personally (or maybe others they hope will help them in return later), but in the Free Software world when I post a blog post asking for help, I even get comments from people I haven’t met before, and even people from the press like Swapnil Bhartiya share my post on Google+ to help. Thank you all guys, you show me how awesome the FOSS world is!

Posted in General, KDE, User Experience

Which Tool Should we Use for User Interface Mockups?

When I read Heiko Tietze’s quite good introduction to Balsamiq Mockups over at the user prompt blog, I was reminded that I had considered introducing it as a tool for interaction design (not visual design, it’s not made for that) in KDE at some point.

What Heiko doesn’t mention in his blog post is that Balsamiq Mockups is free for open source projects. It’s possible to get individual licenses for Balsamiq Desktop for anyone contributing to open source software. However, the cooler point is that any open source project can get a free instance of myBalsamiq, which is the Software as a Service version of Balsamiq Mockups. The nice thing about it is that – like we’re used to from other SaaS solutions or from the awesome KDE Telepathy Collaborative Text Editing – multiple people can edit the same mockup collaboratively.

The downside, of course, is that it’s free-as-in-beer, but not free-as-in-speech. This was also the reason why it wasn’t really welcomed when I introduced it as an idea to the community a while ago. A free-as-in-speech alternative, as Heiko already mentioned, is Evolus Pencil. The downside of that is that it doesn’t support live collaborative editing (unless someone writes a Telepathy Tube for XUL applications) and it offers way less ready-made widgets than Balsamiq.

Having a standard tool for mockups within KDE would have the benefit that everyone could learn to use it and mockups could be shared or collaboratively edited in its format.

Since it would mainly be designers who would work with a mockup tool, the question is: What do you (interaction or visual) designers think? Would you prefer a quite mature, free-as-in-beer tool with collaborative editing, or a free-as-in-speech tool with less capabilities (but still good!), or do you prefer to use Inkscape for everything, even though it is much less comfortable to use for creating draft-level wireframes? Or do you use another tool which you think would be useful in general? Please name only tools which are at least free-as-in-beer and available on Linux.

 

Tagged with: , , , ,
Posted in KDE

The Little Things

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.

Screenshot of Send Later dialog after feedback

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.

Image of Send Later Agent after input

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.

Screen shot of Join Chat dialog before redesign

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.

Screenshot of redesigned Join Chat dialog

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”.

Posted in KDE
Follow

Get every new post delivered to your Inbox.

Join 29 other followers