(Re)Designing Firefox

Stephen Horlander

6

Update — 2014/05/28
I added a slideshow of some of the design iterations we went through from Firefox 4 to Firefox 29.

Warning: It’s image heavy, might take a while to load on a slow connection.


So, we launched a thing. You may have noticed it. We called it Australis. Now it’s just called Firefox.

We spent a lot of time on it.

Dedicating yourself to a project can become an intense experience. You think about it all the time: in the morning, at dinner, when you are trying to watch a movie, in the shower, in your sleep, when you should be sleeping…

But then you set it free, because it’s finally mature enough for that. It’s exciting. But it’s also really scary. You are never sure if you made the right decisions along the way. I like to take some time in the post release glow for some reflection.


History

Left: Firefox 4, Right: Firefox 29

So how did we get from there to here?

We launched Firefox 4 in March 2011. It was a big change from Firefox 3. It introduced the Firefox button, revamped the add-ons manager, removed the status bar, combined the stop, go and reload buttons and included a comprehensive visual update—all while still having time to prototype and discard some other features along the way.

And yet it wasn’t perfect. It had a lot of the rough edges that projects accumulate in the process of going from being designed and built to being shipped.

Firefox 4 was our last monolithic release before we moved to a rapid release cycle. Six week cycles seemed like the perfect timeframe to iteratively smooth out the rough edges. So I created a project to do just that.


Philosophy

The project that I had created for iterative refinement however quickly transformed into a significant overhaul.

People in the frame: Sinchan Banerjee, Alex Faaborg, Brian Dils, Trond, Stephen Horlander (my legs), Jennifer Boriss, Frank Yan, Alex Limi
Taking the picture: Madhava Enros

At the beginning of June the UX team met up for its first post Firefox 4 team offsite. On the agenda was figuring out “What’s next?”. The entire team gathered in a room to pitch ideas and talk about problems unresolved—or that had been introduced—during the development of Firefox 4.

One theme that had been floating around for a while rose to the surface— Firefox is about customization, it should feel like it’s yours.

What would this mean for the interface we had just shipped? A lot of ideas were tossed around. Eventually one guiding principal stuck—make the best core experience we can and allow users to add and change the things that matter the most to them.

Building a fun easy to use Customization Mode—along with a more flexible Firefox Menu—would become the foundation of the new Firefox.


Visual Profile

So Curve, Such Aerodynamic

The offsite also sparked a set of other ideas that would make up what became known as Australis. Primarily: unifying the disparate bookmarking elements in the main window, refining the visual design, consolidating related or redundant features and streamlining the tabstrip.

While the redesigned customization mode would be core to the experience—the redesigned tabstrip would change the entire profile of Firefox.

“Make it look faster. No, no! It needs more air vents!”
Firefox 4 Aerodynamic Sketch — 2010

We had explored the idea of adding visual cues to Firefox to make it feel faster and smoother before. Yet some of the ideas were a little over the top.

Curvy Tab Sketch — June, 2011

This sketch from the design session—inspired by a previous mockup from Trond—had a curvy tab shape that immediately resonated with everyone.

It also had one important additional design tweak—only render the tab shape for the active tab. Highlighting the active tab reduces visual noise and makes it easier to keep your place in the tabstrip.

The early curve shape tried on a few looks. At first it was too angular, then it was too curvy, then it was too short, then it was too tall and then (finally) it was just right.

Design ideas for background tabs on Windows — October 2011

It turns out that designing background tabs without a tab shape is a lot easier if you have a stable background to work with. Windows 7 has translucent windows of variable tints and Windows 8 has flat windows of variable color. This meant we needed to create our own stable background.

We went through several variations to ensure that the background tabs would be legible. First we tried creating a unified background block, but it seemed too heavy. We even thought about keeping background tab shapes and highlighting the active tab in some other way.

Eventually we decided on a background “fog” that would sit behind the tabs and in front of the window. Think of it as an interface sandwich—glass back, curvy-tab front with a delicious foggy center.

