0

This question already has an answer here:

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

╭───╥────────────┬─────────────╮
│   ║  Name      │   Email     │
╞═══╬════════════╪═════════════╡
│ 1 ║ First      │ a@b.ux      │
│ 2 ║ Lorem      │ ipsum       │
└───╨────────────┴─────────────┘

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

╭───╥────────────┬─────────────┬─────────────┬─────────────╮
│   ║  Name      │   Email     │   etc.      │   etc2.     │
╞═══╬════════════╪═════════════╪═════════════╪═════════════╡
│ 1 ║ First      │ a@b.ux      │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.

marked as duplicate by Mike M, locationunknown, Matt Obee, Wanda, Shreyas Tripathy Jan 11 at 8:28

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

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

  • 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 at 13:55
  • then you can use interactions to show the advanced attributes in a layer below the main table object – colmcq Jan 9 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
    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 at 15:59
1

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.

  • 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 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. – user2520890 Jan 15 at 0:34

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