Monthly Archive for May, 2010

Solving the real Alt-Tab problem

In his latest blog post, Aza Raskin – interface design guru, creative lead on Firefox, and son of one of my heroes, Jef Raskin – tackles one of my oldest bugbears, Alt-Tab. Aza is a clever guy, but I was disappointed that his post addressed an issue I don’t perceive as important, while failing to address what I see as the very real problems with Alt-Tab. But let me start with some background.

(I use both Windows and Mac every day, and in this post tend to use Alt-Tab and Cmd-Tab interchangeably.)

(EDIT: I originally gave the window-switching shortcut as Cmd-\ since I use an external keyboard, but I probably confused Mac users who know it as Cmd-~ (tilde). Updated.)

History (something Windows got right)

Windows had Alt-Tab since Windows 1.0, although it was only implemented in its familiar visual form since Windows 3.1 (1992). To this day, I know many people who never use the shortcut, but I personally cannot imagine using a multi-tasking operating system without it.

I found its initial absence on Apple Macs unacceptable. In Mac-based studios during the 90s, I always relied on a third-party extension, Task Switcher, to provide the missing functionality.

When Apple finally introduced native Cmd-Tab (in OS 8.5, I think), they at first got it wrong. It cycled alphabetically through running apps, rather than switching between apps on a most-recently-used (MRU) basis like Windows1, so I had to continue using the extension. They changed it to MRU order in a later OS update. (Thank goodness Microsoft didn’t think to patent it.)

Unfortunately, Macs still suffer from another difference which I’ll come to after the following interlude.

Interlude: Why is most-recently-used (MRU) order better than cycling (and Exposé)?

The first reason is obvious: If Alt-Tab simply cycled through open windows in a fixed sequence (say, alphabetically), it would just require far too much tabbing, on average, to reach the item you wanted.

But Raskin alludes to the more powerful reason: spatial memory. If the shortcut always switches to the most-recently-used (MRU) item, this quickly teaches you to make the switch without thinking or looking at the screen. Spatial memory is awesome because it’s a background faculty, not foreground. Like reaching for your mouse, it does not interrupt your concentration, or where you’re looking on the screen.

This “toggle” behaviour, using a single shortcut key to switch back and forth between two windows only, is worth mentioning as an important feature in itself. It allows the shortcut to be used to compare the contents of two windows, not simply to switch from one to another. (The Undo/Redo shortcut in Photoshop – Cmd-Z for both – also brilliantly uses this principle.)

So, MRU order allows you to switch between two tasks pretty much subconsciously. Personally, I have learned to switch between up to 3 apps without relying on the visual aid (i.e. using spatial memory alone). For switching between more than that I need to look at the interface, but MRU ordering still reduces the number of times I need to Tab.

The trouble with Macs

Cmd-Tab on the Mac works less well than on Windows, due to the Mac’s application-centric model, as opposed to the document-centric model of Windows. In Windows, for example, you can Alt-Tab between two emails, or two browser windows; on the Mac you can’t. To switch between application windows on the Mac you have to use a different shortcut, Cmd-~, which again uses cycling rather than MRU order. On top of that Cmd-Tab on the Mac has the annoying habit of bringing all an application’s windows to the foreground, often covering up the window you were trying to compare against.

I believe window-switching is closer to the mental model of what this shortcut accomplishes. The clue is in the original feature name: “Task Switcher”. It switches between “things I am doing” – I do not care about which applications they happen to be in. So to see it as an “application switcher” is to miss the point.

It’s also my theory that the deficiencies of task-switching on the Mac spurred the development of Exposé, which I consider a sticking-plaster solution. Exposé is nice, but it does not utilise spatial memory – it forces you to look at the interface.

I admit this is debatable: some people (to my amazement) find application switching on the Mac more natural than window-switching on Windows.

The real problem

As more and more applications adopt a tabbed workspace, Alt-Tab is becoming less useful regardless of which operating system you use. And this is especially serious with browsers, because more and more of our daily tasks happen in browsers nowadays. You’re no longer just “browsing”. Just as often you’re composing documents, managing your calendar, filing bug reports, etc. I often find myself automatically attempting to Alt-Tab between two things I’m doing, but failing because they happen to be in two separate Firefox tabs. And then I have to use the mouse.

In Windows I can improve the situation slightly by opening more browser windows. That way I can use a single window, say, for Google Calendar, one for GMail, one for the blog post I’m writing, a multi-tab one with lots of things I’m reading, etc. On OS X I can’t, since application windows can only be cycled through using Cmd-(Shift)-~.

The keyboard shortcut for switching tabs is usually Ctrl-Tab (on both Mac and Windows), but again, this cycles rather than using MRU. Interestingly, there are a few applications who opted to use MRU with Ctrl-Tab, e.g. oXygen (my favourite HTML editor.) I appreciate it enormously when using the application. Weirdly, Firefox occasionally seems to do this (uses MRU rather than cycling), but this is unreliable and I cannot get it to do so now.

Aza Raskin’s proposal

I’m disappointed that Raskin – evidently a lifelong Mac user – implicitly accepts “application-switching” as the point of the shortcut. As I have tried to explain above, this is fundamentally less useful than task-switching.