We also made sure that adding curves didn’t increase the width of the tabs taking up precious tabstrip real estate. And we removed the blank favicon placeholder for sites without favicons. A small tweak that frees up some extra room for the title.


Menu Panel and Customization

Redesigning the Firefox Menu

One size really doesn’t fit all with something as complex and personal as your web browser. Add-ons have always made Firefox a thoroughly customizable browser, however arranging things has never been a great experience out of the box.

But before we could tackle the customization behavior, we had to rethink the Firefox Menu.

The main toolbar is the primary surface for frequently used actions; while the menu is the secondary surface for stuff you only use some of the time. We wanted users to be able to move things between these surfaces so they could tailor Firefox to their needs.

For the updated layout we started with the idea of a visual icon grid. This grid nicely mapped to the icons already found on the toolbar and would ideally make moving things back and forth feel cohesive.

Larger 3×3 Grid with Labels—by Alex Faaborg<

The first grid we designed was wider, with smaller icons and no labels. This quickly changed to a three column grid with larger labeled icons. The updated layout served the same goal but was more clear and also less cramped.

Not everything we currently had in the Firefox Menu would translate directly to the new layout. We had to add special conjoined widgets—also known as “Wide Widgets”—for Cut/Copy/Paste and the Page Zoom controls. We also added a footer for persistent items that can’t be customized away. We did this to prevent users from getting into a broken layout with no escape hatch.

We had some serious debates about whether to use a an icon grid or a traditional menu list. The visual grid has some drawbacks: it isn’t as easy to scan and doesn’t scale as well with a lot of items. But the icon grid won this round because it was more visual, more inline with what we wanted out of drag-and-drop customization and had the side benefit of being touch friendly.

Some items from the Firefox Menu had submenus that could’t be easily reduced to a single action: Developer Tools, History, Bookmarks, Help and Character Encoding. Nested submenus hanging off of a panel felt pretty awkward. We had several ideas on how to handle this: inline expando-tray™, a drawer(interactive mockup—click History) and in-panel navigation.

We settled on what we call subviews(interactive mockup—click History). Subviews are partial overlays containing lists that slide in over the menu. Click anywhere in the partially visible menu layer to get back to the main menu—or close the entire menu and reopen it.

With the new menu layout Firefox should hopefully work just fine for most people out of the box. But by using the new Customization Mode you can really tailor Firefox to your needs. If you are interested in knowing more about why what is where Zhenshuo Fang wrote a great post about it.


Customize All the Things!

Now we needed to figure out how update Firefox’s aging customization experience. Things started off a little ambitious with the idea that we could combine toolbar customization, themes and add-ons into the same UI. This led to an early interactive demo (it does some stuff, hint: tools icon –> plus sign) to try and see if this would work.

This demo surfaced a few issues: 1) including add-ons was going to be complicated 2) we needed a direct representation of the menu panel instead of a proxy. This led to a bunch of mockups for a flatter interface sans add-ons integration. Eventually I made a second demo without the theme selector that is closer to what we ended up shipping. Then Blake Winton turned that into an awesome prototype that actually did something.

Final Customization Mode

The demos and prototypes helped us quickly get feedback from people on the idea. One of the complaints we heard was that it wasn’t obvious that you were entering a mode. We mocked up a lot of ideas for various ways to give visual feedback that you were in a mode and could now rearrange your stuff. We eventually settled on a subtle blueprint pattern and Madhava suggested we add some kind of animation with padding.


Wrapping it up

Thank you to everyone who dedicated so much time and effort into making this happen.

If you want to know more about the people and process behind Firefox 29, Madhava has a good post with an overview.

I think the post-release glow is over now. Time to get back to making Firefox better.

Cross-posted from here.

Try Out Fira Sans: a Free, Open Source Typeface Commissioned by Mozilla

Jennifer Morrow

12

As designers in open source, we’re constantly looking for opportunities to bring the principles of universal access and redistribution to new areas. While the term “open source” may still be mainly associated with code, the value in free collaboration benefits every discipline – particularly design.

