capcloud | Martin Polley

Fitts’s Law for Asymmetric Targets (Like Tabs)

(Originally posted on my old blog on June 29th, 2009)

Since I started putting together my entry for the Mozilla Labs “Reinventing Tabs” challenge, I have been thinking about Fitts’s Law. Here’s what I have been thinking: does the shape of the click target affect the ease of acquisition?

More simply put, is it easier or more difficult to acquire a rectangular target that is (say) three times as wide as it is high than a square target of the same area?

And also, does the orientation of the rectangle make it easier or harder to acquire? (That is, does it make any difference whether the rectangle’s long side or short side is facing towards the pointer?)

Why does this matter? Well, if you have a bunch of tabs stacked up the left side of the screen (as in my entry), the answer could mean that they are easier or harder to click on than regular tabs of the same size that are strung out horizontally above the content area.

And now I have found a paper that contains the answer. At least, it contains the answer to the second part of my question (about orientation).

If you want to read it, go ahead, but here is the money quote:

… when possible graphical widgets should be extended along
the more frequent movement direction. … horizontally enlongated widgets, which are often due to the labeling in English words, should be placed on the left or right rather than the top or bottom edge of the desktop interface.

But there is a caveat:

However, the average horizontal movement distance is somewhat longer due to the landscape display geometry in most computers.

In plain English, tabs that are stacked at the side are easier to acquire than ones of the same size and shape along the top. But because monitors (especially modern wide-screen ones) are wider than they are high, this advantage may be mitigated (or even outweighed) by the extra (average) distance that the pointer must cover.

Adding Filtering Functionality to a Data Grid

Brief

To enable users to filter the items that are displayed in a data grid by any criteria they choose.

First Steps

The first thing I did was to sit down and talk with the project’s lead developer. He said he wanted something like the search feature in the bug-tracking system that we use (which allows you to create and save complex boolean searches on multiple criteria). My initial reaction was that in most cases, this approach would be overkill and the level of complexity that it introduces would make it difficult to perform the simple filtering that this feature would be used for most of the time.

Research

To get an idea of the possibilities, I looked at several examples of search and filtering interfaces: the in-house bug-tracking system that the developer liked, a different bug-tracking system that had been tried there (JIRA), and things like Google’s advanced search and various ecommerce sites with faceted search.

Based on this, I decided that the following points were important:

• Having the search/filter area separate from the area where the data is displayed (i.e., on a separate page or in a modal dialog box) is A Bad Thing. If you want to tweak your query after seeing its effect on the data, you have to pogo-stick back and forth between the data area and the search/filter area.
• Allowing users to use operators or other complex syntax in a simple text-box-based search/filter interface is useful, especially if you also have an easier way of doing the same thing that shows the equivalent operators. (For example, as you manipulate the controls in Google advanced search, the read-only text box at the top of the page shows the query as if you had typed it into the regular Google search box.)
• Having a wide variety of different types of controls for filtering on different types of data (e.g., having sliders, text boxes, AND combo boxes) introduced too much visual noise and meant that the feature could not be easily reused for data grids displaying different types of data. (This was important for the developer, as the plan was to use this feature for several different data grids.)

Initial Wireframe

After some initial sketching, I came up with this:

(Click for a larger version in a new window/tab.)

This was to be displayed as a slide-down panel between the toolbar and the data grid (to allow users to modify their searches and see the results immediately). The panel could then be closed so as to maximize the area available for displaying data.

The other two options that are shown would work as follows:

• Preconfigured search—this would contain a list of commonly-performed searches which could be selected from a drop-down list.
• Quick search—a simple text-box-based search where the user could type a search query (but would have to know the data field names and the search syntax).

You can view a short screencast that I made from my Visio wireframes here.

Feedback

After discussions with the development team, we came to the conclusion that even this was too complex—having “match all these criteria” and “match any of these criteria” was confusing. We decided to get rid of the second section and only display records that match all of the specified criteria.

Other Issues

There were other issues that had to be figured out:

• Should we call it search or filter?
  In the end we went with filter, as you start out with a set of records of a finite, known size, and reduce the size of the set.
• How to indicate that what is displayed is filtered or not?
  Initially I thought that the grid should have a kind of status bar below it, which could show something like “22 items, 18 hidden”. But I decided that this was too subtle. So I decided on a strip that would be displayed between the toolbar and the grid showing the current filter. The strip’s background color would be the same as that of the filter panel.

  

  
  
  
• What should happen when the user switches from one filter type to another (e.g., from Custom filter to Quick filter)?
  Due to the complexity of taking, say, a complex query that the user typed into the box in Quick filter and translating it into the values in a set of controls, it was decided to clear the filter (and warn the user) when switching.
• Which filter type should be the default?
  Quick filter, although it looks simpler and so perhaps most suitable for use as the default, it is really only for power users who already understand the syntax. So Custom filter became the default.

The Implementation

