I am working on this project (web-based) where users can login and see a list of tasks assigned to them. Right now there are only a few columns and the presentation is somewhat clear and uncluttered.
Task | Assigned to | Due Date | etc .... | Actions
Do this | Jane Doe | Tomorrow | .... | Complete
Do that | John Smith | Aug 26th | .... | Review
Unfortunately the client has requested a whole bunch of information they want to visualize at a glance. The table is almost completely spanning the screen horizontally. Here are a few ideas:
-
Add a [+] button that expands the row vertically. More information can be put into this new vertical space. The problem is this new information will not correspond to the table headings (Task, Assigned to, etc.)
-
Add the ability to collapse columns. This will require significantly more work, and I can’t think of way to present collapsed or hidden columns in a way that’s intuitive. The target audience will need something very intuitive.
-
Use tooltips that appear on mouseover. The obvious disadvantage of this method is you can’t see that information at a glance.
Does anyone have ideas on this?
I’m going to assume the client actually speaks for the users, and it really is advantageous to show more information “at a glance.”
Seems to me that each user is generally only interested in work assigned to him/her, so the first thing to do is generate a separate page per user. Give each page a unique URL so the user can bookmark/shortcut it and navigate straight to it. Even better, drop a cookie after the user’s first visit so the page defaults to his/her own. In addition to removing irrelevant clutter, this eliminates the Name column, giving you more space for other information.
To truly see everything “at a glance” –that is no scrolling, clicking, or hovering –you need to make the information as compact and uncluttered as possible:
Strip down the page template to the bare minimum. Horizontal space is most precious with a table, so have no sidebar menus or navigation controls. Get the branding and menu down to a single bar across the top, preferably no more than 50 pixels high. Use a pull-down menu if necessary, at least for holding the less commonly used commands.
Compress your fields as close together as you can, separating them by as little as 10 pixels. If the number of task items in the table is also an issue (in addition to the number of fields), then squeeze the fields together, maybe no more than 20 pixels from the top of one to the top of another at the default font size. Eliminate or mute the borders of the fields to reduce visual clutter. In particular, avoid 3-D (e.g., beveled) or multi-colored borders. Some specific guidelines and ideas at Coded, Compacted, Contrasting Controls.
Tone down the graphic design, reducing or eliminating variations in colors, 3-D appearance, textures, and any light-on-dark headers or text. Use just enough graphics to barely visually group information when that’s necessary. Don’t worry about “looking boring.” Users are going to be studying the information, not the graphic design.
Use a desktop-style object-selection-action model where the user first selects task item(s) to act on then selects the action to execute from the menu. This eliminates the need to repeat each command control for each item in the table, allowing the table to show only data.
Keep each task item in the list to one row in the table, rather than stacking fields for the same item on top of each other. With a single row you don’t have to repeat field labels, avoiding that clutter. It also allows you to eliminate horizontal and/or vertical rules in your table, relying on the fields themselves for guiding the eye through the table (however, you may want include subtle zebra striping since that helps the eye follow rows when they are pressed closely together). A single row per item also makes it easier to scan, sort, and compare items; I assume the reason you have a table at all is to allow users to prioritize their task items.
Consider using mouseover to show the complete values of strings that are too long for the field width. This may allow you to use considerably shorter fields since you won’t have to size them to show entire values at 99th percentile of length. You can also make the columns sizable by drag and drop so users can set the minimum width they need for their respective data.
Compress the fields and columns themselves, using more compact formats, aggregates, abbreviations, codes (e.g., shades/colors) or icons to indicate values or column headers. This may require training the users, but you can also use mouseovers to provide a tooltips on what the codes/icons/abbreviations mean. Abbreviations are probably easier to recognize, learn, and remember, but graphic codes and icons can easier to scan for, helping the “at a glance” assessment. Recommendations for coding at Putting the G into GUI, although that article also advices combining codes with text, which won’t save you any space.
Allow column headers to be multi-line so they don’t force the column to be wider than the field itself requires (e.g., for Y|N fields). If necessary put column headers at an oblique angle. That takes no more space than a vertical header, but it’s easier to read.
Be sure the table resizes with window resize so at least users with large monitors can see everything at a glance.
After doing all the above, you’ve done all you can to keep everything visible at a glance. If all the data still won’t fit, then some lower-priority information must require interaction to view. Your options are:
A wider table with horizontal scrolling, putting lower priority fields off to the right. This is often the simplest and most usable solution because it allows the user to still compare all the task items. It’s usually better than having each item take multiple rows in the table. Horizontal scrolling is not nearly the usability problem for tables that is for prose, especially if you keep the row headers fixed, and only scroll the other fields.
A master-detail division, where there is form-like a pane of lower-priority “overflow” fields below the table. They show the values for the currently selected item in the table. Make this overflow pane tabbed, and you can hold a very large number of fields (but not “at a glance”). Put the overflow pane in an expander so that when the user closes the expander the table expands to full window height, allowing users who don’t need to see the low priority fields to see more table items. Fields in the overflow pane cannot be compared easily among multiple items, so this solution works best when you can divide fields between those used to prioritize task (they’re in the table) and those use to decide how to complete a task (they go in the overflow).
A tree or telescope, where each table row can be expanded to show low priority fields (your + button idea). The chief advantage this has over master-detail is that theoretically it’s easier to compare the low priorities fields of two items –but only when the two items happened to be adjacent to each other in the table. Otherwise, it has more problems than a master-detail: the high-priority fields are more likely scroll out of view, the amount of scrolling to get to a given item changes, and it takes more clicks to find an item with particular low-priority details.
A separate page or window for low-priority fields that the user “drills down” to from the table. This is generally only good if you need to have a page for those fields anyway (e.g., to navigate to directly), or to stuff a bunch of very-low-priority fields your client insists are necessary.
Details and illustrations of these options at Taking Panes.
Showing information with mouseover should be reserved for only short supplemental information. Otherwise it tends to get in the way, may have accessibility issues, and the user can’t copy it or view it when also manipulating something else.
Hiding/showing columns only makes sense (over, say, horizontal scrolling) if different users use different fields. It can be a user preference that should be preserved between sessions.