In that spirit, the Mozilla Foundation commissioned famed typographer Erik Spiekermann to create a completely free, open-source typeface in 2013. Thus was born Fira Sans, a gorgeous san-serif font that looks great on the web. So great, in fact, that we’ll be using it in Firefox’s in-content pages such as Preferences and the Add-ons Manager.

fira sans preview

If you haven’t tried out Fira Sans, now’s a great time: version 3.1 introduces 16 different weights, a huge character map, and extensive language support. Also available is Fira Mono, a monospaced version of the original. Give it a spin on your next project!

Download Fira Sans 3.105 (3.6mb .zip)

Firefox’s Redesigned Preferences Feel More like the Web

Jennifer Morrow

12

Another great Firefox improvement is releasing soon!

Firefox’s Preferences, until now, have required navigation through a cumbersome floating window where it’s nearly impossible to find what you’re looking for. This window is a classic example of a common software problem: settings are slowly added onto the interface as new functionality is introduced, and eventually it sags under the weight.

The mess that is current Firefox Preferences

The mess that is current Firefox Preferences

Until now, that is!

The Firefox UX team is excited to announce that brand new, beautiful Preferences are now the default in Firefox nightlies and will soon be in release Firefox. In this redesign, the interface is visually consistent, the information architecture is improved, and the whole thing is rendered in content space rather than as a separate window.

Firefox’s new in-content preferences

Why is it important that Preferences are in the content space rather than a separate window?

  1. Consistency across devices. By using the content space, we no longer have to rely on the ability of a device to draw separate windows and dialogs. This is particularly important on tablets and phones, where window management is more difficult. Now, users of mobile Firefox will see a familiar interface when move to desktop Firefox, and vice versa.
  2. Consistency across operating systems. Windows, OSX, and Linux all create windows and dialogs differently, which means the user’s experience with Preferences was different depending on the OS. Now, as we draw this interface within Firefox, we can make it look and feel identical across systems.
  3. Consistency with the web. Ultimately, the browser is a doorway to the rest of the web. For the browser to behave like a dialog-heavy desktop application rather than the web itself was jarringly anachronistic. Beneficially, rendering like a website also means users won’t need to find and manage a separate window in addition to their open tabs.
  4. Space to grow. Not being bounded by a small, floating window means we can create richer customization experiences. The Add-ons manager has already  moved to content space, and we’ve been able to explore richer use cases as a result. Similarly, expect to see innovative customization experiments as well as the usual Firefox settings.

And before you ask, yes, the next step is absolutely a search field in Preferences to summon the exact setting you’re looking for. This is needed particularly so users won’t have to “learn” our interface, but can instead focus on their task.

A special thank you goes to Senior Visual Designer Michael Maslaney, who’s been spearheading Project Chameleon, the style guide behind this redesign. Another thank you goes to MSU students Owen Carpenter, Joe Chan, Jon Rietveld, and Devan Sayles for creating the award-winning first version of Firefox’s in-content Preferences in May 2012.

The new face of Firefox

Madhava Enros

17

We shipped it!

Firefox 29 is winging its way to hundreds of millions of people as we speak, and it brings with it the set of changes we’ve been calling Australis: an interface streamlining, evolution, or complete overhaul, depending on who you talk to. It represents years of concepting, designing, building, testing, rebuilding and shipping. We’re extremely pleased and proud that it’s ready for you to use.

This is the most beautiful and detailed version of Firefox yet. Along with the immediately apparent visual improvements, I’m also really proud of the care and craft that’s gone into how the browser feels, especially the way controls respond as you use them.

Every bit of the new interface has been finely-tuned to be fast and simple. The forward button is only shown when it is relevant; the downloads button shows progress only when there is progress to show; the bookmarks button makes it clear where your bookmarks can be found.

I think I’m most proud of how simple and engaging it is now to spend time customizing the browser. The process of configuring a browser could easily have felt like a chore, but instead I think we’ve built it in a way that people will explore, enjoy, and revisit until they’ve really made Firefox their own.

