Mozilla UX

With the recent launch of Firefox 20 for Android, we retired the quit button. Some of you noticed. Some of you were sad. Which in turn made us sad. Here’s how you can get it back, and some background around why we removed it in the first place.

You broke my workflow!

If you used Quit and were unhappy to see it go, well, we’re really sorry about that. The good news is that it’s easy to get back. Just install the QuitNow add-on, which will put Quit right back in the menu where it was.

Easy, right? Now go forth and quit like the wind!

A bit of history

We introduced Quit about 2 years ago, in a time where Android phones were lower in performance, and had poorer memory management built in than they do today. Our users were having memory issues on lower end phones, where Android wasn’t killing background tasks as well as it should have been.

Now, adding a Quit button was kind of a hack that apps aren’t supposed to do. Quitting an app isn’t really a core UI concept on Android, since it handles this kind of memory management at the OS level, and isn’t user controlled per app like on desktop. But we added it in, and our users were happy.

As time went by, phones continued to get faster, and Android improved by leaps and bounds. Android 4.0 brought with it better memory management than before, and also provided users with a multi-tasking interface that also allowed apps to be manually closed, satisfying those who preferred managing apps on their own over simply allowing the OS to make choices for them.

Growing with Android

As these improvements have developed on Android, Firefox has been improving release by release as well. Firefox 20 shipped with Private Browsing, for example. We have lots of other great stuff in the pipeline over the next several releases. A better homepage. A more beautiful Reader experience. Enhancements to Search. And much more.

The thing is, controls to operate these features need somewhere to live in our UI, and Firefox is designed to be as minimal and out of the way as we can make it. We aim to avoid overwhelming people with UI since web content always comes first. So we tuck things into the title bar, into the tab menu, and remaining items go into the Android menu.

This means that from time to time, we need to do a bit of spring cleaning on our UI to make sure we have the most useful, and most commonly used controls at your fingertips.

Given the advances in the Android memory management I mentioned above, it seemed reasonable to remove the Quit button to free up menu UI, and that it wouldn’t adversely affect device performance. The fact is, users simply aren’t faced with the same issues on newer phones that existed 2 years ago. (I should note that we only removed the quit button on phones running Android 4.0+ because of its aforementioned improvements. This means if you are on Android 2.3 Gingerbread or older, nothing will have changed. The quit button will still be there.)

It’s also worth repeating that Quit simply isn’t a core UI concept in Android apps anyway — notice that none of Google’s apps (GMail, Maps, even Chrome, to name a few) include a quit function, nor do must other independently produced apps.

Make it yours

Of course, none of that is meant to convince you that you shouldn’t have a quit button if you truly have a need for one. And that’s what makes Firefox so great: even if a feature doesn’t exist as core functionality in the browser, chances are that an add-on either exists or can be built to satisfy that need. We recognize that everyone uses the internet differently, and we encourage everyone to customize, hack and tweak your way to a better Firefox that works for you. It’s a lot easier than you think, and can make a world of difference to your experience!

Optimizing the Interface is Hard

Creating the perfect Firefox interface is a challenging problem. Every user has their own set of common tasks. The challenge is in defining a common “default” interface that maximizes task success for the most people, on the most tasks. Using designer insight alone, it’s not always easy to know the impact of each design element!

Genetic Algorithms

Genetic Algorithms are well-suited to suggesting novel solutions to complex optimization problems.  If one can define the right optimization (fitness) function, GA can calculate the impact of including and placing elements. Using data recorded from Test Pilot Heatmap studies, we have defined a set of “Web Activities” that describe what users actually do using Firefox. These included “search”, “surfing the net”, and “content creation”.

Evolving the interface

We divided the visible interface space into 14,000 “cells”. Each of the 100 possible interface elements were given starting positions, and allowed to grow randomly until all cells were used. We then simulated a set of common user tasks using each random interface, proportional to how often those tasks occurred in the recorded Test Pilot data set. An interface “did well” if the user didn’t have to move the mouse much to complete the task. Top performing interfaces were kept and allowed to “mutate”, by allowing UI elements to “grow” or “shrink”.  When interface elements got “too small”, they were placed behind the “more options” element, and assigned a higher cost to access.

Firefox Next

Within 700 generations, good candidates started emerging, and by generation 1100, convergence was achieved. We then chose the most visually appealing one as our candidate.   GA led to some ragged edges, so did some visual cleanup to squarify elements.  This “cleaned” candidate preformed with 98.1% of the effectiveness of the original.  The result, which we are calling Firefox Next, appears below. Bubbles describe the salient features. In particular, note:

1. Careful balance between user needs for content, and user desire for web advertising.
2. Much larger “back” and “scroll” elements — the commonest interactions users have with browser.
3. Page content de-emphasis, so that users can achieve other tasks on the internet easily.
4. On-screen keyboard, for easy form filling and content creation.

