How do you keep your data tables simple?

Minimizing Table Real Estate

You say you want to “simplify” the tables, but it sounds like what you’re really after is reducing the space they require. That can help the user by making more information visible at a time, reducing scrolling or paging. Here’re some ways to do that:

• Progressive disclosure. You’ve already done that by moving some fields to popups/drilldown windows (generally they should not be modal), collapsible rows, and tooltips. Another method is a master-detail, where you have a pane below the table (ideally collapsible) to show less important fields (an “overflow”) or a “subtable” for the current object in the table. Putting a subtable in a detail pane preserves the ability of the user to scan down a column in the main table, which is often the reason you’re using a table in the first place.

• Eliminate redundant/unnecessary controls. Many web apps have a separate control for each action on each row of table, which can make for a lot of command buttons. The alternative is have an object-selection-action UI, where you have a single centralized menu of actions (could be a pulldown) that acts on the selected row(s). This is often worth it if you have more than a couple actions possible per row. You can also use edit-in-place, and eliminate the Edit button, saving space in addition to saving effort for your users.

• User groups. Not all users necessarily need all fields. You could create different groups of users depending on their position or role in the organization, and show each only the fields they need. The user group is associated with the user’s login so they don’t have to choose it on each login.

• Table customization. If you can’t anticipate which users use which columns, it sometimes makes sense to have the users handle this issue by letting them add and remove columns, like can be done in MS Outlook with their Field Chooser.

• Grid (versus list). A true table, with columns for each field, a field header at the top, and horizontal scrolling (if necessary), typically makes more efficient use of space than a list, “tiles,” or “cards,” where one field can appear under another in a given row (like the questions list used here at Stack Exchange). You can squish rows closer together and you don’t have to have redundant labels in each row for non-obvious fields.

• Compact presentation. Minimize the graphics used to delineate fields and rows so you can move fields and rows as close as possible to each other. All you need to delineate a field is a faint flat box or maybe just a line. Try to get each row to be no more than 25 pixels high equivalent.

• Abbreviations. Field names (in column headers) and field values can use abbreviations. “Has Extended Warranty” can become “Ext. Wty” for example. “Delivery Date” can be simply “Delivery” (“date” is implied by the fact the value is clearly a date). Icons can also save space, but often text abbreviations are easily to learn and remember. A tooltip can show the full text to help learning.

• Compound graphic coding. While abbreviations often take no more space than an icon while being easier to learn, graphic coding can be more compact if a single graphic encodes multiple fields, each with a different graphic code. For example, a single icon can indicate (a) the class of product by shape, (b) availability by darkness/saturation (e.g., light gray means out-of-stock), and (c) sale status by outline (e.g., a green circle around the icon for products on sale). Your tooltips can show with text what the icon means to aid learning.

• Multiline or angled headers. If your field headers tend to be much wider than your field values (e.g., your field values are just checkmarks or “Yes” or “No”), don’t hesitate to make your headers be multi-line. You may even want to hyphenate some words. Another approach is to angle the headers (generally going from lower left to upper right), like MS Excel does to cell with the Orientation – Angle Counterclockwise feature. This allows you to “spoon” columns, making them no wider than they are high.

Maximizing Table Ease-of-use

You say the ultimate goal is to make the web site easier. A “simpler” smaller table is not necessarily an easier table. A more compact table means less scrolling/paging, but many of the things I listed above can make using the table harder to use. Each has a trade-off.

• Moving fields to a different window can make them harder to find and access.

• Putting fields in an “overflow” detail pane makes it harder to compare multiple rows on that field or scan for rows on those fields.

• An object-selection-action UI means it takes two clicks to do an action (like delete a record), rather than one.

• Table customization shifts the design burden from the designer to the user.

• Abbreviations and graphic codes have to be learned and remembered.

• Heavily hyphenated or angled headers can be harder to read.

Whether anything actually makes the web site easier depends on the details of the users and their tasks. For example, the benefits of abbreviations and graphic codes are greater if your users frequently use the app, so the benefits justify the cost of learning/training. Conversely, when thinking about how to improve the web site, study the users’ tasks. There a lot of ways a table can be difficult to use in addition to having a lot of fields.

• Tables are good for the task of comparing multiple records or scanning for a record with certain field values. If those aren’t your task, maybe you don’t want a table. Maybe you want a single Search blank for the user to enter the (known) record identifier, and then you display all the fields for a single record as neatly laid-out (with a good visual hierarchy) form or page.

• Redundant graphic coding of field values can make items in a table easier to scan and compare. For example, a small bar graph integrated in the cost field can represent cost graphically. Bold print or colors can draw attention to records with certain field values.

• Consider grouping fields in the table into sensible groups. This can be done with additional white space, vertical rules, and group labels that span multiple column headers.

• Consider the users may have an intrinsically complex task. Maybe this isn’t an issue so much of the table appearance. Maybe what the users need is better analysis or decision support tools. These could be sorting, filtering, find, or aggregation features, or it could be more sophisticated automation (e.g., an alerting feature for user-set criteria).

• Little things can make a big difference, things like getting the column order right, having fixed row and column headers that don’t scroll away, zebra striping for the rows, resizing the table width and height to fit however big the window is, and using a scrolling pane rather than paging.