Table Component about design-system HOT 7 CLOSED

I've defined an example of the API using some pseudo JSX below.

It shows a declarative way of defining the output and behaviours for each individual column. I've used a render prop in order to allow column data to be mapped to arbitrary template components.

const data: []TableRow = [{
  foo: 'Hello, World!'
}]

<rn-table 
  caption="Example Table Caption" 
  data={data} 
  borderless 
  selectable
>
  <rn-column 
    label="Example Column 1" 
    render={({ foo }) => (
      <arbitrary-template-component bar={foo} />
  )} />
  <rn-column 
    label="Example Column 2" 
    sortable 
    sortMethod={() => { /* Custom sorting logic */ }} 
    width="300" 
    empty-text="No Data"
    background="#C9C9C9"
  />
</rn-table>

Multiple Implementations

I'm not completely convinced we need to split it into two distinct implementations. Could interactive table not just be used for data table (albeit decorated with less functionality)?

Striped Columns

This background cannot be used to vertically "stripe" the table - all columns that have the background should be grouped together and fixed to the right hand side of the table.

This sounds overly restrictive from a developers point of view. I can see there being a use case where you would want to dynamically highlight certain columns.

Responsive

What are we going to do about mobile? I think these components need to simply scroll horizontally. I don't see any other way of making them work on smaller form factors (without heavily restricting how they are used).

I think the stacking card like table (as seen in the docs-site) should be an additional component (separate from this table implementation).

from design-system.

Obvious clickable items

It's good that cells in the interactive table can be interacted with but an issue has come up in testing where users don't realise that the items in the table are clickable. Relying on hover isn't enough evidenced by user test videos.

A common use case is to use the table as a home or start point to view a summary of status and actions. Users want to view the detail and return to the table. which means there needs to be an obvious way to view underlying detail.

1. In the use case above, not every cell needs to be interacted with and in fact it slows the user down if they don't have a clear element to click on to view the underlying detail of each item

2. Some underlying detail could be viewed in the right hand sidebar fly out, but the small side bar isn't big enough for certain types of detail. Some detail takes up a whole screen or even several screens.

3. What are options to make it clear something is clickable?

4. one option is underlining clickable items in tables to make it obvious they were links. but designers don't like the ugliness of underlined links.

5. on principal I believe we must put usability before design, whatever the solution is

from design-system.

@m7kvqbe1 and @users-champion I've added my responses to the points above. Let me know if you have any questions.

Multiple Implementations

I’m not completely convinced we need to split it into two distinct implementations. Could interactive table not just be used for data table (albeit decorated with less functionality)?

Yeah, this is a fair point. I was trying to establish a visual difference between Tables that have their entire rows clickable and Tables that only the individual cells (/the content inside the cells) are clickable. You can’t have both a row and a cell clickable in the same table, so having this distinction may help comprehension. I’m happy to combine the table into one, although communicating this difference may need some thinking.

Striped Columns

This background cannot be used to vertically “stripe” the table - all columns that have the background should be grouped together and fixed to the right hand side of the table.
This sounds overly restrictive from a developers point of view. I can see there being a use case where you would want to dynamically highlight certain columns.

1. Dynamically highlighting tables will definitely be useful, however I really wish to stay away from allowing implementers to arbitrarily stripe the backgrounds of table columns. I feel this will cause the background change to lose meaning and just be used as a decorative feature.

Responsive

What are we going to do about mobile? I think these components need to simply scroll horizontally. I don’t see any other way of making them work on smaller form factors (without heavily restricting how they are used). I think the stacking card like table (as seen in the docs-site) should be an additional component (separate from this table implementation).

I think we should allow both options - maybe it’s on the implementer to decide which style is most appropriate? I can see use cases for both responsive methods. Sometimes the scrollable table can be hard to digest, especially if there are a large number of columns. Maybe in this instance, presenting each table row as a card may be the better way to convey the data. Either way, I don’t have a preference for a particular style, but perhaps we should offer recommendations as to the best approach for mobile.

Obvious clickable items

It’s good that cells in the interactive table can be interacted with but an issue has come up in testing where users don’t realise that the items in the table are clickable. Relying on hover isn’t enough evidenced by user test videos.

Is this specifically for links or for the more visual components? Links are easy to solve as we can add the Link icon to each of those. That’ll at least provide visual separation between default text in the table and links that can be clicked.

Subcomponents I’m unsure how to tackle as we can’t underline them/add a share icon. Hopefully their design will convey if they’re intractable or not. May need to revisit this.

Hover though is literally the THE interaction on web applications. If users don’t know what to do when they hover on something and get interaction feedback (e.g. transition on hover etc), then we have a much larger problem than the users not understanding how to engage with the table subcomponents. There needs to be some form of education to ensure users understand how to interact with apps in general if this is the case.

A common use case is to use the table as a home or start point to view a summary of status and actions. Users want to view the detail and return to the table. which means there needs to be an obvious way to view underlying detail.

This feels like a pattern that is much larger than the table itself. Whilst this is a flow we should definitely be using in our applications, the starting point doesn’t necessarily have to be the Table - it could also be a list, or a set of cards.

In the use case above, not every cell needs to be interacted with and in fact it slows the user down if they don’t have a clear element to click on to view the underlying detail of each item

We can hopefully tackle this with the icon for links, however there is always going to be a bit of a learning curve with any new software you use. Yes applications should be as initiative as possible to use, however these apps need room to be powerful tools that are used daily by users. If someone doesn’t get something on their first pass, then let’s obviously look at it. I don’t think that just because they weren’t 100% on their first interaction with the app that the feature/pattern/component is wrong. There will need to be learning on both sides. Whilst we should ensure our software is as easy to use as possible, I wouldn’t want to start sacrificing it because a user takes a bit longer to understand stuff on their first exposure.

Some underlying detail could be viewed in the right hand sidebar fly out, but the small side bar isn’t big enough for certain types of detail. Some detail takes up a whole screen or even several screens.

Yeah this is a pattern to define at a higher level. What sort of flows do we want the user to have when using our applications?

What are options to make it clear something is clickable?
We can add the link icon to anchor text, however individual subcomponents will have to be looked at on a case-by-case basis.

One option is underlining clickable items in tables to make it obvious they were links. but designers don’t like the ugliness of underlined links.

As I commented above in this post, hopefully the inclusion of an icon next to clickable text should hopefully mitigate this problem.

on principal I believe we must put usability before design, whatever the solution is

I certainly don’t believe these are mutually exclusive at all - we should be striving for both :)

from design-system.

I don't feel this needs 'sign off'. There's a great amount of discussion in here and I like the approach (discussed in person) of building it incrementally (starting small) and also of getting feedback as we go.

I also like the idea of a separate area within the doc site to allow for some of the variations to be illustrated properly. It would be good to see that appear as part of the first built iteration rather than waiting for more table functionality to be implemented.

from design-system.

Breaking this down for a first pass at building it, I imagine the easiest route would be to construct a table that either accepts an array of data or an arbitrary component (e.g. badges). We should make it responsive, with the table horizontally scrolling at smaller screen sizes.

Sortable headers, table specific sub-components, and the stackable cards can come at a later iteration.

@Royal-Navy/standards-team Is there anything else we should add/omit for v1?

from design-system.

Found a pattern request from Project L, which asks for "Table Totals". Rather than lose it or create it's own component / pattern issue, I thought I'd add it here because the requirements are just more advanced features of the table:

Table Totals

• Self service analytics
• Present counts, sums, averages, etc.
• Calculate and present percentages
• Calculate and present totals

from design-system.

The basic table component is done and there are also PRs for arbitrary cell content and sorting.

from design-system.