Shared Values ⇒ Shared Ideas? What we can Learn from Firefox Australis

If you’re asking yourself “Huh? Australis? Is that edible?”, then let me explain: Australis is the codename of the new user interface that was introduced with Firefox 29 (see the Article on the Mozilla UX Blog for some background).

Australis is the result of years of design and prototyping iterations, which were lead by the recently defined Firefox Design Values. Of those values, especially one looks quite similar to the KDE design vision/motto/slogan/tagline/mantra (yes, it has been called all that!) that I described in my last blog post and which is described in more detail in the “Design Vision and Principles” page of the KDE HIG (though I swear to Stallman that I hadn’t read the Firefox Design Values when I came up with that tagline):

Theirs:

Balances power and simplicity – Firefox is simple and easy to use, clean and straightforward in its design. But simplicity is a means, not the end – the end is understanding and user-agency.

Ours:

Simple by default – Simple and inviting. KDE software is pleasant to experience and easy to use.

Powerful when needed – Power and flexibility. KDE software allows users to be effortlessly creative and efficiently productive.

Though not identical, these values are very similar in their meaning: Both the Firefox and KDE User Experience teams aim for a simple overall user interface, which still offers easy access to powerful features for those who need them. The similarity becomes clear when one compares what I’ve outlined in the aforementioned blog post with the principles which the Firefox UX team derives from that value:

80/20/2: default to surface minimalism and easy access to the rest

user-agency and understanding, not just less

Even though neither of us blatantly copied the other (they were first, but I only became aware of that document after we wrote ours), the similarity isn’t purely coincidental, either: Both KDE and Mozilla have started off from a quite tech-savvy user- as well as contributor-base, and both aim to reach a broad(er) audience without taking the powerful features which advanced users need away from them.

And – not surprisingly either – both groups came to a similar conclusion for how to solve this dilemma: Putting those things which most people use regularly on the main user interface, while offering well-integrated access to the more advanced and/or less frequently used features. In the Australis UI, there are three tiers of access to features (from most to least frequently used): The toolbar (actually, also the tab bar, but for the sake of simplicity I’ll just subsume both under “toolbar”), the button menu and the (hidden by default) classical menu bar.

However, the tricky part is that for many applications there isn’t “the normal user” and “the advanced user”, and therefore there isn’t “the normal feature” or “the advanced feature”. The same person can for example be a power user for graphics software who needs a very powerful tool for their job as a designer, but at the same time be an absolute novice when it comes to software development tools, because they have only just started teaching themselves some basic programming to be able to whip up some interactive prototypes.

A browser is one of those applications: It’s an application which every user with an Internet connection uses (with the majority using it every day they use a computer), which many use “casually” but many also use for highly sophisticated tasks (and in case of ChromeOS even for pretty much every task). Therefore there is no chance to say “An average browser user uses this and that feature, whereas an advanced browser user uses this and that feature”. The same goes for frequency of user scenarios: Some people use their browser mostly for reading on websites, others use web applications more often than “plain” websites, web designers/developers frequently use highly specialized tools.

So what did the Firefox UX team do to accommodate to that uncertainty? They made the user interface highly customizable, allowing users to populate both the toolbar and button menu with whatever UI elements they wish, as well as to rearrange the elements within each area freely. This means that users can adapt the UI to their personal usage patterns. And even UI elements that are created by addons are treated just like the ones that ship with Firefox by default.

Screenshot of Firefox in Customize mode

What my Firefox looks like in Customize mode – And yes, I’ve put the search bar in the friggin’ button menu, because I mostly use web shortcuts instead!

Is this high degree of customizability worth the effort for every application? Certainly not. For applications which are only rarely used or for which usage patterns are indeed highly consistent across users, a static user interface works just fine and has the big advantage for users that if they forget where a certain function is, they can consult the documentation or ask someone else, both of which are not possible if they can decide where to put it.

However, for applications which are used frequently and for which usage patterns vary between users, a flexible user interface solves the problem that even the best user research and most carefully designed default user interface cannot accommodate to the users’ idiosyncrasies. And even though some companies or designers may have made some people believe that an option is always a sign of bad user interface design, one of the dialog principles laid out in section 110 of the ISO 9241 (“Ergonomics of Human System Interaction”) is still “suitability for individualization”.

So, for all who feared that somehow KDE now decided to be “like Apple” or “like GNOME”, which translates for them to “Not giving the user any options”, fear not: In those cases where it makes sense, a flexible UI is precisely the embodiment of “Simple by default. Powerful when needed.”

Tagged with:
Posted in KDE, User Experience

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
Follow

Get every new post delivered to your Inbox.

Join 29 other followers