In his article he attempts to come up with an improvement to the shortcomings of MRU. (He doesn’t even mention cycling so I assume he is not in favour of it.) MRU’s shortcoming, Raskin says, is that it is only useful for toggling between two things (he says apps, I’d say windows), and frustrates your tendency to form spatial memory habits for more than that. Personally I don’t experience the problem he describes with juggling 3 apps. It’s hard-wired in my spatial memory that Cmd-Tab switches to the last thing, and Cmd-Tab-Tab switches to the last-but-one. For more than this I need to shift my attention to the switcher interface, and spatial memory is no longer of help. But this is infrequent enough not to matter.

He then proposes a “habit-respecting MRU” (HRMRU) to solve this problem I don’t perceive. He ponders using heuristics or even a Markov model to detect users’ habits. Personally I see this failing for the very reasons he himself described – it would just result in a seemingly capricious interface.

But the bigger problem I have with Raskin’s article is that he doesn’t address the real erosion in the usefulness of this shortcut: The loss of MRU due to tabs, and the co-existence of both MRU-ordered switching and cycling. (And the greater problem on Mac OS by having 3 switching modes: Apps, windows and tabs, two of which don’t use MRU.)

My proposal

Tabbed interfaces are not going away. They’re a necessary way of managing the ever-increasing number of windows we have to juggle. If I had to Alt-Tab between all of them, it could number over a 100. So I think two switching modes are inevitable.

So I propose that only two shortcuts are necessary: Alt-Tab / Cmd-Tab for window-switching, and Ctrl-Tab for tab-switching inside a window. (Or document-switching in applications that don’t use tabs.) Both should work exactly the same way: MRU order, with the addition of Shift to reverse the order. There is no reason for application-switching to exist.

This would be a minor change on Windows, but a fundamental one on the Mac. Perhaps, as OS X insists on having 3 switching modes with 3 different shortcut keys, they could at least redefine the second one – Cmd-~ – to be window-switching across all apps (i.e. like Windows) rather than within the current app only. And all should use MRU.

Some people may find MRU order in a tabbed interface confusing, and crave a keyboard shortcut that cycles instead, but then a different application-specific shortcut could always be provided. E.g. Firefox already has Cmd-Alt-Left/Right arrow (Mac) or Ctrl-PgUp/PgDn (Windows). These are more appropriate shortcuts for cycling as their names imply directionality.

  1. Windows actually uses Z-Order, but in practice this generally works like MRU. The behaviour was slightly changed in Vista, but the 6 most recent windows still uses MRU order.

Announcing FuncBrows – A browser testing tool

For the short version: System web browser testing abstraction layer. Get it here

For the last month or so, I have been heavily investigating various functional browser testing tools, with the aim of adding them to our Continuous Integration build.

The History

I settled on using zc.testbrowser for writing quick, functional tests that can be added to the end of a unit test run. As testbrowser isn’t a full browser in itself, it’s fast to run tests with, and can easily be integrated with the Zope and Plone functional tools.
However, for a full suite of integration tests, testbrowser isn’t a great fit. It doesn’t support javascript, and won’t tell you that ‘The login button is missing in IE6’, or that ‘Firefox 3 can’t access the profile changer’. For this type of test, the current leader is Selenium, which can instrument and drive real browsers (IE, Firefox, Chrome, Safari), in order to perform more accurate real world tests.
Selenium is currently undergoing a massive revamp in order to add better functionality and clean up the API (including a mode that will work similar to testbrowser), however this means that we are currently stuck with the older, stable version, as it has python bindings and more documentation.

So, given these two tools, I wrote a simple suite of tests for a project. They registered a user, logged in, logged out, and changed a user profle. Not massively complex, but it’s often surprising how many times such simple processes can be broken, and you won’t notice as you tend to always use the same test user details.

This was all well and good, and everyone was happy and it was sunny.

The Problem

The problem then became, that although developers can write testbrowser scripts fairly easily, and run them quickly, selenium is a lot more heavyweight, requiring selenium installs, multiple browsers and virtual machines to run a full test.

Fundamentally, the selenium API is very different from testbrowser, and asking people to write both was never going to happen.

This meant that selenium was added to the CI build, but the developers would never usually run the tests themselves, creating a disconnect between the current tests that the developers would run as part of their unit test suite, and what would be tested more heavily with the CI build.

The Solution

I (with a lot of help from other people, some ‘creative language’, and some frustration) created FuncBrows. This is a simple, lightweight abstraction tool over both testbrowser and selenium, that can easily be extended to add more tools to it, when required (selenium v2 and twill are on the target list).
It can easily be included, and configured in one line, with a base set of tests that can then be run by every tool, as required.

This means that the developers can write fast tests for their own use, and the exact same code can then be reused for more complete browser testing later in the system tests. A quick, simple way to smoke test for browser issues

There is a samples directory in the github repository, with a simple example of how to set up the tests so that they can be run with either the python standard test runner, or nosetests.
It’s fairly simple, and can’t do any advanced stuff, it only progressed to the stage where we could dogfood our existing tests, I expect the API to grow slightly as we need more functionality from it.
Patches and issues gratefully accepted at the github page.

Get the bits here: Isotoma Github
Or ‘easy_install FuncBrows’