古代苏美尔人，平板电脑和HTML表格

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

这是一种来自古老Sumeria(现代伊拉克)的具有5000年历史的黏土板。 它属于一些已知的最早书面文本。

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.

实际上，我们知道苏美尔人在记录方面是完全书呆子。 我们从Sumer回收的大多数药片都是税收记录，农作物产量，库存清单和一般簿记。 我们可能比他们的内心和思想更了解他们的经济。

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.

表格使我们的大脑可以处理比内置“ RAM”内存通常允许的更多的数据。 我们知道我们的短期记忆开始遇到超过七个项目的困扰 ，但是表格允许我们同时考虑15个，20个甚至30个项目。

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.

上周， LivingSocial技术博客发布了一种有趣的新方法 ，该方法将每个表格行完全重组为较小尺寸的独立单元。

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.

例如，以手机上此堆叠视图显示的每月银行对帐单。 当您丢失列视图时，定位10月14日发生的重要交易需要更高的“认知负荷”。

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!

有时，我们可能会发现自己试图通过“电源布局”解决信息架构问题。 您的后端开发人员吐出了6列表格数据，因此6列就是您要布局的内容！

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

我认为我们的第一步应该_always_be尝试优化我们要放入原始表中的内容。

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?)

  有没有更简洁的方式来传达相同的数据？ (例如，您可以在移动设备上简单地写“ Feb ”，而不是写“ 02/01/2015 – 02/28/2015 ”)

• 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.
  将细粒度的细节隐藏在“更多”链接和模式后面是否有意义？ 例如，交易日期单元格可能会链接到详细说明所需交易时间的模式。

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.

上面的塞恩斯伯里(Sainsbury)的示例轻松地列出了产品，原产国，价格，甚至在可能比您的手机窄的纸条上走了多远 。 虽然它不是很漂亮，但可以肯定地有效地利用了可用空间。

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

好的，但是如果您优化了表格却仍然在为空间而挣扎，该怎么办？

Tablesaw ：用于响应表的灵活工具 (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.

去年， Filament Group的 Mat和Zach发布了Tablesaw的代码， 这是解决该问题的好方法。

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

尽管Tablesaw确实提供了“堆叠”表视图，但它还提供了另外两个有用的视图。

• 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.

尽管没有一种方法适合所有情况，但是很难想象Tablesaw无法处理的情况。

Have a play with their demo here.

在这里玩他们的演示。

Originally published in the April 8th SitePoint Design Newsletter

最初发布于4月8日的 SitePoint设计时事通讯

翻译自: https://www.sitepoint.com/ancient-sumerians-knew-html-tables/