I started out designing applications for the desktop on the Windows, Mac, and Unix (Motif) platforms. Now my design work is mixed between web based applications and desktop applications. Most of these are web-based enterprise-class applications. I like to draw upon many of the standards and interactions from desktop application design when I am designing a large, complex web application because, frankly, the desktop just got it so right so many times. I also like to find ways to improve upon traditional desktop application design as I migrate it to the web.

I worked on a project last year with a team that was vexed by a problem. They had a toolbar on a screen with a Delete button. The problem was that the screen had a tree on the left (full of folders) and a table on the right (full of Frozzbots – ok, the table wasn’t full of Frozzbots, but the actual type of information isn’t important). The Delete button could apply to an item in the tree, or items in the table. The tree and the table both had selections in them. So how could they tell what the Delete button would do? (For the visually minded, see the image below).

With two selections, what happens when you click Delete?

With two selections, what happens when you click Delete?

Solution 1

The first solution they had tried on was to make the Delete button a menu button, and under that menu the user could choose to Delete Folder or Delete Frozzbot. Of course they also had to do this to the Edit button, the Export button, and most of the toolbar buttons. So they had a toolbar which had essentially become a menubar full of 2-item menus (see below).

Solution 1: change the toolbar so that each command can indicate a target

Solution 1: change the toolbar so that each command can indicate a target

Solution 2

Some folks weren’t really happy with this, so they rearranged the toolbar so that it now had two menus: Folder and Frozzbot. Under the Folder menu was a list of commands related to Folders and under Frozzbot was a list of commands related to Frozzbots. The menus were virtually identical (see below).

Solution 1: rearrange the toolbar so that it's noun oriented - first pick the type of target, then the command

Solution 1: rearrange the toolbar so that it’s noun oriented – first pick the type of target, then the command

The team had been in many many hours of meetings debating the pros and cons of these two solutions and they went back and forth. But then they hit a wall. Because it turns out that a Frozzbot is made up of a list of Dibbles. And they realized that the screen would actually have three different lists:

  • A tree of folders on the left
  • A table of Frozzbots on the top right
  • A table of Dibbles on the bottom right

The user would select a folder, and the list of Frozzbots would update. Then the user could a Frozzbot and the list of Dibbles for that Frozbot would show up below. In fact, the user could select more than one Frozzbot and all the Dibbles for those Frozzbots would show up in the list below. A picture of this situation is shown below.

With three selections, it's even more vexing - what does Delete do?

With three selections, it’s even more vexing – what does Delete do?

Now the Delete button could apply to one of three objects: Folder, Frozzbot, and Dibble.

Solution 3

In fact, now there was a new solution: make three toolbars. One for each object type. The toolbar for Frozzbots appeared just above the table of Frozzbots. The toolbar for Dibbles was above the Dibbles table. The toolbar for folders had to be pretty short since the column of folders is really small. But they mashed it in there with a little creative use of menus.

Solution 3: multiple=

Solution 3: multiple toolbars, one for each pane

Now there was a 3-way battle. Everyone picked a camp and staked out their turf. Each side had compelling arguments: things that did and did not work about each of the solutions. Everyone had a favorite.

This was actually not a problem that they had invited me to work on – I was off fixing up a different application, but they asked me to weigh in on the debate. I looked the whole thing over, and then I showed them how the desktop solves this problem.

(I did think about suggesting a usability study to put the whole debate to bed, but honestly I thought that there was already a perfectly good, widely accepted design solution to this problem and I wasn’t going to spend resources rediscovering something that’s already been explored and solved – more on this at the end of this discussion…)

The Desktop’s Solution

You see, the desktop has this problem, too. And they really have it worse because on the desktop a user can not only choose Delete from a menu, he can also just press the Delete key.  How on earth would you know what to delete then? Would you ask the user? That would be maddening.

The way that the desktop solves this problem is with the notion of an Active Selection and an Inactive Selection, and while I see this on almost every desktop application, I’ve never seen it implemented on a web based application. I’m looking forward to it, though!

Let’s take a look at my Address Book in the image below. The Group “Physicians” has been selected. If I press the Delete key (or choose Delete from the Edit menu), then that Group will be deleted. It’s the target of the command, the Active Selection.

Active Selection of a Group in the left pane

Active Selection of a Group in the left pane

Now look at the example below. The Card “Beverly Medical Supply” has been selected. If I press Delete, then that Card will be deleted.

Active Selection of a Card in the center pane

Active Selection of a Card in the center pane