This is also not a finish line so much as a new firmer foundation. Firefox’s new design provides a better more extensible interface model that will accommodate future features and additions. It’s a simpler presentation of add-ons as equals to built-in browser features. And it finally brings us a familiar look and feel across all our platforms so that Firefox feels like Firefox everywhere.

For those of you interested in how we got here, the Australis redesign was shaped and focused by our Firefox Design Values. While they all come into play, certain of them were particularly relevant here.

The You help make it and Balances power and simplicity principles flow into customization as a top-level priority. That balance is different for everyone, which is why we feel it is important to give you the choice to make Firefox yours.

The Finely crafted and High user performance principles come in the detail and care we put into the browser’s look and the efficiency with which you can use it.

The animation in interactions like bookmarking is an expression of our Exuberance value. There’s a liveliness to the way the controls respond and explain what’s happening, as in way that the browser resizes when you enter the new customization mode.

There’s a lot to say about the particulars of the design, but others are already doing this extremely well. Here’s a list of other design posts, which I’ll keep up to date.

Further design writing on Australis and Firefox 29

A huge heartfelt thank you to all the Mozillians who helped to make Australis real — we’ve been looking forward to this day for a long time. And thank you, everyone, for using the new Firefox!

The Experience of Mind Reading

Tony Santos

Building an experience around recommender systems

When you think about shopping on the web, or watching movies on the web, or listening to music on the web, or doing pretty much anything on the web, at some point most of us expect that “the web” will make some suggestions on where it is we’re going, what we’re watching, listening to, or buying. These suggestions can take the form of ads that follow us around for days at a time (creepy) or quiet little “people who looked at this also looked at these things” sections of a web page. How computers figure out what we want and when we want it is a black box of magical math and statistics for most of us, myself included until just recently.

Let’s read peoples minds!

A few months ago the Firefox Marketplace team decided to start exploring what it would mean to add a recommender system to the Firefox Marketplace. System-generated recommendations are something we’ve talked about before, and this time we had the help from a fantastic team at Telefonica Labs. They built a functioning prototype of a recommender system for the Marketplace that performed “better than popular,” the gold standard against which all recommender systems are compared. We had the engine, we had the statistical analysis, but I was curious about how people would perceive the system, do people actually think it’s better than popular recommendations after using it?

A peak into the magical black box of recommendations

Before I even attempt to (poorly) describe any of the magic that allows computers able to recommend things to people, I want to stress that I am a complete novice in this field. There is a fantastic slide deck you can view put together by Alexandros Karatzoglou, one of the super-smart researchers we are working with at Telefonica Labs. It is a much better intro to recommender systems than what I’m about to write.

recommendationExample-1

Basically, if we know how enough people feel about a couple of things, and those feelings overlap, we can make pretty good guesses about their feelings about things; as long as some of them have seen these other things that the others have not.

To be clear: we are NOT collecting any data on any Marketplace users at this time. Future recommendations in the Marketplace will be an opt-in, and we will be very clear on what data we would use and how.

Setting up the test

We set up a front-end for the recommendations engine by modifying the existing Marketplace UI slightly to repurpose it for the test. The problems we identified and wanted to explore were:

  • How do users perceive the “cold start?”
  • How do “real unbiased” preferences perform in the engine?
  • How do weighted preferences perform in the engine?
  • What are user’s reactions to “Recommended Apps?”

We built a prototype that displayed 21 popular apps. These were presented as “Recommended apps” and we asked a series of questions to rate a user’s perceptions of these apps as her initial recommendations. This scenario is the “cold start,” where we don’t have any information to make recommendations with. We then asked the participant to press the next button. She was presented with a list of apps and asked to select 10 apps that looked interesting to her. We used these interests to generate a “new set of recommendations,” this time, actual recommendations. The final step is to present the participant with the same set of questions we asked in the beginning, to see if the real recommendations were perceived as better or worse than the popular apps list.

A note on “real unbiased” preferences vs “weighted preferences” that I mentioned above: I made this distinction early in planning the test unaware of just how much it would affect the results because I had no idea how the recommendations engine actually worked. You may be asking yourself “wouldn’t this be biased and unbiased preferences?” and maybe even “aren’t all preferences inherently biased?” These are both good questions, so I want to define the terms as I used them in planning the test.

