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.
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.
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.
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.
To stay true to these values, we don't need a rigid design process.
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.
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.
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.
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.
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.
Having these use cases in mind, we can extract clear goals for what Panorama should be according to this data.
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.
Organizing tabs is meta work. It should be possible, but the focus shouldn't be the activity of organizing itself.
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.
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.
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.
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.
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.
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.