13 / Browser
Firefox Mobile 1.0.
The problem
Firefox on the desktop had a clear idea of what a browser was: a row of tabs, an address bar, menus. None of that fit a phone, and it fit a 10-inch tablet only by accident. People were already browsing on touchscreens, and they were doing it in browsers that had been designed for those screens from the start.
The work had a practical difficulty on top of the design one. The engineers building Fennec were scattered across the world, so there was no hallway to walk down and no whiteboard to share. Every decision about a gesture or a tab had to survive being written down and read in another time zone. Tablets and phones also had different shapes, and a single design would not stretch to cover both.
Success meant a browser that felt native on a touchscreen, and a design the engineering team could build without waiting on me.
The approach
Madhava Enros and I shared UX lead on the tablet UI, and I owned gestures. I drew the concepts, then built prototypes people could touch, then wrote the design down in a form that travelled.
- 01
Requirements and sketches
I wrote the product requirements and drew phone and tablet side by side on one page, with every part labeled. A phone has no room for what a tablet can show, and putting them next to each other made the differences concrete. The tablet sketch gave tabs a panel and put the menu items in a list.
Conceptual sketches for phone and tablet. - 02
Tabs in the Sidebar on a phone
My central concept was keeping tabs on screen. On a phone, I built a prototype where open pages sit behind a control on the left edge and settings behind one on the right, with Site Options, Preferences, Add-ons and Downloads in a grid at the bottom. It was a rough build, and it was enough to feel the swipe.
First phone prototype of the Tabs in the Sidebar concept. - 03
The tablet version
A tablet has room, so the tab panel could stay open down one side. I moved the concept to a tablet held wide, with the toolbar across the top and a Tabs control at the corner. The decision was to give web pages most of the screen while keeping every open tab one tap away.
Tablet version of the Tabs in the Sidebar concept. - 04
Gesture prototype and motion
Gestures are hard to describe in words, so I prototyped them and added motion design to show how each should feel. How a panel opens, how a tab answers a touch, how quickly a page settles. Engineers could play the prototype and match the timing instead of guessing from a spec.
Title card for the tablet gestures prototype. - 05
Labeling the interface
For the distributed team I made annotated overview diagrams. Each control got a name and a one-line description of what it did, and Awesome Bar, Site Menu, Action Menu and Tab Panel all got defined. A shared vocabulary meant a bug report from one country could be understood in another.
Fennecomb v9.0: interface overview with labelled controls.Mockup by Brian Dils, from the Fennecomb (Version 9.0) album on Flickr. Source: Flickr ↗ - 06
Keyboard states and reading mode
The on-screen keyboard fills nearly half a tablet held wide, so I drew how the Awesome Bar and its suggestions sit above it. I also explored a magazine-style reading mode, triggered from a button in the toolbar, for people who wanted an article without the rest of the page.
Fennecomb v9.0: typing in the Awesome Bar.Mockup by Brian Dils, from the Fennecomb (Version 9.0) album on Flickr. Source: Flickr ↗
The solution
The tablet interface kept the web page large and put everything else along the edges. Navigation controls and the Awesome Bar, which combines the address field and search box, ran across the top. A Tab Panel stayed in view down the right side, showing a thumbnail for each open page, with a New Tab control at the bottom. The Action Menu held what did not fit on the main surface.
The design idea was permanent, visible tabs. A person never had to open a menu to see what else was open, and closing a tab was one tap on its thumbnail. Gestures built on top of that, so the layout gave people a map and the gestures were the shortcuts.
What I delivered
- Product requirements for phone and tablet
- Concept sketches and wireframes
- Tabs in the Sidebar prototypes for phone and tablet
- Tablet gesture prototype with motion design
- Annotated interface overview for the engineering team
- Keyboard states and a magazine-style reading mode
See it working
Value added
For people using it
Open pages stayed visible and a tap away, and the web page kept most of the screen. People used gestures that had been tried on a real device before they were built.
For the business
Firefox had a tablet interface that suited 10-inch Android devices and fit the platform. It gave Mozilla a credible answer on a screen size where the desktop browser had no good answer.
For the team
Annotated diagrams and prototype recordings let engineers in different places build from the same picture. Questions about a control could be answered by pointing at its label.
The result
Covered tablet gestures, the Tabs in the Sidebar concept, an interface overview, a magazine-style reading mode and keyboard states. Mozilla's wiki lists me with Madhava Enros as UX lead on the Fennec tablet UI. It also lists the areas I owned: gestures, interim tablet improvements, first-run language choice, first-run discoverability and accessibility.
What I took from it
For a team with no shared room, a labeled diagram and a short recording did more than any amount of meeting time. I would produce those two artifacts first on any distributed project, then use calls to discuss what they got wrong.
Background
Fennec was Mozilla's browser for phones and tablets, built on the same engine as desktop Firefox. Mozilla's wiki says the Tablet UI aimed to make Firefox work well on 10-inch Android tablets and fit the Android Honeycomb look. It landed for Firefox 9. The Register covered the preview in August 2011. It described tabs that stay on screen in landscape and a slide set by Madhava Enros and Brian Dils on how platforms differ.