When I say “real, unbiased preferences” what I mean is letting people choose apps that are interesting to them without the influence of popularity. This may seem silly if you are familiar with the Firefox Marketplace because all of our listings default to a sort by popularity. The intention behind it was to simulate someone with eclectic tastes or who is finding things that are less popular, but are a strong representation of that user’s interests nonetheless. To simulate this effect, we took the whole Marketplace catalog, sorted it randomly and presented it to participants. This gave an equal chance of users finding a popular app or a relatively unknown app when they were choosing their preferences.

When I say weighted preferences, I’m simply referring to preferences participants shared with us from a list sorted by popularity. This is an important distinction because I wanted to be able to account for real preferences, which could be very unpopular but very informative, vs satisficing behavior, which I initially believed to be potentially less informative.

It turns out both of these decisions have very real consequences on how the engine works, and those showed up in our findings.

What did we learn about mind reading?

Satisficing is ok

On our first day of testing, we used the “real unbiased preference” method of collecting preferences from our participants. I point this out because it turns out that the engine doesn’t really know how to deal with unpopular things, and the recommendations that came back were…off. Linus, another one of the researchers, explained it to me as “When the engine doesn’t know anything about an app, because no one has downloaded it or very few people have, all it can do is give back random results.” And indeed that’s what we were seeing. This is an important point and I bring it up to highlight something I learned while testing these kinds of systems with real people. My attempt to control against satisficing was totally incompatible with the recommendations engine, because satisficing is kinda how recommendations work. To account for this, we switched the list of apps we provided to a list of 250 popular apps, cutting off the top 100, sorted randomly. The recommendations we started seeing in the additional tests started making a little more sense, statistically and preferentially, than the randomness we saw in the first batch.

Catalog Counts

Overall, we found that the depth of the catalog is a major factor in people’s opinion of recommendations being “good.” As I went back and looked at the apps recommended, based on the preferences we collected, a lot of the recommendations were actually pretty good. The things recommended were similar types of apps in a lot of cases, which I felt was what the recommender was supposed to be doing. The overall goal of the recommendation s is to offer you something similar to the other things you like because you’ll probably like the recommended thing based on that similarity. This didn’t seem to overcome the vast majority of “unknown apps” in the results though, and it seems that if participants didn’t recognize at least a few of the apps in the list, they talked about how they didn’t think the recommendations were very good. There appears to be a level of familiarity expected from recommendations on the Internet. This leads me to believe that some kind of justification, (e.g. “this recommendation is based on”) is important when making recommendations of less popular items. This explaining why a recommendation was made is extra important for less “tech-savvy” users, who seem to be far less patient with having to do a lot of exploration. We’ve seen this disinterest in other studies and the trend held true in this study, users with reported lower levels of computer proficiency clicked into app details less often to explore the catalog.

Labels are almost as good as the real thing

Of the 12 total participants who successfully completed the study’s tasks, seven of them took the initial list of popular apps as “recommendations” simply because that’s what the label said. Five of those seven mentioned an assumption that we knew something about them based on their browsing history. Three of those five used that assumption to explain why the “recommendations” they saw on first load where good. The other two used it as justification for a complaint about the recommendations, that they should be better than they were. This is interesting and important because it turns out just by calling something “recommendations” it can make people assume you’ve been profiling them somehow.

What’s next for the Firefox Marketplace

Overall, this study was enlightening and we’re now exploring how we can add recommendations into the Marketplace in a way that is useful, fun, and not creepy. We aren’t sure what that means yet, but expect to see some more writing (and pictures) around this topic soon. If you’re interested in contributing to this Marketplace project, reach out and let’s talk. There is still research and design to be done.

I’d like to thank the awesome team at Telefonica Labs, Alexandros Karatzoglou, Linus Baltrunas, and João Baptista for hosting us and helping us make this even a possibility. I’d also like to thank my awesome coworkers David Bialer and Rob Hudson for their help and future work getting us to this point on this feature.