Components: Tables

[jrubenoff]

cc: @jeffmaher

Stories

• As an author of a guide, I want visitors to easily browse my content no matter what device they're on, so that they don't abandon the site from frustration.

Notes

• See the component doc for more information
• This ticket covers both design and development tasks. Change assignee of the ticket based on who has the next action, and remove the person or people that no longer have an action. It's expected that a ticket will get passed back and forth a few times.

Done When

• [ ] UX: Component design is drafted and shared for review
• [ ] Dev: Component design is reviewed and approved
• [ ] Peer UX: Compontent design is reviewed and approved
• [ ] Dev: Component style and markup is developed and shared for PR review
• [ ] Dev: Documentation on how to use component is drafted
• [ ] UX: Component style and markup is reviewed and approved
• [ ] Peer Dev: Component style and markup is reviewed and approved
• [ ] Component is available for use

[jrubenoff]

A note

Tables are really important for the OPO report. They're the best format for content like Section 10's appendices:

By contrast, the table body in Section 1 of the playbook contains a single row of bulleted lists. They're very hard to read with our current typography style.

I'd highly recommend replacing this table with a series of headers and bulleted lists.

Perhaps we could use the Grid component (#15 or #16) to save space.

Design challenges with tables

They're very hard to read on smaller screens.

The "Responsive table patterns" section of this comment concisely summarizes of the pros and cons of different approaches. (Also see the Tablesaw plugin docs.)

It's easy to get overwhelmed here, so I constrained myself by designing for the tables we currently have, rather than whatever tables we plan to add in the future.

The OPO report's tables contain:

• One header row with multi-line labels
• No header columns
• Mostly text, not numbers

It doesn't seem like readers on small screens would benefit from a ton of interactivity here. They don't need to compare data across rows or columns. They just need the content to be legible.

So I've collapsed each row on smaller screens like so:

On larger screens, I made the table header sticky so readers can easily see their context.

The styles for the sticky header target <th> elements. We can add documentation encouraging the Bloom staff to use something like this tables generator, which will ensure Markdown outputs semantic markup here.

Status

I've committed an example to the storybook branch. I can open a PR with just the table styles once #5 and #6 are done.

---

@jeffmaher @SMakaiTakori Let me know if you have any comments or questions!

[SMakaiTakori]

@jrubenoff Thanks for your hard work on this! I like the idea of collapsing the table rows for smaller screens, it makes the content more readable.

For the larger screen design, I am thinking the sticky header could be an accessibility issue, because animations can be dizzying/nausea/distracting where we might just want to add a button at the bottom of the page to scroll back to the top of the page, but I would like to hear what @admoorgit and @jeffmaher think.