The Ancient Sumerians, Tablet Computing and HTML Tables

Alex Walker

A Sumerian clay tablet with columns of cunieform. From 2600 BC onwards, the Sumerians wrote multiplication tables on clay tablets

This is a 5,000 year old clay tablet from ancient Sumeria (modern Iraq). It counts among some of the earliest known written texts.

So what are we looking at?

  • Is it poetry or song?
  • Maybe religious doctrine?
  • Perhaps a diary of daily life?

No, it’s none of those. Even if you skipped ancient sumerian language class at college, you can probably already guess that we're looking at some kind of table of data. Ancient number-crunching thousands of years before Pythagoras or Euclid.

In fact, we know the Sumerians were total nerds when it came to their record keeping. Most of the tablets we've recovered from Sumer are tax records, crop yields, stock lists and general bookkeeping. We probably know more about their economy than we do of their hearts and minds.

One thing is clear: From almost the instant that writing was invented — even before iron or bronze or cornflakes — people understood the power of a data table.

Tables allow our brains to work with much more data than our built-in 'RAM' memory usually allows us to. We know our short term memory starts to struggle with any more than seven items, but tables allow us simultaneously consider 15, 20, or even 30 items at a time.

That is a seriously useful invention.

Tables & Mobile

Recently there's been some front-end dev discussion on what is the best way to present tabular data on smaller screens.

Last week the LivingSocial techblog published an interesting new approach which completely re-structures each table row into a standalone units at smaller sizes.

Animation: Table rows are completely re-structures each table row into a standalone units at smaller sizes.

There are definitely some occasions where this stacking technique would be a great fit. In particular, tables that are always going to short, such as shoe sizing charts or store opening hours.

However, I do wonder if we're too easily giving away the true beauty of tables when we choose to boil down their bones.

For instance, take a monthly bank statement rendered in this stacked view on your phone. Locating an important transaction that took place on October 14th requires a much higher ‘cognitive load’ when you lose the column view.

And even though we have less available screen real estate, we've gone from rendering a single row of column headers to rendering headers on every single record — conceivably dozens of them.

That doesn't feel like a win to me.

Optimized Tables

Sometimes we might find ourselves trying to 'power layout' our way out of an information architecture problem. Your backend developer spat out 6 columns of table data, so 6 columns is what you're going to layout!

I think our first step should _always_be to try to optimize what we're putting in the original table.

Some simple questions to ask are:

  • Is each column relevant to a mobile user? For instance, your cash position after each transaction is interesting on a printed bank statement, but arguably overkill on a phone.
  • Is there a more succinct way of communicating the same data? (i.e. instead of writing '02/01/2015 – 02/28/2015' can you simply write 'Feb' on mobile?)
  • Does it make sense to hide fine-grain detail behind a ‘More’ link and modal? For instance, a transaction date cell might link to a modal detailing precise transaction times when required.

A Sainsbury's supermarket receipt

For this, think about that mundane shopping receipt/docket you throw away each week. It's generally a great example of well-optimized, small-format table data.

The Sainsbury's example above comfortably lays out the product, country of origin, price, and even how far it has travelled on a strip of paper probably narrower than your phone. While it's not quite beautiful, it's certainly an effective use of available space for the purpose intended.

Ok, but what if you have optimized your table, but you still struggle for space?

Tablesaw: A Flexible Tool for Responsive Tables

Last year Mat and Zach at the Filament Group released the code for Tablesaw, a great approach to the problem.

Animation showing the different modes for Tablesaw.

While Tablesaw does offer a 'Stacked' table view, it also offers two other useful views.

  • Toggle view: which lets you switch select only the columns you want to see.
  • Swipe Table: which keeps the main left column in place while allowing you to swipe left and right to access other columns.

While no single approach fits every scenario, it's hard to imagine a situation that Tablesaw couldn't handle.

Have a play with their demo here.

Originally published in the April 8th SitePoint Design Newsletter