Finally (below), I’ve selected the text “Beverly” in the card itself. Now if I press Delete, the text will be deleted. Notice that selection is indicated with the blue highlight. But the Group “Physicians” is still selected, as is the card “Beverly Medical Supply”. Their selection is indicated in gray.

Active Selection of text on the card in the right pane

Active Selection of text on the card in the right pane

The selection in blue is the Active Selection. The selections in gray are the Inactive Selection. The user can make a selection active by clicking on the selection again, or by clicking in the pane that contains the selection.

I’ve got a little video clip that shows all of this at work right here: Active selection in Apple’s Address Book (movie) Here’s what happens in the movie:

  • I click on Physicians – it is the active selection and it turns blue.
  • Then I click on Beverly Medical Supply – it is the active selection and it turns blue. Physicians turns gray – it’s now the inactive selection.
  • Then I select the text “Beverly” on the card itself – it is the active selection.
  • I click back on Beverly Medical Supply – it is the active selection. Address Book has an error here – it lost the active selection of the text “Beverly” in the card details on the right pane. That shouldn’t happen.
  • I click back on Physicians, making it the active selection again.
  • Then I click on the whitespace of center pane (the list of cards that include Beverly Medical Supply) – and the active selection returns to Beverly Medical Supply.
  • Then I click on the right pane – the card itself.
  • I click outside of the Address Book application and the whole application no longer has an active selection – all the selections turn gray.
  • I click back into Address Book and my last selection (the word “Beverly”) is now the active selection.
  • I click on the center pane again and active selection returns to Beverly Medical Supply.

Solution 4

So the solution I offered was to use Active Selection in the application, as you can see below:

Solution 4: One Active Selection, 2 Inactive Selections.

Solution 4: One Active Selection, 2 Inactive Selections.

Using Active Selection

So if you’re thinking of implementing Active Selection, then here’s what you need to keep in mind:

  • You need two selection colors: one for the active selection, one for the inactive selection.
  • In addition to a selection focus color, you could have a change in the pane’s border color to indicate focus: for example, the pane with focus (in our example above, this would be the list of Frozzbots) could have a blue border, whereas the other panes have a gray one.
  • When the user selects an item, it becomes the active selection. Any other items that were the active selection become the inactive selection.
  • The user can click on an inactive selection and it will become the active selection.
  • If there are multiple inactive selections (for instance, 3 rows in the Frozzbot table are selected), clicking on any one of the selected items in the inactive selection will make the whole group the active selection again.
  • The user can click in the “empty space” of a pane (for instance, clicking in the blank area below the list of folders) will return the active selection to the items in that pane (“Chuddles”, in the example above). Any items that were selected (and it can be more than one item) should be selected again.
  • When the user leaves the application, all selections in the application lose focus.
  • When the user returns to the application, the last selection focus is restored.

Should you?

Should you use Active Selection in your application?

As I said, the team was battling between three design approaches: a toolbar of verb buttons, where each was a menu. A toolbar of noun buttons (Folder, Frozzbot, and Dribble), where each was a menu, and three toolbars – one for each pane. I offered a fourth solution: using active selection. But, should they use it?

I think that the place where Active Selection really shines is with keyboard accelerators. Pressing the Delete key to delete an item, using arrow keys to change order or selection, using Command-O to open an item and edit it are big time savers for some users. When you offer active selection along with keyboard accelerators, you can save a lot of mouse movement, which is very important in high use applications. So I told the team that if they were planning to use keyboard accelerators, then they should definitely use active selection.

But what if they weren’t going to use keyboard accelerators?

I honestly think that in the grand scheme of things, it doesn’t matter which of these four approaches they used. All four of the designs were usable. I firmly believe users would figure them out. No one was going to sit down and use the product and fail to successfully Delete a Frozzbot using any of these four designs. All had been carefully designed and crafted. All made sense. The differences between these designs was really going to amount to the amount of mouse movement. Deciding which one to choose really comes down to what your users prefer, what works across the whole application, and what the design and engineering teams prefer.

One of the things to ask yourself, when you’re deep in a debate about the merits of the design, is are we arguing at the margins, here? When a team is passionate about design they can get really entrenched in their particular design approaches.  Try to imagine that you took each design and implemented it perfectly and tested it with users. What differences would you expect to see? In this case, there are probably small differences in time to complete tasks because of the arrangement of the commands.

If all designs are essentially understandable, then perhaps you should focus all this energy on a place in your application where things are not in such good shape. Just pick a solution that can be applied consistently throughout the application, do a great job of implementing it, and move on.