Tables/Disclosure hierarchy (Office hours: 22 Oct 2020)

[PoojMenon]

Hello,

I'm working on migrating the Subaccount usage page in the console out of PHP and mapping to Paste components.

There is however, no direct mapping for the components currently being used.

What I have attempted to do is use a combination of Disclosures and Tables to recreate a similar experience.

What I would like guidance or help with:

1. Are Tables within Disclosures the right way to do this?
2. The Paste guidelines require that every table have a header row. I would like to avoid having a header row within each disclosure - is there a way around this?

[SiTaggart]

Hi @PoojMenon, how confident would you say you are that the original design was the right way to display this data to the user?

You are correct, in that there is no one for one component right now in Paste, but even if we had built a Tree grid component, I still might as the same question. Is that the most appropriate and useful way to display that billing data?

Have you done any user testing on the current design? Do you know where you could make improvements to it? Given that this is a rebuild from PHP, now would be an excellent time to address any usability concerns.

Have you done any explorations in not showing the data in an overall table? So for each section design a sub total composition, and hide the details in a table under a disclosure like you have? The requirement that each column must have a header is a hard requirement, but I'm not sure if you necessarily need the the overall header if you explore some other options like sub-total compositions.

[PoojMenon]

Hi Simon,

The current scope of the work is just a short-term solution to get the existing pages out of PHP by year-end - full console redesign is on the back-burner while the focus is on monkey.

I have considered not using disclosures at all and instead just displayed the usage in an overall table with some indenting to indicate child rows.
Table - CodeSandbox

I think a table with child rows would be the ideal solution, but this should work at this time - would need to gather some data on how far the nesting might go and how many subsections a typical account may have.

Have you done any explorations in not showing the data in an overall table? So for each section design a sub total composition, and hide the details in a table under a disclosure like you have? The requirement that each column must have a header is a hard requirement, but I'm not sure if you necessarily need the the overall header if you explore some other options like sub-total compositions.

The problem with this would be that not all items necessarily have children - some of them are individual items. In which case, subtotals may not apply.

[serifluous]

Hey @PoojMenon! With indenting, while the hierarchy might show visually, it doesn't work for, say, a screenreader, which will read a "parent" and "child" row as 2 separate rows of data.

One other thing you could try is adding a second column that has the child product item in it like this:

Product	Product item	Quantity	Price
Answering Machine detection	Total	2	$1
Add-ons	Total	2	$2
	Add-on 1	1	$1
	Add-on 2	1	$1

From previous chats with the Billing team, I vaguely remember Product Usage needing to go 4 levels, so this exact suggestion might not be ideal, but could give you some other ideas on how you might restructure the table.

Looking forward to chatting more about this during office hours!

[serifluous]

Rounding out discussion here from office hours: @PoojMenon put together a CodeSandbox using a list of disclosures to show the data for now. An API call needs to be made to view the usage details for each product, which makes loading all the data at once on the page unfeasible (without 10–15s loading times).

We'll reassess how Tree Grid is prioritized in our roadmap since there's no suitable alternative right now. @PoojMenon Please loop us in when you kickoff research for this page!