tags:

views:

17

answers:

1

Hello;

Which is the best way to represent data from a table with many columns and possible long text in the columns? The dialema is , if i use tables, the table width is very long and the table overflows outside the div. What options are there, can i list the data, the way this posts are listed in stackoverflow in a business application? how will it affect usability?

josh

+1  A: 

In general, there are no fundamental usability problems with a very wide table with each record occupying a single line as long as:

  • You provide horizontal scrolling so the user can get to all the fields.

  • You fix the record identifiers as row headers that they do not scroll out of view so the users can always identify the record they’re looking at.

  • Fields are relatively short so that many are in view at once; certainly you don’t want one field being wider than the typical window screen so the user as to scroll back and forth for each record to read that field.

The fact that users successfully use very wide spreadsheets shows that wide tables are not necessary a problem.

However a multi-line-per-record layout like SO is perhaps best for the kind of task that SO is used for: the user scanning records for a particular field value (the question title) to find a record of potential interest. Once the user finds a potentially interesting record, she or he can then without any additional input read the other fields (e.g., number of answers, number of votes) to decide if it’s worth drilling down for more information. Compared to a wide single-line-per-record table, this means more scrolling to scan the same number of records, but less scrolling or clicking to see what’s in a given record. There will thus be less work for the user when:

  • Some fields are very long (e.g., spanning the whole window).

  • There are few fields the user is likely to scan on.

  • Those fields for scanning are made graphically salient to facilitate scanning (e.g., with big, bold, and/or colorful font).

A multi-line-per-record layout is not so good when the user may be scanning on any of a large number of fields. You can make one to three fields more salient than the rest, but if you try to make every field salient then none of them are salient.

In contrast with a wide single-line-per-record table, the user can scroll horizontally to whatever field is of interest and scan down the table. There is no need to make any particular fields more salient than the others.

A single-line-per-record table is also better when the user is working between two or more records on a given field, for example, comparing the records on a field or copying one field value to another. More records for a given field value are visible at a time, reducing scrolling. It’s also easier to compare values when they are directly on top of each other rather than when separated vertically by other fields.

Michael Zuschlag