As you may know, Apple’s new operating system, Mac OS X Lion has just been to be let out of the cage. So far, the operating system has been gathering both positive and negative press. Notably, Gizmodo has called Lion Apple’s Vista, while Paul Thurrott over at Supersite for Windows sound reluctantly positive about it. On App Store, users are giving it mostly top grades, with about 8% of users rating it three stars or below.
Looking at the comments associated with the scores, most people who are critical are complaining about stability, compatibility of applications they are using, or performance problems. However, a small number are having problems with the new, gestural ways of interacting with the OS. One user in particular wrote, “Why do I need to learn to scroll in reverse when I’ve been scrolling the other way for the last 20 years?”
I installed Lion the other week, and so far it strikes me as being quite good. Having said that, I do agree that it comes with a new set of problems, most of which have to do with the mixing of old and new interaction paradigms.
This is not a review of Mac OS X Lion, but rather I’m going to explore one particular issue I found when using the operating system, and suggest a solution.
Full screen bliss(?)
With this version of OS X, Apple has focused on marrying the direct manipulation paradigm of iOS to the more traditional desktop interaction patterns. Among other things, this brings the notion of full screen apps to the desktop.
Most of the time, full screen applications work really well. Mail, iCal and iPhoto are applications that feel particularly well suited for using the entire visible area of the screen, as the content they display scales naturally to use the larger screen space.
Browsing the web using Safari on an Apple Cinema Display, however, is an example where full screen should, but doesn’t, work very well. Observe.
Safari in full screen mode works fine on a laptop display, but that experience doesn’t scale well. On a larger screen, the UI becomes quite difficult to use. Above all, I found it difficult to work with tabs on a screen that large. The tab bar is the 20 pixels thick blur just beneath the address bar in the picture above. Trying to click it is just about as close to playing darts with a mouse pointer as you can get.
The problem that Safari suffers from is very similar to the problem that responsive web design aims to solve. Responsive web design suggests that designers and programmers should explore ways of creating web sites that scale dynamically to virtually any screen size, from a smart phone to a high resolution desktop display, instead of creating web sites that only fit a certain resolution (or a small span of resolutions).
As users start to expect that the applications they use to behave well in full screen, and full screen can mean many different resolutions, it may be that we have to start exploring the notion of responsive design more thoroughly and apply it to desktop apps the same way we’ve started doing with websites.
Redesigning the browser window for full screen
So, when designing applications, we’re facing a problem with screen sizes and resolutions. When it comes to the web browser in particular, the user interface hails back to the days when you had to give up your first-born son for a screen that was roughly the size and resolution of a Rubik’s cube. You couldn’t really afford to make the tab- and address bar any larger back then, and the interface has progressively grown more minimalistic, even as screen sizes have increased.
That being said, the experience with Safari on the Apple Cinema Display suggests that we may have reached some kind of turning point with regards to the minimalism of the web browser UI.
Of course, screen sizes do still matter when browsing the web. Since many web sites will be longer than your screen is tall, the less user interface we put vertically, the better. But most screens today are widescreens, so why are we not putting the left and right hand sides of the screen to better use, instead of forcing everything into a bar on the top of the window?
Modern browsers will throw a number of things at you to keep in the left hand side of the browser window: history bars, bookmark bars and most recently the reading list in Safari in Lion, but maybe the space would be put to better use as a tab area. Bookmark bars and whatnot are far less commonly used than tabs. I realize that this is not a new idea, but for some reason it doesn’t seem to have caught on.
In order to explore how a left hand user interface might look and behave in a web browser, I decided to do some mock ups in Antetype. Be warned, this is going to get quite detailed (my apologies in advance).
I’ve been using an iOS / OS X-ish graphics style for this one (since I’m on a Mac), but don’t get too caught up with that. The concept ports to Linux, Windows and BeOS just fine.
The mock ups
This is what I came up with. Click to view larger versions.
Let’s zoom in a bit.
There are a few benefits to keeping the tabs to your left, other than freeing space vertically. First of all, we can make the tabs themselves a lot bigger while still being able to fit a whole bunch of them in a single browser window, especially if we’re talking full screen windows like in Lion.
Secondly, the increased size gives us an opportunity to enhance the tabs with graphics and descriptions that make them easier to pick out from the surrounding tabs. They’re no longer indistinguishable grey blurs lodged between other indistinguishable grey blurs.
If the colors are perceived as too distracting, it might be sensible to give the user the option of fading the tab bar a bit when it’s not in use. Similarly, it could probably be made compact or disappear entirely.
No more address bars
As you can see, I’ve taken the liberty of hiding the address bar. Well, it had it coming, didn’t it? Reportedly, Google has been experimenting with this as well.
After you’ve typed an initial address, how often do you change it? Navigation is usually done by clicking links and the occasional enter-stroke in a password box once a page has been loaded, so changing the URL should be something of a fringe case. Of course it needs to be available upon request, such as when you press ⌘+L (that is CTRL+L on Windows and Linux).
New tabs
New tabs could be created as you would expect: via a keyboard shortcut or by clicking the “New Tab” button. You can type a website address or something you’d like to search for.
I think in this day and age, it makes no sense to keep the address bar separate from the search field. Whether I know a specific address or just the general terms of what I want to find, they’re just two different starting points to the same end goal. So let’s unify them as some browsers out there have done.
In this case, we’re searching for “ux design principles”, because that’s what the cool kids do nowadays.
And the results.
Other details: Notifications, descriptions and names
Notifications. You may have noticed the number boxes right next to Facebook, Twitter and LinkedIn. They’re notification counters. Let’s face it: web apps are here to stay, at least for the time being.
There are a number of web sites out there that change and update interactively as you are using them, or even when sitting in a tab in the background. Let’s give them a unified way of notifying you that something has happened. In the case of Twitter, it would be the number of times you’ve been mentioned while Gmail might use it to display the number of unread emails.
Descriptions. In most cases, the subtitle or description of a tab is simply however the site owner would choose to describe the site, though in some special cases the browser might decide to use it for a better purpose. In the case of the Google Search tab, the browser makes the search phrase stand out in order to make it easier to find among other, similar tabs.
Names. Much of the time, the primary piece of information on a tab is the site name. This is not always the case, however. When you’re reading an article, the article title is the more important bit of information, making the site name secondary. This should be reflected on the tab.
To my knowledge, the HTML standard makes no separation between the notion of page name and site name. That’s why you’ll see titles like The Medium Is The Message – Smashing Magazine, for example, where the two pieces of information are made into one line of text.
I don’t mean to say that Smashing Magazine is doing anything wrong when formatting the page title like that. In fact, it’s good, because in most browser tabs you’ll only see the first bit (because of the size of the tab).
If the title had been Smashing Magazine – The Medium Is The Message, you would not be able to read the entire title, and would therefore be unable to distinguish that article from the other Smashing Magazine articles you may have open at the moment.
Hence it may make more sense to separate the two pieces of information and let the browser sort out how to display them. If the site name (which is permanent throughout the site) could be set to be different from the page name or article name (which changes from page to page), the browser could make intelligent decisions on how and when to display the two.
In the example below, I’ve attempted to demonstrate what a tab might look like when the article name is primary, and site name secondary.
Using tab groups to support the notion of contexts
Let’s take a break for a moment and consider the human nervous system. In particular, let’s talk about contexts, a model that is particularly useful when understanding how people organize information.
All of your emotions, memories and experiences are stored contextually (goes the model). If you’ve ever noticed that happy memories are more readily available to you when you are happy, you’ve noticed the contextual nature of the brain in action.
You can think of a context as the setting, or mode, your nervous system perceives itself to be in. When in a particular “mode”, certain information will be more readily available to you than the bits of information that the brain perceives to be less relevant (that is, further removed from the current context).
The further removed the information is from the current context, the harder it will be to access, up to the point where it is more or less impossible recollect (as seems to be the case with some people who’ve had traumatic experiences, for example).
In UX design, it’s useful to understand how people organize their experience into contexts. It’s also useful to know what is important to users in a particular context, and how they go about switching to another context. This way you can remove anything not relevant to the current context and focus only on what is important to the person right now, while still helping the user to quickly switch to another context if required. This is usually a far better strategy than creating a huge interface with everything in it, in which case the user would have to handle context switching internally only, with no help from the interface.
Modern browsers are quite bad at handling contexts. For example, I may start a session looking through the social networks I participate in and then move on to looking for design related web sites. These are two completely different contexts for me, but the browser has no way of knowing that.
At the end of a day, I’ll have half a dozen contexts or more going in a browser, at which point it’s usually a mess of tabs. I’ll close the window and start over, rather than having to sort out the tabs.
Mozilla has been experimenting with tab groups as a way of representing cognitive contexts, but I haven’t found their solution to be particularly intuitive. Perhaps I’m not alone in that, as the first hit on Google when searching for “Mozilla tab groups” comes out of their own help section and is a page called “Where are the tab groups?“. I do think they’ve got the basic idea right though, it just needs a bit tweaking.
Tab groups, left hand style
I think we can leverage the design of the left hand tab bar design and enhance it to manage contexts. Grouping tabs is probably a good way to do it, but let’s make it intuitive to use. Drag one on top of another to create a group. Perhaps something like this:
You’d get an opportunity to name the group, with the browser starting you out with its best guess (more on name guessing later). It’d be called Social Networking, perhaps. Notice how the Facebook and Twitter counters are summarized into a single counter as well.
When expanding the group, it’d probably be good to remove or fade out all superfluous information.
Let’s go ahead and add LinkedIn to the group as well.
After that, perhaps we’d create a group out of Smashing Magazine and Daring Fireball as well. Let’s call the new group Design.
Now we’ve got somewhere to put all the interesting stuff we’re going find from the search on “ux design principles”, and there’s no way of getting things mixed up with the tabs in Social Networking.
Closing the groups gets them out of the way, so you can start building another context (browsing another topic) without them interfering much. The counter on Social Networking will continue to update in the background.
Saving groups
If you take the time to group these pages (and even name them), you’re probably quite interested in the content. In fact, it’s quite likely that you’d want these contexts to span more than one browsing session. And do you want to recreate them each and every time you restart the browser? No.
Perhaps there’d be some way to save them. For example:
For lack of a better word, I’m calling the top bar the group palette. The reasoning behind the group palette is that you may wish to save groups, but you may not want to display all of your groups in the tab bar at all times. So they need a permanent place to be stored, where they can be selectively retrieved upon request.
When you drop the group in the group palette, it would be saved permanently, until explicitly removed. All changes done to the group from then on would be reflected automatically to the saved version. It would have it’s own little time machine (history) so you could revert it to any previous version without much effort at all, or use it to find any tab that has ever been part of the group.
We can continue saving groups like this.
Both groups saved.
Saving by default?
It might be the case that just creating a group should save it. If I’ve gone to the effort of creating and naming it, it’s quite probable that I intend to keep it. I don’t know this for sure though; it’s difficult to make guesses about sensible defaults without actual user testing.
In the cloud
The groups should follow the user around. Remember; they are contextual to the user not to the browser. There would be several benefits to syncing the groups to the cloud (apart from them obviously being available to everywhere with no additional effort).
Group name guessing
On the backend, the browser developer could treat group names as tags applied to the sites contained within the group. Over a large number of groups saved, the most common group names would emerge. This could be used for a number of purposes:
- Have the browser guess the name of the group based on its contents. The browser would transparently get better and better at guessing group names as more groups are saved by users everywhere.
- Enhance search engine results.
- Suggest additional pages and other resources, based on what’s already in a group. Upon request of course – no badgering the user, please.
Finally (not)
These concepts are not final. I have a whole laundry list of interaction design related question marks that arose when making these sketches, most of which can’t be ironed out without at least a modicum of user research. There are probably a whole bunch of edge cases and interaction gotchas I haven’t considered yet, as well.
It’s hard to predict how people would use the groups, for example. Would they, for one, feel inclined to share the groups or collaborate with other users? I’m not sure. Some browsers have tried to integrate social features before, and most of the time it hasn’t worked very well (in my opinion).
I think the basic interaction patterns of this solution would transfer quite well to the iPad and similar devices. The left tab bar could be shown using a two- or three finger swipe to the right, while the group palette would be revealed with a similar downward swipe.
The basic look of the UI needs to be developed as well. I’m unsure of the best way to represent groups for example. I tried a number of alternatives, such as this:
I remain undecided on this. But I’m not a graphic designer; I’m sure that there are vastly better ways of doing this.
Get in touch
If you have any feedback or criticism, and would like to get it off your chest, you can find me on Twitter under the handle @henrik_eneroth or send an email to henrik.eneroth@antrop.se. Or you could simply submit a comment below.
The mockups were 98% made in Antetype, with image formatting done in Pixelmator or Photoshop and a few bits and bobs from Omnigraffle thrown in.
Many thanks to Robert Lundberg for providing me with feedback and suggestions while developing this.
