UI Design Principles from Mozilla Labs

As part of the Labs concept series, I attended an online talk by Alex Faaborg from Mozilla UX, presenting Jakob Nielsen’s 10 principles for software usability design. They are simple and useful, so here they are.

  • Keep system status visible: Is there a web page loading right now? Am I in private browsing mode? The user should be kept aware of the current status, and feeback on modes should be timely. When a user doesn’t know which mode we’re in, this is called a mode error.
  • Systems should mirror the real world: Engineers want to implement whatever the technology makes easy to implement – but users want to use something that mirrors the world as they see it. Some technology elements are still confusing (e.g. Fx asking if you want to resend POSTDATA) but some are now commonplace (404 errors or the http:// prefix). Real world elements can appear in icons (padlocks, floppy drives, gold stars) or replicating a real life method (e.g. having a desktop).
  • User control & freedom: Don’t prevent users from doing certain things. For example, in Fx3 it’s impossible to bring back the Most Visited folder on the Firefox bookmarks toolbar if you delete it.
  • Consistency & standards: Be consistent internally with the way you’re always represented things inside your application, and be consistent externally with the wider OS or peer applications. These could conflict – Fx changed the bookmarks icon in v3 from a bookmark to a gold (or blue) star to fit with other browsers.
  • Recognition not recall: The command line requires you to remember everything, which is why most users find it too tough to use. Ubiquity suffers from this in a way – although it does a lot to help you, it can’t do anything unless you type something.
  • Flexibility & user efficiency: Toolbars that are malleable are flexible, but it’s tough to create complete flexibility, as very flexible UI systems (like Ubiquity) require some skill to use completely.
  • Minimalist design: Visual clarity is good. Reduce redundant elements (e.g. the address bar URL, the window title and the tab title). Combine elements logically – the iPod wheel combines a set of functions into one element while keeping it easy to use.
  • Error prevention: fix common user errors like commas in URLs.
  • Help users recover from errors: proactively provide contextual help, like the internet connection wizard in Safari.
  • Help and documentation: ensure users know where it is and can access it.

Balancing things out

The keen ones amongst you will have spotted that not all of these things are achievable – balances are needed between these elements, and the correct position depends on the user and the application. Here are the contradictions – and the balances – that I can identify.

  • More user control and freedom can mean less minimalism, less error prevention and less consistency. The user can reconfigure away from standards.
  • More recognition can mean less minimalism. The command line is an awesome interface for the right kinds of people.
  • More system statuses can mean less minimalism. Where do you put the throbber in a chromeless browser?

Creating an awesome design – it seems – is about finding ways of winning on both sides of these balances so that compromise becomes less necessary. At the same time, we must recognise that no system is going to be perfect for everyone – as the market becomes more diverse, the interface must understand and trade off different requirements in that market.






3 responses to “UI Design Principles from Mozilla Labs”

  1. Why do you have to fix your balance? You make it sound like you have to find your balance, then stick with it. What about a dynamic UI, that adjusts to the abilities of the user (toolbars for novices, consoles for pros)? Like the English teacher who will use piecemeal language in the primary school, and Shakespearian prose in the Sixth Form. Or the Physics lecturer who pitches Newtonian laws to the first years and Einsteinian relativity to the post-docs.

    Or something.

    I guess that all I’m saying is that human/computer interaction has got a long way to go till it reaches the refined level of human/human interaction; particularly if it’s going to do it on-the-fly like we do.

  2. also, yet another theme? I miss the trees… Have you looked into K2? I did but it confused me. Feel free to junk this comment…

  3. also also… check this out:


    although he doesn’t explicitly say it (or doesn’t seem to when I scan-read it), the whole “mastering a skill before you proceed, so that you can be relied on to have that skill in later levels” ties in nicely to the idea of a dynamic ui that opens up options as the user becomes more experienced.

    anyway, gotta go, I’ve an Agile lecture to get to…

Leave a Reply

Your email address will not be published. Required fields are marked *