(Click for a larger version in a new window/tab.)

The initial implementation bore some similarities to my design, but there were lots of missing pieces. For example:

• There was no default filter—the user had to select one of the three options every time.
• The selected filter was not visually differentiated from the others.
• There was no way of knowing whether a filter was enabled or not.
• The spacing and alignment were all over the place, which made it hard to see what was related to what, which elements were most important, etc.
• The panel had a white background, so the fields did not stand out.
• Things that were clickable did not look clickable because the pointer turned to a text pointer instead of a hand on mouseover.

Fixing Things

When I saw how the design had been implemented, I started playing around with the CSS to see what I could fix just by changing things there. It turned out that substantial improvements could be made.

I also sat with the developer and showed her the problems. She fixed most of them, I made the changes to the CSS, and all was well.

For a while…

The New Version

Some time later, the developer who had implemented this feature left the team and a new developer joined. He was given the task of adding another new feature—the ability to group records (and also aggregate selected fields). Unfortunately, nobody consulted me about the feature until after it had been implemented.

The developer had decided that, as adding a filter and specifying a grouping were both kinds of queries, they could safely be combined into a single feature. He had combined them into an “Advanced Query” wizard that was displayed as a dialog box instead of the original panel (so reintroducing the pogo-sticking problem mentioned earlier).

The first stage of the wizard was where the user could specify a filter. The user could apply the filter without having to go through the other two steps of the wizard. But if the user wanted to group records, they had to click Next to move on to the second stage. There was no indication that the ability to group was unavailable until the second stage was reached.

The user would then click Execute, which would close the dialog box and open a new dialog box, containing the third stage of the wizard (specifying which fields were to be aggregated and how—count, sum, average, etc.).

Needless to say, this was less than ideal… I talked to the developer about it, and explained the rationale for originally having a panel instead of a dialog box. I also explained why I thought filtering and grouping are, for users, separate, unrelated things and so should be implemented as separate features. He agreed, but said that to change it, he would have to get the lead developer’s approval.

And that is how things stand right now. I do not have high hopes that my suggested changes will be made before the imminent release. (It works, so fixing it is a lower priority than fixing all the other bugs and problems before the release.)

I will push for this to be fixed, though. If not now, then later.

What I would do differently

I learned from this experience that it is very important to keep in touch with the developers during the implementation stage. To explicitly ask them to show me what it looks like at various stages. Once something has been built and works (however badly) it tends to stay that way (especially in an enterprise setting). If it works, there’s not much incentive to go back and make it better. There are always newer, more important things to work on.

Mozilla Design Challenge Entry

Brief

The brief of this design challenge was to find a creative solution to this question: “How can we create, navigate and manage multiple web sites within the same browser instance?”.

Entries were to consist of a video (around three minutes) and images of the mockup.

First Steps

After reading Aza Raskin’s blog post about browser tabs, I quickly saw the advantages of stacking tabs vertically at the side instead of spreading them out along the top. (If the aspect ratio of a tab is wider than that of the screen, you can fit more in this way. I also had the feeling that it would be easier to “hit” a particular tab this way, but I only discovered later that there is actually research that backs this up (referenced here).)

Once I started thinking about the problem, my first thought was, “Is this really a problem?” Do people really have so many tabs open that they have trouble keeping track of them? And if it really is a problem, what proportion of browser users suffer from it?

Research

To get an idea of the scale of the problem, I tweeted:

Quick! How many tabs are open in your browser right now?

These were the answers I received:

• Around 20
• 2
• 7
• 13
• 100 to 160, in 3 to 5 windows
• 6
• 4
• 20 to 25 windows, total of 36 tabs

Obviously this was not very scientific, but it proved the point that, yes, this is a problem for some people. (I’m sure my friends on Twitter are generally more tech-savvy than most, so they probably run into this problem more than most people.)

Another thought that crossed my mind was that maybe some people limit the number of tabs they have open because it is hard to manage more.

Initial Thoughts and Ideas

As I bounced ideas around in my head, I came up with the following points and ideas:

• You should be able to group tabs (e.g., applications, social media, read later, etc.). Related to this:
  • You should be able to collapse these groups to (a) save space and (b) let you focus on your current task (e.g., booking a hotel).
  • You should be able to arrange stuff by dragging and dropping tabs into, out of, and between groups.
  • What about new tab behavior? Where should a new tab be created? (In the current group? Outside all groups?) I decided it should be outside all groups, but to provide the ability to add a new tab to a group (e.g., via context menu).
  • Should we allow groups within groups? I decided that this would make things too complicated, so the design does not allow this.
  • Should we group things automatically or leave it all up to the user? My decision—leave it up to the user, except for tabs opened from within tabs. These should appear in the same group as the current tab.
  • Should we use tagging instead of each tab being only in one group? I decided against this, as it over-complicates things and does not match my own mental model of how tabs work (or should work).
  • How to visually distinguish grouped tabs from ungrouped ones? By color? By indentation?