Conclusion

Bringing quantitative methods into design is an emerging field. Firefox Next demonstrates that even without expert designers, quantitative methods alone can create a beautiful, easy-to-use interface.

Project Readability

The Firefox UX team has been thinking a lot about type and readability lately, as part of our ongoing goal to make the web more beautiful and more readable on Firefox for Android than on any other mobile web browser.

Since the web is made almost entirely of text, we do a lot of little things to improve the readability of the web, especially on devices with smaller screens. We subtly increase the text size of content to make reading more comfortable (the algorithm we developed for this has actually been adopted by the folks working on Chromium). We  built a beautiful Reader Mode that converts articles into a simpler and more readable format. In fact, more and more, we find that we are comfortable with the baseline legibility of text in Firefox, letting us explore the broader definition of readabilty.

The web deserves great type

Historically, web browsers have relied on operating systems to provide fonts for displaying content. This has evolved with the rise in popularity of web fonts, but many websites still look to the OS for a generic Sans or Sans Serif typeface to use. This is more or less acceptable on desktop computers that ship with tons of fonts, but mobile operating systems don’t tend to provide much in the way of variety (iOS being the exception here, with quite an impressive collection of typefaces from which to draw). Android ships with Roboto, Droid, Droid Serif. All of these are strong for use in UI design, but they aren’t as well suited for the kind of long form content we see on the web.

So we thought, what if Firefox could make the web look better than Android’s default font allow? What if we shipped our own fonts inside the app? It seemed like an interesting opportunity that no one else was doing on Android browsers, so the search for fonts began.

Defining the right typeface

What makes a great typeface? It all depends on the job it needs to accomplish, so we started out by defining a set of criteria for finding the right pairing of serif and sans serif typefaces.

1. Must be beautifully designed and very comfortably readable
2. Design must be subtle – this is an all-purpose font. Like Helvetica, it should adapt to content but not make any strong statements about itself through its appearance.
3. Must have broad character support for multiple languages (good coverage across Latin/Cyrillic/Greek character sets)

Open vs. Licensed

Given that Firefox is an open source product, the natural place to start was to explore options for open typefaces. Sadly, we often found that either a typeface was beautiful but lacking in character support, or it had great coverage but was either unattractive or simply not appropriate or refined enough for general purpose use. So we moved on and started reaching out to font foundries about licensing fonts to use, and they delivered some of the best fonts available today.

Initially, paying to license fonts seemed like a reasonable alternate solution. It is quite common to pay money to get good design, whether it’s an illustration, a photograph, an icon, a piece of graphic design or a typeface. As discussions evolved with our teams, however, placing a paid font into our app opened up deeper and more philosophical discussions about how to deal with licensed objects inside of open source products. There is a real tension that exists between maintaining our free and open ideals and licensing things that will greatly improve the quality of our products — and that even now it is up for debate as to what the Right Thing to do is.

We felt it would be best to take it to the newsgroups and talk through our options. Paid or Free, Licensed or Open.

Samples

So to gather more research in preparation for a newsgroup discussion, we went back and did a much deeper dive into open source typeface design. And in our research, we discovered some open fonts we had missed the first time around.

We also learned that some of the fonts we dismissed early on for lack of  character support actually stacked up much better than we thought!

Unsurprisingly, paid fonts performed exceptionally across the board. However, the open fonts were more competitive this time around. Charis (serif) was a new find, and performed surprisingly well. Open Sans (sans serif) is strong across the board, and has considerably better character support than we initially thought. Gentium and Source Pro were also nice, but were either too distinctive in their design (Gentium), or lacked the character support we require (Source Pro). Even though the quality of design of the paid fonts remained superior to their open alternatives, it became a difference of A+s vs. As, whereas before it was A+s vs. Cs.

Given the closeness in quality between the open and paid fonts we were comparing, we decided to put our top picks for open fonts — Open Sans and Charis SIL — into our Nightly test builds and live with them for a while to see how they performed, and to get some more testing and feedback.

And it turns out, they are awesome, we’ve been very happy with them so far. The difference is subtle, but hugely enjoyable. The fonts are set to launch with Firefox 21 in mid May (goes to Beta in early April). But who wants to wait that long when you can try these fonts in our pre-release Firefox Aurora right now? Go get it!

Almost three years ago, we hosted a session here on Reddit where you got to tell us everything that annoyed you about Firefox 3.6. This led to an effort at Mozilla called “Papercuts” (see the blog post and slides). We got over 2000 comments back then, and we’d like to hear from you again!

What we’re after is the “paper cuts”, the stuff that gets in the way or annoys you about Firefox on a daily basis, and that we could help get prioritized.

So please, head over to Reddit, and tell us about your pet peeves!