I'm thinking about how to design a table component in Angular2 that can show complex data types.

A complex data type can contain the following:
1. Primitives - numbers, strings, etc.
2. Lists - several pieces of data

Also, they can contain inner complex types, (person can have an address that contains several fields and etc), and lists of complex types (basically a sub-table).

When I think about exporting that data, I dont know how can I show types other than primitives. The only idea I get is to put a button in the table cell, that would open a modal that would show whatever data I need, let it be a list, an object, or a list of objects.

How do you think such a problem should be approached from a UX perspective? Until now, the data was only available as a CSV, which makes it easy to show, but complex information was basically unavailable to the user, whereas now, I get a json with all the data I can think of.

Rightfully, I've been suggested to add the requirements to the post:

Basically, we're talking about

1. A table that can show complex objects, which can have nested objects and nested lists of objects.

2. I want to allow the users to search easily - either values, or headers (f.e, search for alabama, or state. one is a cell value, one is a column header)

  • What is the device/resolution? How many rows and columns would expect to display, on average? Jan 20 '17 at 16:45
  • Ok, didn't expect to be asked that, but I guess it makes sense since it's UX. It's not for mobile, it's almost exclusively for 1920x1080 screens, scaling from 20 to 24 inch sizes. The table will almost always scroll horizontally since there are many columns (on average), and likewise for the rows - there are tables with avg of ~5 rows, and others with avg of 25~ rows or more. Jan 20 '17 at 17:09
  • The table cell data that has the potential to hold more information, do you have any stats on how often people access/will access this information? Jan 20 '17 at 17:19
  • Not numeric stats, but I would say fairly often. Until now, people didnt have access to reading those lists, since lists arent available inbthe csv format, which is one of the reasons for the change. Inner objects were available as well, but it was in a fairly bad format, as in - inner object fields were added as columns with their column names prefixed with the inner object field name. Although its fairly useful for searching fields of inner objects Jan 20 '17 at 17:25

I will expand on this if it is incorrect. Are we basically talking about this, which is a before and after (top to bottom):

Expanded Cell Data

  • basically, yes. If I open a cell that represents an object, it would show some sort of a form or just a list of field-name: field-value. If I show a list, it would be a list ul/ol of the primitive values. If I show a list of objects, It would open a modal with a table representing the list of object. I'm fairly certain our database doesn't contain nest levels of more than 2 (modal of table), so I would define it as a limitation, or simply open another modal if needed to show the extra data. But you are on point about what I meant Jan 20 '17 at 19:50
  • Well you're not going to get complex programming advice here. We here for the user experience, so lets look at my design and improve it for your users! Tell me how it could be improved for them? Jan 20 '17 at 19:51
  • I wasn't really looking for programming advice. I wanted to get a sense of whether my modal approach is legitimate, are they are known approaches for that problem, and what do people who specialize in UX know. Jan 20 '17 at 19:53
  • It's inherent, a modal pop-up forces the user to view that one bit of information, hence why I asked about the device and size of the real estate. If you believe or have checked to see whether your user work in this fashion, then there's nothing wrong with displaying data this way, if it becomes a burden to your users because, lets be frank and expansion of the cell field to display the data I've imagined wouldn't be that difficult, then we'd probably need to revisit it and device a better way. Jan 20 '17 at 19:56
  • Look what we're gonna do. First of all, I thank you for even taking the time and discussing with me. Second of all, it's currently Friday here, so I'm only going back to the office in 2 days. I'm going to talk to my fellow developers (who are also the clients of this product, it's for viewing our database when researching and debugging), explain to them my vision and this approach, I'll get a sense of what they want, and I'll pop this question up with what I find. How'd you like that? Jan 20 '17 at 20:00

You could have something like this:


download bmml source – Wireframes created with Balsamiq Mockups

The grid shows the basic information and the arrow indicates that the row is closed.

Clicking the arrow opens the row showing the subsidiary information.

This only works when the rows show data about one object and is more usual when there is a list of subsidiary information (like transaction history, children, etc.), but it might work in your case too. There's nothing to stop you arranging the subsidiary information vertically.

This arrangement would allow you to have several rows open at the same time so you could compare the subsidiary information on screen if you needed to.

  • You do point out one of my biggest problems - enabling quick search for fields in inner objects and object lists. If I remove inner objects from the view directly and use a modal, it'll mean I can't rely on the browsers find and I'll have to make a search feature for the table, which is pretty unwanted. Jan 22 '17 at 17:27
  • @GioraGuttsait - ah. Yes. This is a major drawback. It would be worth adding that requirement to the question.
    – ChrisF
    Jan 22 '17 at 17:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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