Fun with Tables

For those who have maybe read one or two of my posts, you may have noticed that I draw inspiration from current events at my day job. It’s been awhile, but I’ve recently been asked to create a user experience for a table with the following display and functionality requirements:

1. There is a default set of data that needs to be displayed, but no one seems to know who to ask to find out what the data is exactly
2. The table can potentially display up to 17 columns (17 data segments)
3. Users can customize the table view by hiding or revealing columns (data segments)
4. Users can customize their table view by reordering the columns (data segments)
5. Users need to be able to filter table data (rows)
6. The table needs to be responsive, because the site is responsive
7. We’d already designed a card view (previous iteration of a table scenario with less requirements), so our “new” table scenario needs to have continuity with the card

By now we (as an industry) have more or less figured out how tables on modern web sites (RWD) can render depending on the size of the screen. Such as:

1. Tables (containing only numeric data) that switch to a pie chart when viewed on a small screen.
2. Tables (with numeric and text data) that transition to a card or “cell” view when viewed on a small screen. See example.
3. Tables that hide less important columns for smaller screens (not my favorite approach). See example.
4. Similar to above, but a drop down menu is available to re-enable hidden columns that can be accessed with horizontal scrolling. See example
5. Tables that flip x and y axis for smaller screens so the column headers are always visible while the data cells scroll left and right (on a small screen). See example. 
6. Tables where the left-most column is “locked” in position on smaller screens and the remaining columns scroll, allowing for row-to-row comparison. See example.
   

Obviously, this isn’t the end-all-be-all list, but you get the idea. There are a lot of solutions out there, and luckily for me, I was able to adapt aspects of them for this particular ask. (With a little e-commerce conventions sprinkled in.)

Small Screen, Card View:
I decided that since a card view already existed (though with only 8 data points displayed), we would take a retail approach and treat this view as an “e-commerce” product card. Most e-commerce sites’ product cards (or tiles) contain an image, title, price, rating stars and number of reviews. In order for the customer to see more information about the product she needs to click through to the corresponding product detail page (PDP). Easy-peasy mental model.

Since each row in our table represented an individual item, and each item just happened to have a corresponding detail page, it seemed a logical solution. Why overcomplicate?

Also, it was decided that there was no point in offering the user the option to customize the information (requirements 3 & 4) while in the card view. The card data was predetermined and order locked, meaning trying to hide/reveal or rearrange the order would be a pointless exercise in futility. If the user wanted to see more item details and info, she could click or tap on the card detail to go to the corresponding detail page.

Medium Screen and up, Table View:
Adding a menu to hide/reveal columns was no biggie, especially for larger screens that had the real estate. Also, a filtering mechanic wasn’t an issue either, since the card view had to be filterable as well. Because we had solved for the question, “WTH what happens on a small screen?” it was just a matter of WTH happens when the medium/large screen gets smaller, but not small screen size.

The biggest issue of course, was the fact that the table didn’t have a set number of columns.  At any point in time a user would be able to hide/reveal/reset columns and rearrange the order of columns to suite their browsing preference. Regretfully, there was no user data to help inform any user scenarios, so we winged it.

It came down to two relatively obvious options: 1) the entire table is scrollable left-to-right (once the screen was reduced for overflow to kick in), advancing one column at a time, or 2) the left-most column would be “locked” and the remaining columns would scroll horizontally.  We went with option 2.

I really like Option 2 because it’s a brilliant solve for a table that has rearrangeable columns. Users can decide what information is most-to-least important that needs to be visible. As the screen sizes reduces, the most important information will remain visible, and secondary information accessible via horizontal scrolling.

We also decided to implement the ability to export the whole kit-and-kaboodle to Excel, just in case a user had hundreds of entries.

Fun with Excel.