*Update* see more responsive tables progress (5th Jan).
A real short post for future reference! I’m experimenting with a responsive calendar design and build. See my very rough responsive calendar demo.
I’ve found through trial, error, and much pondering that the idea of a responsive calendar is actually not that complex. My demo needs more considered breakpoints and design tweaks but it proves the concept. I’m thinking about developing it into a fully fledged HTML & CSS baseline for others to build upon.
I’m also looking into more traditional tabular data as that seems to be trickier to tame in responsive web design. After a lot of Googling and a few tweets with Harry Roberts and James Young (two fellas who know their stuff) it’s become apparent that no one has really cracked responsive tables yet.
Chris Coyier at CSS Tricks presented a good idea in August 2011. His solution requires hard-coded content inside CSS, not good at all for many reasons. Chris Garret has evolved the idea very recently using data-* attributes in HTML and the content: attr(data-*) technique in CSS. A great improvement but still limiting. In the end, I’m not convinced the final small-screen view of this technique is really the best solution. The ability to compare related data sets is reduced greatly. That said, I’m at a loss as to where this can be improved.
My calendar demo also hard-coded the labels “Monday” to “Sunday” within the CSS file. That’s only slightly more acceptable until you consider localisation for language support. It’s just asking for trouble later on. With more care I believe the calendar format can be nailed. I’ll keep you posted!
Filament Group blogged a different idea in December 2011 that maintains the table appearance by reducing the columns visible. It relies on JavaScript for the interactive choice of visible columns (making it an acceptable use of standards), but again, only suitable for certain data. I’ve been dreaming up more outlandish uses of JavaScript to change presentation/interaction but as a baseline the visual layout, style and presentation should never require it.
One thing that quickly becomes obvious is that there is no single solution. The ideas above may be perfectly adequate for some cases and completely useless for others.
It could be said that tabular data is boring; avoid at all costs! Fair point I’d say — thinking outside the box! Or table in this instance. But then sometimes you can’t escape semantics. Why not alternate content? Hide the table and present something else, like pie chart as Scott Jehl suggested in response to Chris Coyier’s experiment. A possibility, but if you’re going with a table in the first place it’s probably the only suitable format for that quantity of data.
I’m beginning to think that trying to perfectly resize a table within the visible viewport is not the best idea after all. Responsive web design does not make scrolling illegal! Could the solution lie in the realm of — gasp — horizontal scrolling?
More research and experimentation required, I’ll let you know my findings! Apologies if this post is a bit scatty. It’s gone midnight and if I don’t publish now I doubt I’ll find time until 2013!
6 Comments
Scott
I’ve been working responsive tables as well and I also went down the solution of hiding rows of the table and having a small screen only menu appear to switch between the rows that were hidden.
This solution could get rather bulky for tons of table rows, but it worked decently for my needs.
James Young
It’s interesting just how few efforts there have been to tackle this particular problem really and how far off they are from being a one solution fits (nearly) all cases fix!
Tabular data isn’t boring, it’s what it is and there’s definitely a need for it of course. Will keep you updated on my own progress anyway!
J.
M1ke
I certainly agree that more efforts need to be made to allow tables to be a bit more responsive; unfortunately there are a number of developers who, since the great table purge of the early 00s see tables as evil no matter what they’re used for. There’s also the issue that their structuring is still quite different from most other elements – if you take a out of a it still renders reasonably fine, but take a out of a table and its a lottery where it ends up.
However with applications and especially management tools using tables more often I think the issue needs to be tackled. I was impressed when the table turned into the form of a list for a narrow screen, though would this be as easy for a more complex table representing actual tabular data? I’ve written a few items, mostly using JavaScript, to shorten table items and reduce font sizes to keep tables to one line but it always seems problem specific and messy. I’ll have to blog a few examples of the problems I have to deal with, maybe if more developers shared the issues they were having with tables more people would see ways to solve them in a general sense.
Juan Carlos
What about info architecture? why dont prioritize what really matters in each table? what with the ability to switch those columns what the user is looking for? I mean… a table is a table… it’s not a piechart… its not a text description… its a table… I think we (UXs and UIs) need think a bit about how handle the tables, what about horizontal navigation? I think we need make them gracefully… not just replacing… everyone know replacing things is not a solution… we need re-think them… re-design them… innovate them… now is when…
Mark Myers
I feel like you could make a fairly elegant solution combining this with compass / sass where it could be easily repurposed to handle a number of use cases.
Awesome stuff. Thanks for sharing.
Ryan
I’m coming up on having to RD a calendar and this was pretty much what I had in mind, glad to see and play with it before I took my first swing lol
I thought a lot about the U part of things and I get the drift that a simple break from calendar to list is what the user would expect. Like, people on devices using applications have been doing it before sites started to get with responsive. Before that those applications they used pretty much defined their expectations.
Simplicity and familiarity tend to be well received and for calendars I think it’s kind of a bye in front-end UXIif no further complexities are involved like exposed filters. The layout of the calendar itself whether it’s list for small screens or calendars for screens that can accomodate it just has the most prudent balance to fit expectations.
The motivation of someone is relatively clear is to spot an event, you just don’t want to derail that kind of motivation with them seeing something new. Perhaps if you wanted a transition you could use some JS to replace the event divs with a number that takes them to a page of the days events. It’s something different, but it takes me another step, that step only gets in the way of better alternatives, I guess a pop up bubble would make more sense.
Actually, I like the bubble idea, then you could bring it to that spot on the list.
But for phone screen size I’d check to see if there’s a breaking point where the day cells are just to small to be easy to press, if you go from 14 to 21 than I would have just been better off with the list unless you were trying to sell me on the point that you have events nearly everyday of the month. That can be argued and tested either way, but when it comes to events, you want to make absolutely sure you’re not adding additional steps.
So I think focusing on clear styling is key and to roll with the layout side of things (though there is paging and of course exposed filters lol). I think more attention should go towards how you layout you event pages if you don’t have any other complexities, at least if it’s a calendar of your events. If it’s aggregation of a bunch of things going on around town then the extra cool factor of the interactivity/app-ish-ness of it is part of what your site special without really risking invested conversions.
What do you guys think?
Your Comment…