If we wish to publish meaningful census data on our site,  we’re going to have to display tables of data. Rendering rows and columns of data is easy enough, but not if we wish to show tables on smaller screens such as exist on hand-held mobile devices like tablets and smart phones.  Shoving lots of data into a small space not only has it limitations, but should be avoided at all costs for reasons of usability.  At better approach (really the only approach), segmenting the delivery of large data sets into digestible, screen-sized pieces, requires design decisions to be made. Making such decisions can be done, of course, but we need to limit our design choices to interfaces that come by way of implementing inexpensive, out-of-the-box (and WordPress-compatible) tools. Unfortunately, there are not that many tools out there. Nevertheless, whatever paucity of choice there might be in this regard, whatever difficulty there is of publishing tables on small screens, these facts should not stop us from providing on the site (in some form and at the outset) census data because census data constitutes one of the most powerful ways to convince visitors of our claim that a rather diverse lot of people have resided in this part of Long Beach for a very long time.

As I say, inexpensive, out-of-the-box solutions for displaying large or complex tables smartly within the WordPress environment are not quite here. Ultimately, we need to find a tool (a widget, if you will, that does not require days to install or tweak or customize or program or implement) that can offer a visitor—even a visitor who is using a smart phone with a 3.5-inch screen—both an ability to see any or all of the fields that are present on a large table and be able to easily search and sort that data. The 1920 census, for example, has 29 columns and, for each ED, several thousand rows; for an ED with 3,000 rows that translates to 87,000 individuals cells of data; and there are 11 EDs altogether for 1920. Ultimately, say in a year, and without too much work, we can (and, I hope, will) gather together the data for all censuses from 1900 to 1940. So while we do not want to get to mired in the big picture, we do not want to ignore it, for our solution, if nothing else, should at least be able to scale with relative ease. Especially because there might be several persons at once hitting the site at once. Offering both high readability as well as high findability, it will be recalled, is one of our goals for the website. It’s true, of course, that we do not need to offer every column of data now nor, perhaps, ever; but the goal of viewing several rows at a time (and any row) and many fields (enough fields that the display of a row will surely overrun the right margin of the screen) is required now if we are to provide any census data at all in a meaningful way.

Though  inexpensive and easily configured widgets that respect responsive design principles and meet all of our criteria are not presently available,  they are coming soon. That much is clear. Now that the mobile phenomenon is an entrenched pattern of user behavior that is not going away, some very promising WordPress widgets are being developed for rendering user-selected segments of large tables on mobile platforms. All we need to wait for is for various features of these solutions to coalesce into a  single, affordable tool. Therefore, I advise not clobbering together a ‘custom-like’ solution at this time, which, even as late as last year, was probably the only way forward to do what we had planned—showing a modicum of tabular data in a ‘responsive’ way. Instead, thanks to the fact that several techniques that do a lot of what we want are now available,  I suggest that we choose one of them, live with its limitation(s), whatever it/they are for the next six months or a year, and update the site later with what will surely be by then improved out-of-the-box technology.

With this in mind,  here is a brief synopsis of what I think are our best choices for the time being:

• Selectively (programmatically, automatically) determine which fields can fit on a given screen and, initially, limit to to those fields, as happens in this example, which comes from this exercise. Note that the user can choose to look at other columns. This example offers no way to search and sort, nor even to page through the rows. Moreover, the orientation of the table is obviously ‘horizontal.’ But does it need to be?
• Take a look at this and this (with both of these latter two examples, start with a wide-ish browser window  and then resize the browser window to be narrower, and narrower still). A more complete solution for implementing  tables turned on their side is this implementation. These examples, in particular the last one because it is ready to plug right into WordPress and is therefore an attractive candidate to use, though it affords a means to search, sort, and page through the rows, it offers no way to select which columns display at a given moment.

To make better sense of these choices, I’ve provided three examples using 1920’s ED 8-81 census data:

• Table Press (non-responsive)
• Table Press (Responsive)
• A table inspired by the techniques inspired by the Filament exercise

These are not the only choices, but they should get our conversation started on how best to proceed.