It's been a few months now since we merged the mobile and desktop Firefox user-experience teams into one supercharged all-platform Firefox design juggernaut (in the good sense). In that time, we've been hard at work digging into the next set of features and improvements, as well as pursuing one of our major goals for the year: getting Firefox to feel more like one product — more Firefoxy — across all our platforms, desktop to tablet to phone.
I presented an overview of what we're working on at the Firefox Toronto Workweek last week. Here are the slides (and a direct link, just in case). I had a fair bit to say about them, so I'll be posting a video of the talk soon, but the mockups and wireframes in the slides are too awesome to wait. The team will be posting about each of these projects, individually, in more depth.
This presentation makes reference to the Kilimanjaro project, a set of short-term priorities around integrating the browser and ecosystem projects (identity, apps, marketplace) that Mozilla is working on right now. You can learn about it on the Kilimanjaro wiki page.
Many thanks to the team (see slide 2!) for all their hard work.
The mobile UX team's recently gone through a big top-to-bottom review of the in-progress native UI for Firefox on Android, sanding down rough edges and making sure that things all fit together. Here are some slides from a walkthrough I'm about to give of the current state of the designs. The nightly builds are getting closer to these every day!
Credit to Patryk Adamcyk and Ian Barlow for these mockups
If you're watching the nightly builds of Firefox on Android, you'll have noticed that a lot just changed. What you're seeing is the first wave of basic function and interface revisions as we rebuild Firefox as a native Android application. This is very much a work in progress — a lot is there already, but there's even more still to come. Oh, you can get it here.
What have you done to my browser?
Firefox, overall, is being rebuilt to be faster and more responsive. We wanted to match this with a rework of the UI that will make us feel quicker, more natural, and a better fit on Android. Our goals have been, primarily, the following:
We're still revising, tweaking, and, well, wholesale throwing things out and redoing them, so please pipe up with your suggestions, but here's what you should be seeing right now.
A simpler, Firefoxier, thumbier UI
What you'll notice right away, I think, is that the browser controls have been pruned back and, overall, they're laid out more simply. The browser is continuing on its path of doing things the Android way, whether that's through use of the system back button or standardizing on the Android menu system. Things should be where an Android user would expect to find them.
This consolidation has also let us put everything you frequently need under the arc of your thumb when you're using your phone in one hand; hopefully you'll seldom find yourself reaching and stretching, even as Ice Cream Sandwich phones get bigger and bigger.
Tabs are kind of a big deal
We've kept our Firefoxy focus on quick access to tabs, where you don't have to leave your current context to see and choose from what else you currently have open. We're also trying to leave you with better ambient sense of when tabs are getting created or closed, in the background or foreground, through the use of some subtle animations and transitions.
Pulling in visual cues from Firefox on tablets and desktops
The team has spent a lot of time looking at how we can have consistency across our many platforms. Firefox should feel familiar no matter where you're using it, even if the constraints of the particular device mean some structural changes.
We've had a lot of great feedback about the upcoming release of Firefox for tablets, and you can see that this new Firefox on phones is its close sibling.
There are also a lot of places where the phone UI references that of the desktop, like in the position of the new tab button (though it serves more purposes here), our icons and glyphs, and in certain UI elements like our notification "door hangers":
Optimized for Froyo / Gingerbread, and Ice Cream Sandwich
Of course, people out there are on a lot of different versions of Android, and we want to look right for all of them:
Coming Soon
All of that is what you can have in your Firefox-nightly-clutching hands today. But there's more! Here's what's in the UI-design pipeline, coming to the nightly build soon:
I need more stability in my life
If you like to wait for the new native Firefox to stabilize a bit more before you start using it, you can switch from Nightly builds to the Aurora release channel. You may particularly want to do this if you're using a Honeycomb tablet — the new Firefox tablet UI that everybody's talking about is stabilizing there, getting ready for final release later this year.
[with many thanks to Mozilla mobile UX designers Ian Barlow and Patryk Adamczyk]
A month ago I crossed the five year milestone at Mozilla, and my first post on this blog was exactly five years to the day. I’ve recently decided to move on from the corporation to try out design work in an entirely different space.
It’s been a tremendous honor working with all of you. Every top tech company has people who are brilliant, but few have people who are so warm, so kind, and so incredibly passionate.
This blog chronicles all of my design work over the years. I’ve recently posted a look at some of the crazier conceptual work we’ve done. I’ve also posted a talk I gave at PARC on the eve of the Firefox 4 launch that reviews why Mozilla exists, our design philosophy, and a comprehensive look at some of the specific principles that have guided the design of Firefox 3 and Firefox 4.
Some highlights from the last five years:
Firefox 3:
-Interactive design of the awesome bar
-Designed the one click bookmarking interface
-Art direction for every visual resource in the application
-Created an iconic form
-Managed a refresh of the Firefox icon
Firefox 4:
-Visual and interactive design of Sync
-Design of a new notification system
-Design of a new command structure with the Firefox button, leveraging usage metrics
I’ve spent 1/6 of my life working on the design of Firefox. For the past five years Mozilla has felt like home, and the people here have felt like family.
I’m incredibly proud of what we’ve achieved. It’s been an amazing adventure.
Other formats (all 720p):
I gave this talk at a BayCHI event at PARC on 3/10/2011. Steve Williams over at the CHI Conversations Network provides a nice intro:
“While much open source software suffers from poor design and usability, Firefox shines. What makes the Mozilla community different? With great branding, usability backed up by research but tempered by realism, and a powerful extension architecture, the Firefox web browser claims 400 million users. On the eve of the release of Firefox 4, Mozilla designer Alex Faaborg covers the unique challenge of coordinating user experience design in an open source community, important features of past versions, and the future of the Firefox interface.”
It was a fantastic opportunity to be able to give this talk to a large section of the Silicon Valley design community. Also looking into the audience and seeing Don Norman smiling was one of the more rewarding moments of my design career so far.
Design is a very lossy process, and there are a lot of good reasons why a piece of design work might not be released to users. Sometimes a design is cut due to the natural triage process of focusing on top priorities and trying to ship on time. Sometimes a design is cut because in retrospect, it really isn’t the best solution to a problem. And sometimes a design is cut because it was only intended to be a conceptual exploration, like all of the concept cars that are created to help shape the design of future products.
This post features some of the crazier concepts that we never rolled out, and highlights some of the stranger scenes that we have on the cutting room floor.
Nightly Build Icon
I provided art direction for this 2009 candidate aspiring to be the new nightly build icon. It was humorously rejected by the other product drivers for being “too dramatic.” I continue to contend that the planet is definitely forming as opposed to exploding, but as a still image, the trajectory of the continents is arguably up for debate :)
Visual design was done by Joy-Vincent Niemantsverdriet of Sofa. The objectives I gave them were to create an icon that visually conveyed danger and an incomplete product (at the time Minefield was still full of mines). I also wanted them to base the work on paintings like Castle of the Pyreness by Rene Magritte, or this image from the French anime Skyland.
Stealth Theme for Private Browsing
This is one of my favorite design ideas, but as a low priority feature it has also now missed every major release (Firefox 2, Firefox 3, Firefox 3.5 and Firefox 4). As an ambient, peripheral, and constant indication of being in private browsing mode (or ideally opening a private window), Firefox transitions to a dramatically darker theme. This is meant to invoke connotations of day/night, or for the more militaristic, a stealth fighter.
Visual design by Stephen Horlander. You can also view an updated mockup based on the Firefox 4 theme that he created as well.
Fluffy Pie Menu
Interactively this pie menu does what pie menus are good at, it provides visual feedback for a mouse gesture (in this case browser navigation). But what I really like about this particular pie menu isn’t what it does, but how it feels. It’s fluffy, it’s soft, it’s friendly. It’s like interacting with a happy cloud.
I provided art direction, and the visual design was done by Mozilla intern Wei Zhou. This design work was purely conceptual.
Immersive Full Screen Mode
Again purely conceptual design work, this was an immersive full screen mode, where the site’s aesthetic dominates the entire browsing experience. Visual design was done by Mozilla intern Wei Zhou. To correctly build this type of overlay various Web sites would of course need to be expecting it, which is a technical challenge. This design work did however later inform how we approached overlaying the browser’s control scheme on top of personas in Firefox.
Bugzilla Theme Refresh
I spend a significant part of each day living in bugzilla. As you can imagine, I’ve had some time over the years to daydream of a more elegant and streamlined interface that is easier for users to very quickly visually parse.
As an advanced tool for organizing software development, bugzilla isn’t meant to be simplistic. It’s like a DLSR camera, consisting of a dense set of controls meant to be quickly and easily accessible to highly trained users.
But that doesn’t mean that users (including the highly trained ones) should arrive at a bug, and have absolutely no idea what is going on. This redesign of bugzilla uses color exclusively to represent value (positive, negative, in transition). This makes it easy to figure out the current status of a bug (status, assignment, commitment) at a broad glance, including peripheral vision.
Additionally, while it keeps controls in a mostly consistent position for the thousands of users already acclimated to interacting with bugzilla, this design provides enough visual structure to organize areas of UI around the core journalistic questions (what, who, when, how). This makes it easier for users to answer specific questions about a particular bug.
The design focuses on clean stark lines, and emphasizes data (like bug summaries) over metadata (like bug numbers).
Many of the same design principles were also used to redesign the interface of HTML bugmail messages.
Command Blocks
This was an exploration of how we could turn the location bar into a sort of modern graphical command line, building on the work of Mozilla Lab’s Ubiquity project. We explored exposing the selection of various commands through both mouse and keyboard input, and providing rich results based on the activated command block.
This is a visual design for the command blocks that I worked on with Stephen Horlander:
Graphical Keyboard User Interfaces
These mockups are a series of explorations into creating graphical keyboard driven interfaces. Designed as accelerators for advanced users, these mockups re-imagine functionality that exists elsewhere in the browser. The resulting interaction is fast, transient, and provides keyboard users with a level of visual exploration and feedback that is uncommon to standard keyboard shortcuts.
Detailed post about the common tradeoffs between mouse driven and keyboard driven interfaces
Searching the Web:
Bookmarking and tagging a page:
Browsing your Personal Web
This is a conceptual redesign of bookmarks and history in Firefox that focuses on leveraging the core browser controls (location bar, navigation controls, content area), to blend navigating bookmarks and history with browsing Web content.
In this model, users can navigate to an existing collection of bookmarks using the location bar, just as they would navigate to a Web site:
These bookmarks then are displayed in the content area of the browser:
Read an extended discussion in a blog post about the idea.
Isometric Pixel Art for Prism Apps
Mozilla Lab’s Prism was created to frame Web applications as equals in the desktop environment. This quickly introduced a problem for the project: most Web applications only have a 16×16 favicon, and desktop applications, particularly on OS X, require icons that are at considerably higher resolutions.
Leveraging a nostalgia for the 8-bit age, I embraced the low resolution nature of favicons, and converted them into isometric pixel art. The image below is an actual screen shot as opposed to a mockup.
This was also one of the very few times I sat down and wrote some code to get an idea across. While a cool idea, the apps team at Mozilla is now defining a manifest file for applications to package their own high resolution icons, so the overall problem of only starting with 16×16 icons now no longer exists.
Conclusion
Those are the highlights of the design work that didn’t make the cut. In each case there were good reasons for us not to move forward, or just not to move forward yet. Even if these concepts never get deployed in Firefox, ideally they’ll spark even better ideas in the future.
Mozilla’s manifesto describes the internet as an integral part of modern life and a key component in communication. However, communication on the web has far to go before it’s as rich as face-to-face communication. Real-time video communication on the web should be easy, rich, and readily available to developers in a way that proprietary formats can’t be.
That’s why a new project is spinning up at Mozilla called WebRTC (Real-Time Communication). WebRTC will allow developers to use the web platform to include video and audio conferencing as part of their websites and applications, both mobile and on the desktop. In its first phase, WebRTC will make webcam feeds a primary object in the browser, allowing sites to create rich interactions such as video calling and conferencing. In later phases, WebRTC will allow interactions like co-browsing, in which users can share their screen with a friend.
Privacy and security are major concern in enabling open video communication on the web. A face and voice are two of the most identifiable kinds of shareable data, and keeping users in absolute control of who has access to them is vital. As the IETF states in its WebRTC draft document, the ability for users to control access to their webcam, be able to cancel communication at any time, and not be eavesdropped upon are essential.
Some of the challenges we’ll face are in giving users the most accurate information possible about the site and caller who are requesting access to their webcam. Most requests for webcam access will simply be from a trusted site itself, but a malicious site could potentially try to gain access by embedding its call request within a trusted site. In this paper, Eric Rescorla outlines how potential “ad-hoc” calling attacks could come from ads in iFrames embedded within trusted sites. Many other potential attacks need to be dealt with. For instance, because WebRTC would be controlled by a web server rather than conventional real-time systems, web browsers might expose JavaScript APIs which allow a server to place a call. If access to such an API were unrestricted, sites could “bug” a user’s computer and capture video camera activity (Rescorla).
Even a trusted site could be compromised, both during a call or after. And, since the sites themselves would control and display the UI of the call itself, Firefox needs to give the user both constant indication that they are in a call and the ability to disconnect at any time.
However, guarding against threats only goes so far towards keeping users in control of their webcam communication. Clear messaging, useful tools, and sensible defaults need to be in place for video conferencing to safely take root in the browser.
The first phase of enabling WebRTC will allow the most basic use case: giving a site access to a user’s webcam and microphone. The browser already serves as a mediator for other user data, such as location and access to cookies. Firefox usually asks for permissions using a door hanger notification. Door hangers stem from the URL bar to show the site is asking for a permission, and it extends past the content area to show that Firefox is the mediator of the permission request. Using a door hanger notification for WebRTC is both consistent within Firefox and correctly conveys visually that the site has requested access, and Firefox is asking the user for that permission.
Usually, these door hangers simply ask the user for a permission, and in a click the user can give it. However, webcam access requires a secondary stage: showing a preview of the webcam feed. This approach has three benefits:
In some ways, it’s unfortunate to ask users to pass through two dialogs to give webcam feed rather than one. After all, in most cases the site itself will be providing all necessary UI, and perhaps even a video preview before a call is initiated. So, this could all be redundant in many cases. However, we cannot predict what purpose a site may be requesting webcam feed for, nor what UI will be in place for the user on that page. Even with all our efforts against security threats, any request for webcam access must be treated as potentially malicious.
Once a user has given a site access to their webcam and is likely engaging in face-to-face communication, that interaction should be given a heightened level of priority within the browser. For a user to lose that tab or forget they are broadcasting could range from mildly embarrassing to, well, use your imagination. If a user is actively sharing their webcam feed, they should be able to jump to the tab where data’s being shared or simply cut their webcam feed from anywhere within Firefox. This will require at the very least a toolbar-level Firefox control that appears once a user’s actively sharing.
Designing and implementing a new API is always a complex process. If you’re interested in reading more or contributing to this project, here are some resources:
“No one wants to die. Even people who want to go to heaven don’t want to die to get there. And yet death is the destination we all share. No one has ever escaped it. And that is as it should be, because Death is very likely the single best invention of Life. It is Life’s change agent. It clears out the old to make way for the new. Right now the new is you, but someday not too long from now, you will gradually become the old and be cleared away. Sorry to be so dramatic, but it is quite true.
Your time is limited, so don’t waste it living someone else’s life. Don’t be trapped by dogma — which is living with the results of other people’s thinking. Don’t let the noise of others’ opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.”
Steve Jobs
February 24, 1955 – October 5, 2011
As the web evolves, so does the way people interact with the web. Firefox’s user experience and research teams have been eager to learn about our users’ browsing habits so that we can better design for our users. Lately, Mozillians like Lilian Weng and Jono X have been running some fascinating studies using Test Pilot to determine how, when, and why Firefox users open new tabs. I wanted to note a few key takeaways from their recent study that give us a glimpse into how our users browse (full studies are linked at the bottom of this post).
A caveat is that these results – as with all Test Pilot studies – are gathered using anonymized data submitted by users who have signed up to participate in Test Pilot. Thus, the Test Pilot users data tends to skew slightly towards the technical and early-adopter crowd.
Each day, the average Firefox user creates 11 new tabs, loads 7 pages from a new tab, and visits 2 unique domains from a new tab.[1] The average new tab loads two pages before the user closes or leaves it.[2]
Once users have a new tab page open, about half of the time (53%) they navigate to a new page using their mouse, and about half of the time (47%) they use the keyboard.[1]
Here’s a breakdown of what actions users take once they’ve opened a new tab:
As you can see above, the URL bar was the most-used item on a new tab page, with 53% of use actions originating there. The search bar only accounted for 27% of user actions. Even though by default it’s not even enabled in Firefox, 16% of new tab page actions were clicking on a URL in the bookmark bar. History and bookmarks menus were both used less than 5% of the time.
In this study, 17.4% of the domains recorded accounted for 80% of the page views for all participants. You might think that the more active a user is, the number of unique domains they’d visit would follow the same ratio. However, this study found that the more sites a user visited online, they more often they would visit the same 20% of domains. Turns out, the most active internet users are even more loyal to a few choice domains than their less active counterparts.[2]
[1]Quick report on new tab study, by Lilian Weng
[2]Test Pilot New Tab Study Results, by Mozilla Research Team
Design (mostly) updates for the last two weeks:
