Tables

[iuloshi]

Once demo page is built in Capital Framework, per #151.

[Dnpizarro]

@Scotchester has this been developed in FJ? If so can you provide some examples?

[benguhin]

Adding @marteki because she's scrum master and can delegate appropriately

[mebates]

https://pages.18f.gov/govt-wide-patternlibrary/elements/#tables

[caheberer]

Audit of cf.gov tables:

Reversed header, zebra striped, bordered
http://www.consumerfinance.gov/mortgage-rules-at-a-glance/

Colored header, no zebra stripes, bordered
http://www.consumerfinance.gov/hmda/explore#!/as_of_year=2013&section=summary
(generate a summary table to see it)

White header, no zebra stripes, no border

Special case / interactive
http://www.consumerfinance.gov/paying-for-college/compare-financial-aid-and-college-cost/

No header, zebra stripes, no border

Gray header, zebra stripes, no border

Updated responsive table currently being used in cf.gov refresh

Highlight interaction

[mebates]

Seems like we should have a standard for border and borderless, ala USDS.

Is there a strong UX argument for the zebra stripes? Is there anyone on cf.gov refresh who can speak to why they were chosen? Looks like USDS is not doing zebra stripes.

[jimmynotjim]

Zebra stripes definitely make it a lot easier to follow along when a table isn't responsive, because you're often scrolling back and forth, but for responsive tables like the Agenda linked above, it's a lot easier because each row is grouped with it's first column as a header and the original table headers are moved inline above their related content.

Now that we have this responsive table pattern, I'm not so sure we need the zebra stripes. @duelj or @ajbush might have compelling reasons to keep them though.

[schaferjh]

After the accessibility training I went through yesterday, I strongly advocate for keeping the zebra stripes. Anything we can do to help people distinguish rows of information is helpful and I don't see a con to keeping the zebra stripe.

[niqjohnson]

Based on all your comments (thanks!), the tables team has taken a first pass at the tables design manual page: http://niqjohnson.github.io/design-manual/ui-toolkit/tables.html.

The examples there aren't fully coded or functional (the sortable table isn't sorting, for example), but hopefully they're far enough along for everyone to get an idea of what we're thinking. Also, there are lots of open questions on the page (in bold) that we'd love feedback on.

One specific item we'd like feedback on: sortable tables. Would those be useful in the first release? What should the sorting icons be (we're aware that the arrows we have there now don't have enough contrast)?

Other than that, how's it looking so far?

[mebates]

Wow, awesome progress!

[niqjohnson]

Some feedback from the Fallingwater design working group on 8/17

• Put the "are" guidance before the "are not" guidance in "Use" section
• Include a section about setting column widths (and how browsers will try to set column widths automagically if widths aren't specified)
• Differentiate header background color in striped tables? Maybe a darker gray? Will that create accessibility issues?
• Consider locking the left column in scrollable tables
• Consider what to do for scrollable tables with really long cells

[ielerol]

This looks great, Niq!

I don't have a good sense of whether sortable tables are important enough for our purposes include in the first release, but I do have some thoughts on the sorting behavior. First, I'd want to make sure the entire header cell is clickable to sort on that column, toggling between ascending and descending. Maybe that's what you intended, but the hover states on the icons make me think that I have to click directly on an arrow to get the table to sort. If we have a hover state I'd definitely want to see it affect the entire cell.

I've looked for some examples of accessible sortable tables, and there aren't a lot of great examples, but I found this one and this one. The icon approach seems to be to show both up and down arrows at high contrast, and then remove the appropriate arrow when the table is actually sorted by that column.

Is there a solid use case for restricting some columns to not be sortable? I can see tables where I wouldn't necessarily care about sorting according to every column, but that doesn't mean it would be a usability problem to allow it. As a default I'd much rather provide the possibility to sort by any column, than assume I can tell when no one will want to sort a particular column.

I like the idea of locking the left column on scrollable tables.

Are we likely to need to combine some of the special cases? For example I'd assume that scrollable tables would also benefit from zebra striping, even with the left column locked. Do we want to be able to use highlighting on a striped table also? We don't necessarily need to show all the options in the design manual, I'm just thinking about potential recommendations for or against certain combinations, and whether needing to combine options will impact the way these are developed.

[niqjohnson]

@ielerol: All good points, thanks!

We're working more on sortable tables now. We'll definitely make sure the sorting trigger is easy to get to and decipher (I think you're right that the arrows are too small to be effective triggers). As for non-sortable columns, the plan for now is to leave non-sorting as an option. I haven't seen any tables currently in use on our sites that would absolutely require non-sortable columns, but I have needed it on past, app-ier projects to handle columns that just have actions (like "remove row") or images to prevent weird sorting.

The special cases are meant to be combined as needed, so a table might have both striping and highlighting. Good idea about having all scrollable tables be striped—we'll take a look at that.

[ielerol]

Oh, good point about non-text content in a table. I've dealt with that before, but in sad legacy apps where sorting was server-side only, controlled by dropdown menus. 😞

[JenniferHoran]

Yes, non text content in a table also needs markup for 508 :)

[jimmynotjim]

Do we have tables without text? Per the spec:

The table element represents data with more than one dimension, in the form of a table.

If it's not text, it's not data, so in situations where there's non-text content we should probably be using a definition list.

[JenniferHoran]

So for 508, think of a table as a grid from a game of battleship. I like to see markup in every cell, even if the cell is blank, because the assistive technology user needs to know where they are in the table. Some kind of markup indicating that this is an empty cell is a best practice even if a visual user would never know that this is there because you've indicated it programatically.

For example if I'm building a table in a Word doc to export to PDF, I type "empty cell" in white text in an empty cell that has a white background, so that the screenreader or AT user will know it is there but the non-AT user would have no idea that the sneaky little markup is included in the empty cells since the white on white text is visually "hidden". If you are using HTML or InDesign or other authoring tools there are other ways of marking up cells, of course. You've probably also seen a dash like "-" in empty cells on a lot of tables people put out, and that is part of the reason why the dash is there, to draw focus on the empty cell so that the AT user knows where they are within the table.
You have to know where you are so you can sink that battleship :)

