1

Usually, when I start to create a list of things in a web application, I start by displaying a table

╭───╥────────────┬─────────────╮
│   ║  Name      │   Email     │
╞═══╬════════════╪═════════════╡
│ 1 ║ First      │ [email protected]      │
│ 2 ║ Lorem      │ ipsum       │
└───╨────────────┴─────────────┘

Then the web app grows and I need to display more things:

╭───╥────────────┬─────────────┬─────────────┬─────────────╮
│   ║  Name      │   Email     │   etc.      │   etc2.     │
╞═══╬════════════╪═════════════╪═════════════╪═════════════╡
│ 1 ║ First      │ [email protected]      │Lorem        │ ipsum       │
│ 2 ║ Lorem      │ ipsum       │Lorem        │ ipsum       │
└───╨────────────┴─────────────┴─────────────┴─────────────┘

Then it start to become unreadable, because there are too many columns.

Assuming all of these fields/properties are important (I mean, they have to be displayed in the list), what can I do to display all this information ?

Example of properties: name, firstname, email, group, departement, role, last connected at, action, ...

DISCLAIMER: I'm not a UX designer. And it may be my first question here: I can edit if I misunderstood some rules about UX questions.

0

3 Answers 3

2

I've had a similar issue where a table ended up with as many as 40 different columns, all of the deemed useful.

We tried several different solutions accepting that some of the content would not be on the stage. The best solution in this instance was to freeze the first column with the id or column name that would provide the context to the row. This allowed users to scroll all the way to the right and still see which row they were looking at.

enter image description here

This wireframe shows that the frozen panes and the columns that the user can scroll through, the blue section shows the frozen pane, the white shows the viewable columns and the grey shows columns off stage.

5
  • this sounds more like a spreadsheet design then, which is fair enough, but all these solutions depend heavily on what the use case is. If your 'thing' needs a spreadsheet design, then maybe a website isn't the best place for it, but a spreadsheet!
    – colmcq
    Jan 10, 2019 at 10:38
  • I think most of these tables that end up in webApps are specifically to remove the nightmare of handling hundreds of spreadsheets across teams. The above solution works great for long tables that multiple users will use. Jan 15, 2019 at 0:34
  • I'd like to see a precedent and working example of where this has been done with success.
    – colmcq
    Jan 25, 2019 at 11:42
  • I understand your skepticism and appreciate you not dismissing the idea outright, the frozen panes solution allows the user to scroll horizontally without losing the context of the row itself. In my case the row name, ID and status were frozen leaving >70% of horizontal space to explore the other columns. Its in our roadmap to allow users to add new columns to the frozen pane to allow easy comparison within the table. This is a very sensible and high impact way to utilize a monstrous table and have it remain useful and is a part of our users workflow now. Jan 25, 2019 at 17:18
  • when you finish, can you send a link? I'm genuinely interested in your approach.
    – colmcq
    Jan 28, 2019 at 17:10
1

This is quite an established pattern.

Split the design into two interactions:

A)A table listing the parent objects with columns representing unique identifiers of that parent object

B)An interaction detailing more attributes of an individual object which is reached by clicking an object in A)

Edited: when you click on an object, extra lines in the table can show the extra attributes of the object

But don't get up in having to display everything on one screen: you can use lightboxes, drop down layers to display the extra info. If you insist on having lots of columns then you'll run into problems

2
  • Thank you for your answer! In my question, I precised: "they have to be displayed in the list". It means it's required to display these information directly in the list, not on another screen.
    – rap-2-h
    Jan 9, 2019 at 13:55
  • then you can use interactions to show the advanced attributes in a layer below the main table object
    – colmcq
    Jan 9, 2019 at 14:07
1

Couple of solutions could be;

a) Use cards instead of table rows
b) If you use table, use horizontal scroller for columns that goes off the screen
c) If you use table, use columns that are most important that fit into the screen, and for the rest - use "toggle more" button below each row to display rest of the informations
d) If you use table, stack each column (or unimportant columns) to small width and then in column header make option to extend to full width, or compress column back.. <.> <.....>

1
  • 1
    I'm not sure about scrolling horizontally for columns that go off screen. A question for OP is: you need to do some user testing to see which attributes are more important or most frequently needed
    – colmcq
    Jan 9, 2019 at 15:59

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