UX: Reducing clutter and visual overload_问答_开发者

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

Unfortuna开发者_如何学Ctely 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.

You could break your single table into multiple tables by Due Date or Assigned To. With multiple tables, all the tasks could be assigned to one person, or all the tasks could be due tomorrow (or "sometime next week", etc.). I don't know if this would still make sense for what you're trying to accomplish though.

I have had this problem: Normally the solution is in some combination of the following:

1) Combining columns. Obvious examples of this are if you have columns like First Name, Last Name, combine into Name.

2) Grouping rows so columns are obsolete. Something like:

Assigned to Jane Smith: (collapse/expand UI widget could go here)
Task     |       new           |   Due Date    |  etc .... |   Actions
Do this  |       free          |   Tomorrow    |  ....     |   Complete
Do that  |       space         |   Aug 26th    |  ....     |   Review
Assigned to John Doe:
Task     |       new           |   Due Date    |  etc .... |   Actions
Do this  |       free          |   Tomorrow    |  ....     |   Complete
Do that  |       space         |   Aug 26th    |  ....     |   Review

3) 'Action' columns can go into a floating toolbar. They select a row, then can click a button on a toolbar to complete the same action. You can then reclaim the action column

4) Push back. :) Easiest way to do this is by showing them the UI they ask for, then the one that you suggest, and agreeing to show it to another end-user to see which they prefer...

If you think that these changes will have a negative experience on the user experience, why not develop a couple prototypes with the proposed additions and put them into user testing.

If the users find it hard to accomplished the same tasks with all the extra cruft, then you have a strong argument for not making those changes.

From my point of view, the first solution could work.

In fact its how the SAP Portal allow you to chek the logs : you get a table of events, and opening an event add a space under the line with the detail of the event (user, stacktrace for exemple). The fact that the table header is not valable for this additionnal zone is made clear by a different background.

+-+------+--------+--------------+   
|+| Date | Source | Event        |   
+-+------+--------+--------------+   
| | User       : xxxxxxxxx       |   
| | Stacktrace :                 |   
| |    jhig kg kg kj jkg jk g    |   
+-+------+--------+--------------+   
|-| Date | Source | Event        |   
+-+------+--------+--------------+   
|-| Date | Source | Event        |   
+-+------+--------+--------------+

Another possibility is to put another zone under the table, and display additionnal information for the selected line in this zone (ie general/specific zones).

One of the drawback of those soltuion is that, in both case, the additionnal datas can not be used as other column (for exemple "sort by" is not available for those data).

Regards
Guillaume