Thanks!

[marteki]

Code pull request is live: cfpb/cf-tables#3

[schaferjh]

@marteki @niqjohnson Sorry come back to this -- and I may be misreading the pull request and or Nicholas' page prototype -- but it appears to me that when the "highlighted rows" interaction was removed, no other direction was made about how to indicate interactivity in a table cell/row (links, downloading etc).

Is that correct (and as a result we're leaving interactivity up to individual teams to implement) or am I missing something? Thanks!

[niqjohnson]

@schaferjh: Correct, there's no standard for links/buttons/other click-y things in tables anymore. My thought is that individual teams can style those elements as they see fit, and if a standard starts to emerge from those implementations, we can add it to the Design Manual later.

[schaferjh]

@niqjohnson OK. Thanks for the clarification!

[Scotchester]

Update: cf-tables is live in Capital Framework.

Remaining steps:

• Add the cf-tables component to the Design Manual's dependencies.
  • This will necessitate transitioning the DM to CF Voltrazord. Shouldn't be toooo much of a pain.
• Merge in @niqjohnson's content page.

[niqjohnson]

Question I came across while putting the finishing touches on the tables Design Manual page: now that the individual cf-whatever repos are deprecated, where should the repository links at the top of each Design Manual page point to? For example:

Should that "cf-tables" link go to https://github.com/cfpb/cf-tables (like the rest of the pages, even though the first thing you see there is a big old THIS REPO IS DEPRECATED)? Or https://github.com/cfpb/capital-framework/tree/canary/src/cf-tables? Or somewhere else?

[Scotchester]

I think most like it should indeed be https://github.com/cfpb/capital-framework/tree/canary/src/cf-tables

Agree, @cfpb/front-end-team-admin?

[contolini]

@Scotchester 👍

There's also the gh-pages usage pages but my understanding is that the DM pages will supplant them?

[Scotchester]

@contolini Eventually the DM will have its own code snippets. But there's probably still a value in linking to the source code somewhere on the page, like in that little repository box.

[contolini]

@Scotchester Gotcha. Linking to the capital-framework/src/COMPONENT directories makes sense to me.

[niqjohnson]

And juuuuuuust in time for the end of the sprint, here's the tables Design Manual page with all the new content: http://niqjohnson.github.io/design-manual/page-components/tables.html

And a screenshot just in case:

@kurzn and @sonnakim, how's your new content look in that page?

@caheberer, everything look right to you?

[caheberer]

@niqjohnson looks great to me!

[sonnakim]

@niqjohnson Looks good to me, too! Thanks for taking the time to accommodate all of the new content into the page 👍

One question: would it be a major headache to work in both screenshot examples under the Directory Tables section, as shown below? It would be great to show the larger breakpoint style for comparison.

[niqjohnson]

@sonnakim: Easy change to make (also viewable at http://niqjohnson.github.io/design-manual/page-components/tables.html):

How's that looking?

[sonnakim]

@niqjohnson That looks great! 🙌

[niqjohnson]

Hey look at this! http://cfpb.github.io/design-manual/page-components/tables.html

I think this is done now, right?