Back to my Resumé

Firefox Tab Spaces
Rethinking Panorama

Panorama (a.k.a. tab groups) is a great feature. Whenever I tell someone about it, people love the idea.
But I think it can get even better.
Let me show you how.

Try the prototype!

Why change the status quo?

It forces organization

Organizing tabs is meta work. If we could completely eliminate it, we should. As that is currently not possible, we should at least not request more decisions (position of a group, size of a group, name of a group) than are absololutely needed. Instead, let's focus on quickly getting to the pages while maintaining a great overview.

It is hard to access

Right now there are two ways to access panorama: clicking a small icon and using a keyboard shortcut. Especially when the main activity becomes is tab switching, that is probably not enough. By introducing a double click on the tab bar as a trigger for tab spaces, we can utilize the natural flow of the user when searching for tabs, and also make use of Fitt's law.

My Process:
The UX Framework

There are as many design processes as there are designers out there. But when we break them down, we can see three core values of User Experience Design.

It's not about technology,

it's about people.

It's not about process,

it's about results.

It's not about getting it right on the first shot,

it's about speed.

To stay true to these values, we don't need a rigid design process.

We need a UX Framework.

Business Goals In every project, some business goals are involved. It is our job as designers to bring them in line with the goals of the user.
User Goals User research and user modelling informs us about the needs and desires of the people we are beholden to.
Requirements Different contexts have different requirements and we need to be aware of them. A desktop app is different than a mobile app or an embedded system.
Functionality What does it do? The answer to this question should be based on the user goals.
Interactivity How does it work? What are the actions a user can take and how does the system respond?
Visuality What does it look like? How are the interactions communicated? How is information presented?
The Prototype This is what it's all about. In the UX framework there is always a prototype. It starts out with a very low fidelity so that we can iterate our way up towards high fidelity. Always having a prototype means always having something real to talk about.
Inspections We can inspect our prototype by testing it against heuristics or guidelines. This is fastest method of evaluating a concept.
User Tests Because we always have a prototype, we can continuously do user tests and see if our concept matches the expectations.

Move your mouse over the icons to see descriptions

I created this framework together with my friends at envis precisely and it has been a great guide through our projects. The key is that there is no step by step process. Instead, it is a map of the variables we need to consider in order to design for great user experiences.

Use Cases:
Building the right thing

What do people actually use or want to use panorama for? Researching forums, Bugzilla, Telemetry and questioning some people around me, I have identified these use cases.

Organize huge amounts of tabs

Users reporting this behavior mostly had permanent tab groups with permanently opened tabs. They invested time organizing those groups, so losing one of them would be unacceptable.

Finding an opening tab visually

This is what most people think panorama is, when I tell them about it. The grouping feature is mostly a second thought after the »I need to find that tab with the yellow header« use case. In addition, telemetry shows that almost 60% of people using panorama only have one tab group.

Clean up tabs

When users have opened a great number of tabs, it becomes harder and harder to get rid of the ones they don't need anymore. So they use Panorama to get a better overview and selectively close tabs.

Notice how only one of those use cases actually utilizes the grouping functionality.
The others mainly see Panorama as a tab overview and switcher.

Design Goals

Having these use cases in mind, we can extract clear goals for what Panorama should be according to this data.

Easy in, easy out

People use panorama as a task switcher (whether that was intended or not). So getting in, finding a tab and then getting out again must be fast and easy.

Don't enforce organization

Organizing tabs is meta work. It should be possible, but the focus shouldn't be the activity of organizing itself.

Manage groups effortlessly

Some people just have gigantic amounts of tabs. Those are the people who really need groups. So it would be great to provide them with a way, that makes working with many tabs just as effortless as working with a few tabs.

Sketches

My first steps towards a solution were a series of sketches. I always try to start with smaller features and then work my way towards the big picture. That way, I can get familiar with a problem and don’t have to solve everything at once.

Various sketches that helped me understand the problem and the possibilities better. As you see, some ideas were quickly discarded, others were continually refined. The sketch in the top right corner was the last one.

I quickly discarded the spatial organization that panorama currently uses. While it is easy to find a tab spatially, there is a big decision toll associated with the process of laying out the various groups on the canvas.

I wanted to preserve the benefit of spacial recognition while getting rid of the organizational overhead. Fortunately, this can be done rather easily by laying out the groups automatically (and in just one dimension).

I also got rid of the idea that tabs in all groups must be visible all the time. This would only be useful, if people switched frequently switched between groups. While I couldn’t find any hard data on this behavior, people on various forums were mostly talking about how they use tab groups as workspaces. This, combined with the fact that most people have only one group, means that most switching happens within a group and not between them.

Wireframes

After finding a general direction with sketches, I get into the pixels with wireframes. The main point of this is that sketches can be deceitful when it comes to space and font sizes. Wireframes let me see if everything still fits.

Static Wireframes

Again, I try to take the fastest path towards reality. That’s why I don’t use a special wireframing tool (which would probably trick me into caring for symbols, masters and interactivity). I just use Keynote an copy & paste my way towards a better solution.

As you see, the wireframes are not just a pixel version of the sketches. Some new ideas only come to mind when getting down to pixels.

Animations

Wireframes are a good start, but they are static states with little context. That's why I sometimes, create little animations which double as half-functional prototypes – so evaluate what is happening between the panels.

In this case, I just quickly animated the transition between the regular view and the tab overview. Easy enough to do in Keynote.

Prototype:
Because nothing beats reality

The first shot of this concept is ready for prime time! Combining all the observations and ideas so far, I created this little prototype. This way, we now have something that can be easily communicated and easily tested.

Try the prototype!

Let's recap

Alright, Mozilla. You've seen how I work.

Let's do this.
Together.

hey@philippsackl.com

Back to my Resumé