Responsive Tables

Before I get started, I should warn you, I’m putting my geek cap on for this one.

If you’ll recall, the new Lane web design is responsive (if you don’t remember what that means, check out the original post). Unfortunately, there are two parts of our website that dislike being responsive: images and tables.

The problem with images has to do with size. If you’re on a cell phone, you have very limited screen space. So you don’t want to download big huge images, only to have your cell phone shrink them down. That wastes both bandwidth and processing time on your phone. In other words, it’s a slow page. But despite that problem, at least the page still works and looks right.

Tables are a different story. Here’s an example of a non-responsive table:

Program Entry/Application Application  Deadline Prerequisites Schedule/Location Contact Person
Bridge to C.N.A. Application tk Bridge Prerequisites TBA / LCC Juanita Kirkham
C.N.A. I  Application tk C.N.A. I Prerequisites TBA Juanita Kirkham
Healthcare Professions Orientation Call (541) 463-5223
to reserve your space
Open until filled TBA /LCC WorkSource Lane at LCC Staff
Fundamentals of Microsoft Word 2010 for the Workplace Call (541) 463-5223 to be placed on waiting list Open until filled Typing Speed: 15 words per min. Ongoing two 5 week sessions a term/LCC WorkSource Lane at LCC Staff
Fundamentals of Microsoft Excel 2010 for the Workplace Call (541) 463-5223 to be placed on waiting list Open until filled  Typing Speed: 15 words per min. Ongoing two 5 week sessions a term/LCC WorkSource Lane at LCC Staff
Basic Computer for the Workplace Call (541) 463-5223
to reserve your space
Open until filled  – Ongoing-3 weeks/LCC WorkSource Lane at LCC Staff

Look ok? Try making your screen narrower or viewing this post on a cell phone. Your web browser recognizes that this is tabular data, and that it doesn’t make much sense if you can’t see the entire row. But your web browser also runs into a hard limit – the width of your screen. As your screen shrinks, the web browser will continue trying to reflow the text – meaning re-lay it out – in the table. But eventually, either the table needs fewer columns or the browser needs to break words apart to get things to fit. Neither answer works. So it just draws some of the table off the right edge.

This can be real problem on a mobile phone. In a best case, it’s just kind of ugly, and you can scroll the page with your finger to see off the right edge. In the worst case, the phone won’t let you scroll (or you’re on an older device where you can’t scroll), and you can’t see the right side of the table at all.

There’s been a series of excellent write ups on different ways to approach this problem, so I won’t rehash them all here. We considered two – flip scroll and “no-more-tables“.

First, we tried Flip Scroll. It’s an almost ideal method – it preserves the visual layout of the table, without adding much additional content. But we found that it didn’t render correctly in earlier (1.x and 2.x) Android devices, which represent the majority of our Android users. There were also some concerns with accessibility, since it makes it harder to tell how rows flow together. So we moved on to “No-More-Tables”. This method does change the visual appearance on mobile, but it was supported on the dozen devices I tested.

To see these tables in action, take a look at any page on the Lane webpage that has a large table on it, such as the the Workforce Development Short Term Trainings page. Because we’re rendering tables responsively on the client side, nothing needs to change for our content editors – they just keep on making tables like normal. The only exception to this rule is if there’s a table where the data series are in rows rather than columns. If that sounds like a problem you might have, see the table documentation on the internal Drupal Help Site.

If you’re interested in knowing more about Drupal and/or responsive tables, let me know in the comments, and I can publicize the mini modules we made to try each of these techniques.

EDIT (7/31/12) – One of these modules is available on Github

Better Ways to Track Progress

In an effort to understand the progress we’re making, we spent a few minutes earlier this week figuring out what the biggest “chunks” of the website are. Of course, once we had some data, we had to do a little bit of analysis. The results are now linked on the menu bar up above under “Current Progress“.

On that page, there’s two graphs which display the percent of our chunks in these five statuses:

Status Meaning
Cut Chunks that are just going away – still stored on backups, but not linked from anywhere.
Archive Chunks that pertain to old projects that need to be kept around for either legal or historical reasons. They’ll be stored on the Site Archive
Review Chunks that have been moved into Drupal, but need a final review before deployment
Done Chunks already moved into Drupal
Not Complete Chunks still on the old web server. This is chunks that are in progress or haven’t been started

Here’s the first graph, which shows the percentage of individual pages in each status:

Here’s the second graph, which shows the percentage of departments in each status*:

The best part about these graphs is that they update every time we update our spreadsheet. So, some day several months down the road, instead of these images showing a lot of grey with a little bit of yellow, they’ll show a lot of orange and no grey at all.

Unfortunately, I only have statistics for the pages that are still on the web server. If I included the work done last summer, when we deleted over 5000 pages, which would have made that first graph 46% blue!

* technically, this is the percentage of top level folders on the web server in each status, but that’s a pretty close approximation to departments.

Deployments this week

Three more sites are up in Drupal this week, including some that were never on the web before:

There’s also been a good deal of progress toward improving our backend setup, including fixing our version control server, more tuning and testing of our two reverse proxy servers, and quite a bit of work in fixing our forms handling. Expect to see bigger chunks in Drupal next week!

Search Tips & Our Mini

As previously mentioned, we’ve been tuning our Google Mini the last few weeks. Hopefully you’re getting a much better search experience. But to make sure you are, starting yesterday, when you do a search on our search server, you’ll find a blue bar at the top. If you do a search on our site and don’t find what you’re looking for, click the link in the blue bar and let us know! I’ll do my best to try to figure out what went wrong.Thanks Jace Smith for the suggestion to make a feedback form in the first place!

The Google mini is also going to provide us with lots of interesting search statistics. While it’s too early to look at them now, it’s not too early to talk about how we’re going to use these statistics to make a better website. Every week we pull a list of the 100 must commonly searched for keywords and phrases. Over time, we’re going to look for trends and try to learn what people can’t easily find on the website. So, if “Bike Lane” keeps showing up, we’ll know that we’re not doing a very good job of making “Bike Lane” easily findable on the homepage, and we’ll try to fix that.

We’ll also be using these statistics to improve the actual results of the search. For example, if we notice that people keep searching for “nuring”, we’ll tell the Google Mini to search for “nursing” instead. Or if a department changes it’s name, and people keep searching for the old name, we can tell the Mini to search the new name and save lots of confusion.

I should also note that although I’m trying to make the mini work as awesome as I can, I can’t control what Google does. So when you search on google.com, that has nothing to do with our search engine, and there’s only so much I can do to improve your results. That leads us to Search Engine Optimization, which is much too big of a topic for this post.