Real World Design Stories: Menu Tradeoffs

Historical GIS Beta Screen Shot

I thought it might be interesting to talk through some of the design challenges that I’m currently facing in our projects. The design challenges will probably have a bit of both interaction design and pedagogical design thrown in. I’m always open to comments and suggestions, so it’d be interesting to hear someone else’s take on the problems. Please chime in!

To kick things off, I’m going to start out with the challenge of helping a student select a data layer from among a list of 50 layers. (Look for a few more examples coming up in the next few weeks.)

The problem:

For our web-based Historical GIS project, we need to design a system where students can select a data layer for display. The problem is that in some instances, there are 50 layers to choose from, with each layer categorized into two levels of membership: e.g. a layer might contain population data (category 1: type) at the state level (category 2: scope).

So, we need to make it easy for students to:

And just to make things more complicated:

Selecting a layer involves making three decisions:

  1. Choose the data scope: State vs. County vs. City data.

  2. Choose the type of data: Population vs. Agriculture vs. Industry

  3. Choose the specific data layer: Jobs vs Wages vs White Population vs African American Population, etc.

The question is, what kind of interface is the most appropriate? Given that it’s relatively cheap to try things out with the web, we’ve been building and iterating on a lot of prototypes throughout our development process. So in that spirit, here’s a whole mess of (quick and dirty) approaches to play with as we explore the viability of the various solutions.

Candidate A: Three Menu Solution

The brain dead way to do this would be to make each level into a menu. So you choose the first level (say, County), and then the second menu would populate itself with the available county layers. Choose the second item, and the third menu would populate itself with the actual data layers. Here’s an example of a three layer menu:


There are at least two problems with this approach:

  1. It is next to impossible to get a sense of the whole gamut of data layers that are available. You have to select every menu item just to see all of the choices.

  2. Even if you know which sub-menu to find the data, selecting a layer at minimum requires three clicks and drags (six clicks if you don’t drag). [Technically, with this particular implementation, if you happen to be selecting one of the default values you can do it in one click — e.g. if you wanted to select State>Population>Total Pop, which is the default layer when you select ‘State’, then you can do that in one click. But that’s being nitpicky.]

Candidate B: Select-by-Scope, Group-by-Type Two-Menu Solution

To make things a little more simple, we can reduce the number of menus to 2 menus:

  1. Choose the data scope: State vs. County vs. City.
  2. Choose the specific data layer, arranged by option groups.

For example:


This works a little better. If you’re just switching layers within the same scope, you can switch with one click + drag. The worst case requires only two clicks + drags when you need to switch both scope (e.g. from ‘State’ to ‘County’ data) and type. You can also see more of the available layers, though still not all of them. And this approach makes it really easy to switch scope.

But if your scope variables don’t match (e.g. if “White Males > 16” is available at the state level but not the county level), then we have to do a lot of work behind the scenes to make sure your selections stay valid. (e.g. sometimes when you switch your layer will remain selected, but if you switch and your data isn’t available, then we have to revert to some other layer). This isn’t ideal. Also, it still takes two clicks to set a layer. Reducing the number of clicks would be preferable.

Candidate C: Select-by-Type, Group-by-Scope Two Menu Solution

We could also reverse the menus, so that students first select by the type of data they want, with scope integrated into the layer name:

<

