List versus table design

Question

The inability for tables to deal with data that span multiple rows, especially in situations where the screen space is limited is one particular reason why list views have been used as an alternative to display information. The popularity of the flat/metro design that uses the card/tile style of information display has also resulted in the use of list view to display more complex data.

While the use of tables are well defined in terms of the data structure and implementation details, the specifications of a list view seems to be less detailed. Some list views are static like a table while others can trigger additional information to be displayed. Also the hierarchy levels of list views can vary considerably while tables generally have the header row and data rows.

Apart from the implementation issues that have been dealt with on StackOverflow and specific accessibility issues, are there any other considerations when it comes to choosing between list or table design?

Are they considered logical equivalents (so it is a matter of visual or cognitive processing preference) or do they cater for specific types of information display (in which case we should provide better guidelines for when we should use which type)?

A related question about Tile versus List/Table view provides some interesting ideas as well.

Answer 1

1) One important aspect is that a tile layout makes it easier to analyse the items one by one (a) while a table makes it easier to compare the items (b):

a) The power of getting all the data around one content item in one separated layout item is not to be underestimated. The analogy between the two entities makes it a lot easier to focus on in and make a complete assessment of the data. In a table, the intrusion form neighbouring rows will distract and the fact that you will have to send you eyes on a trip to the header every time you're not certain which column you're looking at makes the table a poor choice if this is the main task.

b)
Tables, if implemented so (and they really should be), can be order by the values of any one column (asc or desc) selected by the user. This makes it very easy to rank the items out of different attributes which is very convenient in comparison scenarios. This can somewhat be achieved with a tile or list layout as well by adding an "external" sort feature. However, even though the sort feature might put the items in the correct order, it's a lot harder to scan the particular values you have sorted on since that value will not be lined up vertically above each other; they will still be in their respective tile and the eyes will have to jump between the tiles rather than just scan a column.

2) The tiles are better containers for media. A table with larger images quickly becomes inusable, or at least loses it's advantages in ranking/comparing.

3) In a table, the headers are displayed once only (in the header bar). In a tile layout, the designer must either design the content so that the values are clear enough on their own, without even needing the headers to explain the values, or the headers needs to be included in every tile. The latter being very real estate consuming and lays up for a messy design with poor scanability.

Answer 2

I cannot give a comprehensive answer, but there is one very important case where the table is superior.

Sometimes we have lots of equally structured items (that's an important precondition!) and need to display lots of information about an item in an UI which supports multiple tasks (or multiple scenarios of the same task), but only one piece is relevant for a given task. There, a table provides the user with the perfect way to follow only the information he needs. The visual search query is highly simplified as opposed to a list display.

An example: a manager wants to see if there are any irregularities in production. He pulls up a table of KPI numbers for the last 30 days. It has 30 rows, and one column per KPI. The manager now focuses on the percentage of dud products per day (a visual search query). If it looks unusual, he does two comparisons. First, he looks at other numbers of the same row, to see if they explain the high number of duds (another visual search query). Second, if he finds no direct explanation, he looks for other rows with the same amount of duds (yet another visual search query) and compares the numbers for the rows with similar dud rate, to see if the other numbers also match, seeking for a common pattern (visual query number four).

If you have this in a table, the position of elements needed for each of these search queries varies in one coordinate only, either x or y, so our manager can follow a straight line and do some stops along the way. This is much easier than when doing this in a list. In a list, both the x and y coordinate of an element will vary. Even if they vary in a consistent pattern (which isn't always the case), the eye coordination needed for moving to the next item is much more complex. It may be even so complicated, that the cognitive load of finding a number is high and the person cannot process enough of them at once with the eye. There is no way for only the relevant information to "pop up" into at once into working memory and for the person to see deviations form the pattern at a glance.

So, if you expect your table to always be read row-by-row, this argument isn't very relevant. A list might be even better, I'm not sure. But if you expect your table to be read columnwise, or the user to do comparisons of single rows, tabular data is better.

Note that for a subset of the possible pattern search tasks (but not all of them) a graph, or actually a number of graphs (one per table column) will be superior to both a table and a list.