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