script type=”text/javascript”> function handleSelectByType( thisMenu, targetMenuID ) { var menuEl = document.getElementById( targetMenuID ); var newData = fullm[ thisMenu.options[thisMenu.selectedIndex].text ];
clearMenu( menuEl ); populateStateCountyMenu( menuEl, newData ); } function populateStateCountyMenu( menuEl, newData ) { var c = 0; var u = newData.length; for (var i=0; i


Note that we’re also adding ‘(State)’ or ‘(County)’ to the individual menu items so that when the men is collapsed, students can still figure out which scope they’re using.

This could be a little bit more intuitive than the “Select-by-Scope” solution above in that the student’s first decision involves thinking about the type of data that they’re interested in, with scope being just a secondary characteristic.

On the other hand, every time you select a layer you have to keep making a decision about “do I want state data or county data?” (This is in contrast to Candidate B where you only need to make the state vs county decision once and then are free to explore the specific data layers within each scope). This makes the selection process much slower. This is also slower because the specific layer names are are ‘hidden’ in the second menu. This means that in order to be able to see all the available data you need to consecutively select all three types and then click on the second menu (e.g. select ‘NATIONALITY’, then click on second menu to see the NATIONALITY layers, then select ‘SLAVEHOLDING’ and click on the second menu to see the SLAVEHOLDING layers). So relative to Candidate B, it’s actually more difficult to get a feel for the data that is available. Also, it still takes two clicks + drags to select a layer.

You still have to do a similar thing with Candidate B in order to see the State vs County vs City data, but at least for each scope you can see all the types at the same time.

Candidate D: Custom Submenu Solution

We could roll our own custom menu with submenus that open up via disclosure triangles (e.g. http://dhtml-menu.com/menu-demos/demo2040.html). The problem with this is that our site is being designed for a wide range of students with varying levels of computer expertise. We’ve found that submenus are sometimes difficult for novices to easily navigate. And you would still have the problem of not being able to see all of the available layers simultaneously.

Candidate E: Nested Groups Not Supported by HTML

We could try to have nested groups in the menu. For example, the top level group would be scope (State vs County vs City), the second level would be type (Population vs Industry vs Agriculture), and the third level would be the actual data layer. But HTML 4.01 currently does not allow for nested optgroups, so we can’t put all of the menus into a single menu.

Candidate F: Fake Nested Groups Via CSS

Another solution would be to use CSS with dummy optgroups to fake nested groups. All we’re doing here is adding a bit of margin and non-breaking spaces to the sub-group items so that they’re slightly offset from the ‘STATE’ and ‘COUNTY’ groups (NOTE: If you’re using Safari, this menu won’t look right to you…the scope labels will be missing. Also the marginLeft style property doesn’t seem to work on IE6):

<

script type=”text/javascript”>

function createNestedMenu() {
    var el = document.getElementById( 'nested' );

    var scopes = ['State', 'County'];
    for (var s in scopes) {
        //  Create Groups
        var g = document.createElement('optgroup');
        g.label = scopes[s];
        el.appendChild( g );

        for (var groupArray in fullm) {
            //  Create Groups
            var g = document.createElement('optgroup');
            g.label = '  ' + groupArray;
            g.style.marginLeft = '15px';


            //  Create Options in Group
            var u = fullm[groupArray].length;
            for (var i=0; i<u; i++) {
                var optionText = fullm[groupArray][i] + 
                                    ' (' + scopes[s] + ')';
                var o = document.createElement('option');
                o.text = optionText;
                o.innerHTML = optionText;
                g.appendChild( o );
            }
            //  Append Group to menu
            el.appendChild( g );

            //  Repeat
        }
    }
}


The nice thing about this approach is that you can theoretically make a selection in one click, though in practice you’ll often have to scroll through the menu, which means more clicking and dragging.

Putting everything into a single menu leads to a very long menu. The split between State and County also means that it’s difficult to switch back and forth between the state and county scopes (e.g. you have to scroll down to a section of the menu that is not currently in view in order to see the layers available in the other scope). Also, this CSS method doesn’t work in Safari: if the optgroup is empty, Safari won’t display it.

Candidate G: Single Grouped Menu Approach

If we really want to make sure that it’s easy to switch back and forth between various scopes, then it might work better to put all of the menu items within a single menu and group only by type. Scope is then selected within each type:

<

script type=”text/javascript”>

function createSimpleMenu() {
    var el = document.getElementById( 'fullmenu' );

    for (var groupArray in fullm) {
        //  Create Groups
        var g = document.createElement('optgroup');
        g.label = groupArray;

        //  Create Options in Group
        var u = fullm[groupArray].length;
        for (var i=0; i<u; i++) {
            var optionText = fullm[groupArray][i] + ' (State)';
            var o = document.createElement('option');
            o.text = optionText;
            o.innerHTML = optionText;
            g.appendChild( o );

            var optionText = fullm[groupArray][i] + ' (County)';
            var o = document.createElement('option');
            o.text = optionText;
            o.innerHTML = optionText;
            g.appendChild( o );
        }
        //  Append Group to menu
        el.appendChild( g );
    }
}


This certainly feels more compact (submenus nested more than one level ala Candidate F are pretty much incomprehensible), and it makes it relatively easy to shift scope from State to County and vice versa. It’s still a very long list though.

Another problem is that, like Candidate C, as you browse the menu you have to constantly make a decision about state vs county vs city.

Candidate H: Three Menus with Radio Buttons

Another solution is to use radio buttons to choose between three full menus with groups. The nice thing about this solution is that you can actually select via one click + drag (because we can auto-select the radio button when you click on the menu). Also, it’s nice to be able to see all three scopes simultaneously.


State
County
City

The drawback to this approach is that it’s less obvious which is the currently selected data source. We can do fancy CSS trickery to make the other non-selected menus fade back. But we wouldn’t want to disable them altogether, as that would mean that you would have to first click on the radio button to enable a menu and only then be able to select a layer. Nevertheless, I foresee a lot of confusion if there are three menus.

The other drawback to this approach is that this takes up a lot of valuable screen real estate.

Conclusion?

There is no ideal solution. Each method has tradeoffs.

We can use what we know of the task model to help guide us. The curriculum around this project has students making comparisons and drawing inferences from multiple data sources. But most of the reasoning is coming across data types (e.g. looking for correspondence between Average Industrial Wages and Population), rather than across scope (e.g. trying to compare population of a county relative to population of a state). This suggests that most users are probably going to spend most of their time switching layer types, leaving the focus on one scope at a time, and only occasionally switch back and forth between scopes. So perhaps pulling out scope into a separate menu may not be such a bad idea after all. The overhead of the additional click when making the occasional scope decision might be worth it.

It sounds like Candidate B is the best candidate given existing tradeoffs.

Of course, there are also other non-standard HTML widget solutions to the problem, but it would involve rolling our own javascript interface, and that’s beyond the current scope of the project.

posted May 11, 2006 by ben

Add comment:


Name:  
Remember personal info?

Email:
URL:
Comment:Emoticons /
Comment spam is an unfortunate problem on our site. Making you answer an Obvious Question is one way to defeat the spambots.
Obvious Question: How many states are in the United States (50)?




Small print: All html tags except <b> and <i> will be removed from your comment. You can make links by just typing the url or mail-address.