Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

One of the problems in a tabular representation of data, is text wrapping inside cells. There are some options available, like:

  1. Fixing the width of the columns, and enlarging the rows height to encompass all of the text.
  2. Letting columns fit the contents width by stretching each column and stretching table container
  3. Letting columns fit the contents width by stretching each column and putting scroll on the table container
  4. Fixing the width of columns and height of rows, and hiding the portion of text which is overflown.
  5. Fixing the width of columns and height of rows, but letting the cells have scroll inside them.

And many other available options. But each of these options prove to be inadequate in some UI scenarios. For example, when you work in a web page, you shouldn't let your table take as much width as it wants. Thus, you should limit the width of your table. On the other hand, sometimes you have to show a long text (2 paragraphs for example) in a cell. You can hide the overflow portion. But there are still other times when you really need to show almost everything.

We're trying to create a web application in which a big amount of heterogenuous data should be represented in tabular format. We want to limit and fix our design to 960px width, and we have a sidebar also. Therefore, we don't have more than 700px for our tables and grids. We can't decide which approach is the best approach for formatting our data in tables.

Does anyone know of a good UI and UX research about the best practices of formatting HTML tables, regarding text wrapping? Do you have any experience that can help?

share|improve this question
add comment

1 Answer

There's no one ideal way of handling this problem. Like many user experience matters, it's an issue of choosing the best compromise for your use case.

Let's consider the five options in order:

1. Fixing column width and enlarging rows

This works well if the user needs to compare two fields for a particular entry (row) rather than the same field in two different entries. Fixing the columns means the table never exceeds the pageview. But it makes it harder to quickly scan a column.

2. Stretchable table widths

This is fine so long as you aren't likely to exceed the width of the page, or if it doesn't matter that the user only sees one side of the table at once. Constant horizontal scrolling is awkward and to be avoided.

3. Scrollable tables

Not an attractive solution. It's hard to scroll horizontally (many users now rely on purely up/down scrollwheels), and your user won't be able to use keyboard scrolling unless the table is in focus.

4. Hiding overflows

Again, not great. Only acceptable if the user is unlikely to need to see the whole contents of long entries to glean semantic information.

5. Scrolling cells

Difficult to implement nicely, looks messy, and users can't scroll without putting cells in focus.

Another option: Secondary Disclosure

There is, however, another option.

'Secondary disclosure' means 'not showing full entries at first glance'. There are several ways to achieve secondary disclosure. You might, for example, show only a brief summary in each table row, but when the user clicks each entry, it 'opens' in an 'accordion' fashion, showing full details.

This works well when the user is unlikely to need to scan rows and read the full cell entry at the same time. In a way, it's a method that combines the best of options one and two. But the disadvantage is that users can't see a full entry at a glance. You may decide that, given the usecase, this is an acceptable limitation.

share|improve this answer
    
Another secondary disclosure option is to show a tooltip of the full text of a cell when hovered over (using the title attribute), but this isn't well suited for mobile as there's no direct hover action. Usually tapping your finger works the same, but it also activates a click event which may cause other behavior, and it's even less discoverable. –  Ben Brocka Oct 15 '11 at 13:11
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.