Archive for November, 2008

Personalizing Firefox’s UI automatically. Just for you.

Sunday, November 30th, 2008

Here’s the question: Does automatically generated interfaces — based on user skill, dexterity, and impairments — have a place in Firefox?

The University of Washington recently released a program called Supple. Essentially, it puts you through a small digital obstacle course — move your cursor here, click there — and then calculates all of your motor-skill constants: what’s the difference between your single and double click, how quickly can you target a button on screen, what’s your reaction time, etc. Once it has all of the data, it generates an interface to match your particular set of skills.

Although this loosely falls into the adaptive interface category, it doesn’t have the normal problems associated with adaptive interfaces because it only adapts once. (more…)

Documentation Localization (and Ubiquity in the Top 10)

Tuesday, November 25th, 2008

After the tour around Europe and Asia, it became very clear that even Labs projects (perhaps especially Labs projects) need to enable a global community by providing better on-ramps to participation in more languages. Everywhere I went, I heard frustration that all of our documentation (when it exists) is written only in English. That makes it hard for contributors to get up to speed on a project, and for potential contributors to find out about a project. Luckily, everywhere I went people volunteered to translate what they could, if we had the infrastructure to support them.

With a head nod to Lipsey and Lancaster: “Wikis are the third best solution to any problem.”

MDC (Mozilla Developer Center) has done a great job showing the power of wikis to invite world-wide contributions. To make this a possibility for Ubiquity projects I’ve been looking into the API for Mediawiki. It allows such neat tricks as pulling out structured content in JSON, which makes it easy to build a pretty front-end for a Ubiquity site that uses as a back-end.

Awesome Statistics

While looking into the API, I discovered a whole bunch of neat statistics about A couple things to call out:

The Ubiquity User Tutorial is the 10th most visited site on the Mozilla Wiki with 1/3 of a million reads. In 9th place is Prism, which is another Labs project (this one originated by Mark Finkle). In 11th place is Mobile, which is run by Jay Sullivan formerly of Labs and uses a UI that was informed by Labs. Just squeaking in under the top fifty, in 47th place is the Ubiquity Author Tutorial, which is a bit shy of 100,000 reads. Then, in the most active pages section, the Ubiquity Commands in the Wild comes in 2nd, with 588 revisions. Wow!

It’s great to see Labs generating so much interest! It’s also interesting that the authorship tutorial was read only one third as meany times as the user tutorial. It shows just how generative the community we work in is.

Ask Aza: Mistake Proofing

Monday, November 24th, 2008


A simple and effective concept from Toyota is Poka-yoke, or mistake-proofing. Products and Interfaces are context-sensitive — that is, products and interface features have a particular purpose , but I’m curious if you can share any generic context-agnostic approaches to mistake-proofing, or Poka-Yoke? Principles of Poka-yoke you can apply to anything; to any product or interface?


An interface is humane if it is responsive to human needs and considerate of human frailties.  We make mistakes.  No matter how hard we try to concentrate and prevent errors, errors will happen when our concentration wanes or when we are forced to do something that is beyond our cognitive abilities like multi-tasking: the act of consciously thinking about two things at once — and, with the use of Queueing Theory & Little’s Law, we learn that multi-tasking leads to lower productivity.

Poka-Yoke is an excellent method of making a process more efficient and humane by being considerate of human frailties: we won’t always be thinking about which way a part fits in, so design the part in a antisymmetric way so that it can only be installed correctly.

Shigeo Shingo, the originator of poke-yoke, wrote “Defects arise because errors are made; the two have a cause-and-effect relationship…yet errors will not turn into defects if feedback and action take place at the error stage”.  In other words, users make mistakes, but those mistakes are detrimental only if they aren’t corrected immediately.  One context-agnostic principle of humane interface design is summed up in the mantra “Never Use a Warning When You Mean Undo“.  If you make a mistake, no big deal.  Just undo it.

For example, a common Poka-Yoke style method is to cover an important switch so that it cannot be bumped accidentally. But, what happens if you use that switch all the time? You’ll either leave the cover open or flick-the-cover-open-and-flip-the-switch as a single gesture. In the computer world, we often have the advantage over the real-world in being able to undo. So that even though you just ran the smash-the-car-into-the-wall safety test while the technician was inside, you can just go back to the way it was before.

If Poka-Yoke was practiced more in interface design our lives on the computer would be a lot less stressful.

Thoughts on China’s Web Users: Part 1

Sunday, November 23rd, 2008

I just spent the last couple of days in Beijing, working with the wonderful folks from Mozilla China, meeting with the major tech players, and covertly observing user behavior with other UI researchers in internet cafes. It was on of the most intense learning experiences I’ve been through in recent memory.

This is a brain dump, in no particular order, or some of the observations from the trip.


Interview in Berlin

Tuesday, November 11th, 2008, one of the preeminent sites for technology in Germany, wanted to know more about how we design interfaces. As we passed through the reconstructed space-station-from-the-future C-Base, they caught up with us for an interview.

All thanks go to Jane Finette for all the hard-work in setting everything up, and founder Jens Ihlenfeld for the questions and great discussions that unfortunately weren’t captured on film.

Ask Aza: Good Products at Large Companies?

Monday, November 10th, 2008

I’ve been remiss in blogging as often as I should. To try to combat this, I’ll be doing an “Ask Aza” thing once a week. Pose questions about design, Firefox, Ubiquity, Mozilla Labs, life, whatever and I’ll do my best to give cogent, non-sleep deprived answers. Feel free to shoot me an email with your questions aza [at] mozilla [dot] com, or leave them in the comments.

The first question comes from a reader of, which is where the idea of the weekly thing started.


I work as a product manager for a technology company in the valley.  In large companies like mine, the department of Product Management, Software Engineering, and Customer Experience work together, but in a clunky way, to build a product.  What is the best way, in your opinion, to infuse the humane design principles in a hot political environment?

For example, the classic problems of: product will define a feature based on market research and define the personas.  Engineering feels like we define something and “throw it over the fence” to them to develop.  At the same time, Customer Experience is bothered that Product Management didn’t involve them, etc.

My question is turning out to be more of a human resources question than about design, but wanted your thoughts.

Maybe you should start an “Ask Aza” column, like a Dr. Phil segment, or something.


Successfully bringing a product to market is a holistic endeavor.  User requirements drives customer experience; customer experience drives marketing; marketing drives user requirements.  Nobody should feel that a set of requirements has been “thrown over the fence”.  When this happens, the recipient-of-the-throw is beholden to an abstract deliverable and is no longer connected to the end-user.  That’s a real problem.  Combating this requires a tight-feedback loop which is most easily created with a small team: engineering gets to see the market research come in, and the usability people can guide engineering throughout the actual creation process.

In an ideal world, everyone on the team would have a foot in engineering, design, and marketing.  Unfortunately, this isn’t always possible.  What is possible is that we can create small, tight teams that collectively have intimate knowledge of all three disciplines.

The small-team idea is by no means new.  In the book In Search of Excellence, Tom Peters explains over-and-over again that it’s the small groups; skunk works, home-brew projects, and strike teams that drive innovation at companies both large and small.  The most successful teams are those of 10 people or less — preferably between 4 and 8 — that include people from the required disciplines.

By keeping teams small, products don’t get commitee-ized.  The team is directly responsible for success.  Success is dependent on making a product that meets the needs of the user and to the user, the interface is the product.

P.S.,  I like the idea of an “Ask Aza” column: Anything that’s alliterative must be good!