Our ‘items out’ page is one of the most viewed pages on our ‘catalog’. This makes sense, people need to see when their items are due, as well as to (try and) renew their items, which is also done on this page.
Since it’s one of the most used, it makes sense to spend some time trying to make it nice and usable.
We are on in control of the items out page in our Rails (Blacklight-powered) ‘catalog’ app, as a pretty thin UI layer on top of our ILS. We use a combination of screen-scraping-like techniques and other horrible esoterica to provide our own UI layer. I think it’s worth it, due to how important this page is to our users, and it’s mostly worked out.
Well, at least we’re mostly in control of the UI, we are constricted in many ways by the underlying ILS, as well as by policies and business processes (that are, as a rule, much harder to change than technology, as most of my readers know!).
Anyhow, one of the first things we added to this page, which I’m still very proud of, is the addition of ‘relative time’ due dates like “1 week”, “6 months”, or “2 days”, using the Rails distance_of_time_in_words_to_now helper.
Here is a very early preliminary iteration of a someday-in-the-future new version of the page, part of an upgrade of our app to use a new version of Blacklight, and Bootstrap 3.x for the styling.
That is actually using an html <table> there for layout, which I think is probably appropriate in this case, it is essentially tabular data. (It would be fairly straightforward to do it without a <table>, especially if you are willing to use CSS “display:table” (if you don’t care about IE7), but I think a table is actually probably right.)
Ah, but part of this redesign (again, for the benefit of my local colleagues reading this, I will emphasize very early preliminary work) is to make sure the website works well on small screens and touch screens and small touch screens — you know, ‘mobile’. And I fully expect that the ‘items out’ screen will be just as, or more, used on mobile as on desktop.
What do you do with that page on a very small screen? How about something along these basic lines:
The first screenshot and the second screenshot are actually the same HTML, only transformed by responsive CSS, using basically the technique described in this blog post.
The HTML starts out <table> and is responsively transformed to block and inline-block display by CSS at small screen widths.
In retrospect, it would probably have been a better idea to start out with the block-display ‘mobile’ version, and use CSS media queries to responsively change to a table at large sizes, and it may iterate in that direction. (There’s a note at the end of the responsive table blog post with a link to an example of a mobile-first responsive approach).
That wouldn’t work in IE7 as it requires CSS “display:table” to responsively make something into a table display — or at least it’d be harder, you’d have to emulate a table with just sized divs. But once you’ve gone Bootstrap3, IE7 is pretty much a lost cause anyway. (Bootstrap3 says while IE7 isn’t officially supported, it ‘should look and behave well enough’ in IE7. But I suspect if you develop a site in bootstrap3 without testing in IE7 constantly as you iterate, most such sites are going to end up not working in IE7 and needing very significant reworking to do so).
But there would be some benefits to ‘mobile first’ here. It would mean that any browser which can’t handle media queries, or can’t handle setting “display:block” on <tr>’s and <td>’s — would get the more basic ‘small screen version’. Which is probably a better fallback than getting the table version even if you have a small screen, and definitely better than completing messing up a browser that can’t handle “display:block” on table elements, which the responsive table blog post warns can be a problem in IE9 and down. (Yeah, we still got to support IE9!)
It would also be more consistent with bootstrap3, which is also designed ‘mobile first’, with initial CSS appropriate for small screens, and CSS media queries changing display on larger screens. Bootstrap probably chose to go this way for similar reasons; but once it has, and you are building out your own CSS on top of Bootstrap, it pays to try and be consistent with Bootstrap. I’ve found that, when developing on a bootstrap3 framework, following my previous habits of designing for a large screen and responsively changing for smaller screens, can produce weird interactions with the bootstrap3 mobile-first CSS. Best to follow boostrap3’s lead when using bootstrap3.