---

Something that I and I imagine many people struggle with is designing and implementing a table in an enterprise setting. There are so many examples of good and pretty tables but usually the amount of data they show is much less than what I run into inside a company.

Usually I'm trying to display 15-20 columns and some of these columns might be really long descriptions and others have long column names. Often times the tables could be streamlined but because there are many users and they all value different things, we need to have all the columns available.

The solution is usually to make it a full report rather than a web app but it would be nice to have it accessible as a table on a web page. The following is going to be my thoughts on how tables should work and what features they need to have in an enterprise setting.

The first is that a table is composed of 2 parts, there is the key of the table, this is the items we are looking at. This is often the left most column of a table besides the numbering column.

The second is that tables have attributes, this is the column headings of a table.

Now data in a table can be compared in 2 ways. You can compare items against each other so you'd ideally like to control which rows are currently visible. For example, if you had a product listing, you might want to compare 2 products to see what the differences are.

You can also compare attribute to each other. For example if you are looking at a product, then seeing the sell price and the cost would be valuable.

I also believe that tables that work on a desktop should also work on your phone. Mobile is king now and many people expect everything to work as well on their phone as it does on their computers.

Given that set up, these are some notes:

Column Specific

• Tables should scroll horizontally and vertically. The container they are in should scroll rather than the whole page. This is what users expect.

• The left most column should be locked in place. This way scrolling horizontally will not lose the column that determines what items you are looking at.

• The header row should also be locked in place. Scrolling vertically shouldn't lose what attributes you are looking at.

• Have some sort of indicator to show which columns are currently in focus. This can be a set of dots that shows that you are viewing some subset of the available columns.

• Columns should be reorganiable, this means a user should be able to move them around

• Columns should be resizable, this means they can change the size of a column

• Columns should be lockable, this means they should be able to freeze a column and scroll

• Columns should be hideable, this way users can hide columns they don't need

Table Specific

Now that we have the columns figured out, the next thing is that tables should all be filterable, sortable and searchable.

• You should be able to filter data based on the type of the column, for example each column should be able to use the greater than less than options.

• Each column should be sortable.

• Searching a table should search the entire table and it should highlight the part of the word that matches the text.

Tables should also be paged, though I haven't decided if I like showing just a next and prev button or if seeing page numbers is important. I like page numbers but given a total count and a number of results per page you can get an understanding of where you are. The page numbers makes it more explicit but it gets messy when you get to many many pages.

Styling

• Tables should have a horizontal line separating rows. This makes it easier to visually tell distinct elements.

• A good default height for a tight table is 40px.

• Each column should have 16px of padding on either side of the text, this means a min size of a column is 32px

• There should be a clear delineation between the header and table, this can be done through bolding the text or by changing the background of the header

• Numerical data should use a monospaced font so that numbers can be easily compared

• Columns should be aligned properly, text is left and numbers are right justified

• Column headings should align with their data and icons shouldn't interfere with that. That means for number columns, icons should be to the left of the heading

• You can use a subtext within a cell to show extra data

Actions

The above all deal with the presentation of a table, if you can have actions then there are also other things that need to be done.

• You should let cells be editable but clicking a cell should unlock the entire row.

• Any save buttons should be on the left side of the table so that scanning is easy. The primary button should be clearly marked.

• Bulk actions should be allowed if it makes sense and they should be outside the table and on the top.

End

These notes were made after reading the following articles:

https://medium.com/design-with-figma/the-ultimate-guide-to-designing-data-tables-7db29713a85a

https://coyleandrew.medium.com/design-better-data-tables-4ecc99d23356

https://pencilandpaper.io/articles/ux-pattern-analysis-enterprise-data-tables/

https://ux.shopify.com/lessons-from-building-mobile-friendly-accessible-data-tables-1e05c6924eaf

My only wish was that there were some examples of large data sets with all these ideas. I'll need to wire something up and see how much of this stuff is really valid. Everything makes sense when laid out this way but I want to optimize for both the person using the table but also for the developer making this table.

For that reason I'm going to stick with vanilla js for the functionality and try to keep things as semantic as possible. The goal is to try and get all these things done with as little code as possible.