• If we stack tabs vertically at the side, will this cause problems with sites that are optimized for a certain (wide) screen width? We need to let users hide or minimize tabs.
• The line between tabs an bookmarks is a blurry one. (I know I sometimes leave something open in a tab and sometimes bookmark it and close the tab. Sometimes after I have left something open for a few days, I will bookmark it and close it.) What behaviors/functionality can we add to help users here?
• Should we treat application tabs (e.g., Gmail) differently from “regular” tabs?
• How different should the interface be? If we go for something too revolutionary, it will have more of a learning curve, which will put some users off. If it is not different enough, we may miss an opportunity. In the end, I decided to go with something more evolutionary than revolutionary.
• How can you find a particular tab among all those open tabs (especially when one is hidden in a collapsed group)?

Initial Sketches

I didn’t put pencil to paper until I had bounced several ideas around in my head (including how they would look, in detail). So these initial sketches are more polished than if I had worked out the ideas on paper instead of mentally.

Exploring the ideas of tags vs groups:

Expanding and collapsing groups:

Alternative idea—workspaces—groups are displayed as blocks of favicons in the main browser display area:

Another alternative idea, similar to the last one. Here, when you click the “groups” button to the left of the (here, horizontal) tabs…

… the group pane slides down, displaying group blocks (comprised of favicons)…

… Then, when you click on a block, the current tabs animate up into a block and the favicons from the selected block animate down to populate the tabs (with tabs being added or removed as necessary):

Final Deliverable

I used Visio to create static mockup pages and Camtasia to record and edit the video.

As I worked in Visio, I played around with things to see what worked and what didn’t. I ended up with something that looked quite similar to my sketches, but the colors were quite different from my imaginings, and lots of details got filled in along the way (for example, what search looks like, what the tab area looks like and how it behaves when it is minimized, exact locations of buttons, and so on).

I also continued talking with people about the idea while I was working on it, and came across additional challenges that I hadn’t addressed. For example, what about tabs (or groups) that are particularly important (i.e., ones that represent a task that must be completed soon). These ended up in the video as “What Else?”—things I didn’t have time to go into in detail. (The video was constrained to around three minutes.) I also included drag and drop here, as it is hard to simulate using the tools I was using.

You can see some static screenshots here. And this is the video (best viewed full-screen):

Outcome

My design won Best in Class: Execution:

What I would do differently

If I had the chance to do this project again, I would definitely:

• Do more user research. This would have surfaced some important issues earlier and allowed me to explore them more fully rather than adding them in as an afterthought.
• Ideate more on paper. I spent so much time exploring possibilities in my head that by the time I sat down with pencil and paper, I was pretty sure of my direction. The project could have benefited from more idea generation and exploration.

Replication—Provide a Way for Users to Set up Syncing of the Contents of Multiple Storage Areas and Track Sync Status

Allocating Storage Resources to an Organizational Unit

Brief

To enable administrator users to assign storage resources (physical disks) to organizational units.

First Steps

This is not a complex problem that has never been solved by anyone else before (though there are a few wrinkles that need to be taken care of). So I looked to the available design patterns to see what would work best.

The interface was already in place for selecting an organizational unit in order to configure it. So all I had to worry about was assigning disks to the currently selected organizational unit.

Initial Design

I thought that the way that Google Calendar allows you to add as many alerts as you want to an event could be adapted (copied?) for assigning disks to organizational units.



The thing that makes assigning disks different is that each disk belongs to a file server. So first you have to select a file server and then select the disks (any or all of them).

So I decided to go with something that worked a bit like Google Calendar’s alert-adding interface, but where each row could be in one of two modes—add/edit mode and view mode. The user would be able to click the row (or an explicit link) to edit a row in-place.

This screencast shows what I came up with (prototype created in Axure RP while trialling that application):

The Implementation

The implementation was quite similar to my design, except that the Save and Cancel buttons were directly below the file server drop-down, and did not move down when the disk radio buttons appeared.

The fonts and alignment were also a bit off but these are easily fixed. This screencast shows the implemented version.

Fixing Things

I understood that putting the Save and Cancel buttons below the row was a bit of an afterthought on my part (maybe a result of my initial design not having these buttons). The implementation compounded this problem.

I realized that it would make much more sense to put the buttons to the right of the other controls (thus providing a straight line for the user to follow from left to right to complete the sub-task).

I created a new wireframe and showed it to the developers (see the quick ‘n dirty screencasts below).

This will be implemented when time allows.

With Save and Cancel buttons

Without Save and Cancel buttons

About me

Interaction designer masquerading as a technical writer. Dad. Husband. Etc. Brit in Israel. Johnny TV dude.

Twitter
Facebook
LinkedIn
Flickr
Delicious
last.fm
Huffduffer
Google Reader shared items
Google profile
I live here