One of the most common questions I get asked during responsive design workshops is how to handle tables. I usually show some of the techniques and then tell people they should pick the right technique for the content in the table.
There are a series of questions that you can ask about the content in a table that will help you pick the right technique.
Do people use the tables to compare rows? Compare columns?
Example 1: People don’t compare rows or columns
Let’s assume for a moment that people don’t compare rows or columns. What would be an example of a table like that? How about a listing of top movies?
In this example from the jQuery Mobile library, we have a table containing the top movies ordered by rating.
On a wide screen, it is helpful to see the movies in a table because it makes it easy to scan each column. But it is unlikely that people are relying on the table to compare rows or columns.
There isn’t a tremendous value to be gained by comparing the director from row 1 (Orson Welles) to row 2 (Michael Curtiz). Similarly, comparing the ratings column to either of the columns next to it—year and reviews—doesn’t add much, if any, meaning to the table.
Because people do not compare rows or columns, this table is a good candidate for being transformed into a list on smaller screens:
Which is exactly what the jQuery Mobile developers do in their demo. Check it out.
Example 2: People compare rows or columns
If you have a table listing a bunch of stock and their prices, like the one below from Simon Elvery, then you will probably find that people are comparing one stock to another to see if they are investing in the right places.
In this case, we want a solution that allows people to continue to compare rows. In the example Simon provides which is based on work by David Bushell, the table flips so that the header row is a header column and the rows are now columns that are scrollable.
Again, this is something best seen in action by going to Simon’s Flip Scroll example. This is very similar to Zurb Foundation’s responsive tables solution.
Another way to handle this need to compare is to reduce the number of columns so that the table fits as demonstrated by the Filament Group.
They also used a stocks table as their example, but on narrow screens, they hide columns that are deemed less important.
If someone needs to see a column that has been removed, they can use the pull down menu to add it into the table.
Check out the Filament Group demo and a similar demo from the jQuery Mobile showcase.
What information is essential?
If you find yourself in a situation where you want to show fewer columns on small screens, then you have to start asking yourself what information is essential. It is helpful to ask yourself these questions.
What information do people care about the most?
- Which columns are most critical to understanding what the meaning of the table is?
- Which columns are people most likely to care about?
What is necessary to be able to differentiate one piece of information from another?
If you’re looking at row after row of information, what information would allow a person to quickly distinguish between two rows? This is particularly important in scenarios where the rows are used in applications interfaces.
Say you have a table that shows information about users. Administrators can select a user and then edit that user’s account.
On wide screens, you would might include things like the user’s roles, last time they logged in, etc. But on small screens, you simply need to make sure that you’ve provided the critical information that an admin needs to be confident that they are selecting the right user.
Is it necessary for everything to be on the same screen or can you conditionally load additional detail as needed?
A lot of the more complex responsive tables implementations I’ve seen have come in situations where the developer was trying to fit every piece of content that was available on wide screens onto small screens.
In some of the more extreme examples I’ve seen, this has caused huge performance and layout problems as tables with hundreds of rows and dozens of columns were combined with fixed header rows and columns and squeezed onto a small screen.
I think the mistake a lot of people make is believing that responsive design means that they have to everything in the same document regardless of screen size.
If you were to start a mobile first design of a stock table, you might say that on small screens, you are going to show the following columns:
- Company name
- Ticker symbol
- Percent change
If the user wants more data, they select a stock to go to a detail page and view more information about the stock.
Then as the screen got bigger, you might show more columns. You might even decide that on wider screens that you will make AJAX calls to retrieve the data from the detail page you built for small screens.
This all makes sense. You’re using progressive enhancement based on screen size. No big deal.
There is a funny thing that happens when you flip it around—when you start from existing big table of data that was designed for wide screens. People no longer allow themselves the option to not have everything on the same screen.
I’ve observed on more than one occasion that designers and developers no longer feel like it is acceptable to not show all the columns or to have people go to a detail page to see more information on small screens. That doing so is not responsive design and is cheating in some way.
I think it is a mental trick that we play on ourselves depending on our starting point. If we start mobile first, we never doubt it. If we start from an existing desktop table, we unconsciously limit our options.
Here’s what matters when it comes to tables in responsive design:
- Do people understand the meaning of the table in all contexts?
- Can people get to all of the information somehow?
- Have you made sure that every URL is accessible regardless of device?
If you can answer yes to all three, then you’ve done your job.
Your content will dictate the best responsive table solution
There are a lot of different ways to handle tables in responsive designs. And I expect that we will see more alternatives and techniques as time passes.
But regardless of how many responsive tables solutions we have to choose from in the future, the way to select the right one for your project will remain the same.
Your content will dictate the best responsive table solution. You just have to ask the right questions of it.
Responsive table resources
The following is a non-comprehensive list of potential responsive tables solutions. I use them primarily as inspiration and design patterns.
A few years ago I wrote an article entitled CSS Media Query for Mobile is Fool’s Gold. It garnered a lot of attention at the time, and I still see people reference it.
I’ve long wanted to write an update to that article, but never knew quite what to say until now. And because one inflammatory title deserves another, read on for why Responsive Web Design is Solid Gold.
Our default approach is now responsive web design
Back in 2010 when I wrote the Fool’s Gold article, our default approach for mobile was to use device detection. If a site was simple and the budget small, we might use responsive web design.
Some time ago our default approach switched. We now treat responsive web design as the default approach and look out for reasons why it won’t work instead of the other way around.
Why did our default approach change? Two reasons: performance and device diversity.
Update on performance
Much of my Fool’s Gold article focuses on performance problems with flexible images and CSS background images. One of the reasons why I’ve had trouble figuring out how to write a follow up is because the performance issues that I raised remain true today.
Let’s do a quick round up of the issues and updates on each:
Perhaps most importantly, most responsive web sites are still far too large on small screens.
So if most of these remain true and most responsive designs are bloated, why has my perspective changed?
Because it is possible to build responsive design responsibly and create fast experiences. The keys to doing so are:
- Build mobile first responsive designs
- Keep CSS background images in scoped media queries
- Implement a responsive images solution
- Handle retina images very carefully and err on the side of performance
If you do these things and do the normal things you should do to make any web page fast, you will have a fast responsive design. It may not be easy, but it is possible.
But what about the fact that most responsive designs are bloated? As Tim Kadlec says, “blame the implementation, not the technique“.
I don’t blame device detection for the many sites that route people to the mobile home page instead of the article they’re looking for. And I don’t blame responsive web design for the fact that most implementations are bloated.
Can a responsive design ever be as fast as a page tailored for a specific device?
Probably not. But the web is a balancing act between many competing interests. A site that was completely tailored for search engine optimization would be unreadable by humans.
By the same token, performance is an extremely important factor, but is still just one of many factors that make a site successful. You can build responsive designs that are fast enough that the benefits of responsive design outweigh the potential performance improvements you might get from separate sites.
Especially when you consider device diversity.
Device diversity makes responsive design inevitable
Let’s assume for a moment that responsive design doesn’t work for your project. So you decide that you’re going to need to build mobile, tablet and desktop experiences. And let’s set aside for the moment the inevitability of new form factors like televisions, watches, etc.
Even in this scenario with different experiences for each of the three major form factors, you’re still going to end up needing responsive design—or at least responsive characteristics.
Yesterday, Samsung announced that it was launching a 6.3 inch phone. The range of screen sizes on mobile phones alone will likely force you to build something that will adjust from the small screen sizes of Blackberry Bolds and feature phones to the mammoth screens of some Samsung devices.
Tablets present a similar challenge ranging from 7 to 13 inch displays (and sometimes much bigger). And we’re all familiar with the large difference between ultrabook screens and cinema displays.
I wrote in much more detail about the impact of device diversity earlier this year and my conclusion that:
Any attempt to draw a line around a particular device class has as much permanence as a literal line in the sand. Pause for a moment and the line blurs. Look away and it will be gone.
So regardless of what techniques you use in addition to it, responsive web design will likely be part of your solution.
What about mobile context?
One of the other points I made in the Fool’s Gold article was related to mobile context. It is something I’ve struggled with for years.
I’m now firmly on the side that there is no mobile context. We have abundant data that shows that people use their mobile devices indoors and for a wide variety of things.
Luke captured it well when he wrote:
But if there’s one thing I’ve learned in observing people on their mobile devices, it’s that they’ll do anything on mobile if they have the need. Write long emails? Check. Manage complex sets of information? Check. And the list goes on. If people want to do it, they’ll do it on mobile -especially when it’s their only or most convenient option.
So Jeremy Keith and Stephen Hay were right. There is no mobile web. Mea culpa.
Still No Silver Bullets
I concluded my Fool’s Gold article by stating the obvious: there are no silver bullets when it comes to adapting our existing apps and sites for mobile screens. At that point in time, people were touting media queries as a quick fix for mobile.
Since then, our profession has learned a lot more about the complexity of designing and building experiences for multiple devices. Now it is generally understood that supporting all the devices that may access our content and services isn’t easy, but that tackling problems that range from responsive images to legacy content management systems are the heavy-lifting that we must do in order to be future friendly.
And despite those challenges, I’m excited about where the web is heading and what we can do with progressive enhancement and responsive web design.
Responsive web design: it’s solid gold, baby. :-)
When I wrote Common Patterns in Styleguides, Boilerplates and Pattern Libraries back in May, I honestly didn’t know if anyone would find something as pedestrian as a spreadsheet that interesting. It was great to discover I’d at least partially solved a problem for a lot of people. But I was surprised to hear from a handful of designers and developers who interpreted it as a score card… the more patterns a library contained, the better.
Yikes! Totally not my intention.
Here’s the thing: These frameworks are terrific resources. I think it’s really helpful to see how other teams craft (and document) scalable and modular interface elements. They are excellent points of reference.
But I tend not to use them for more than that. For two big reasons.
It’s a rare project that launches with less complexity than anticipated. So why front-load your project with the totality of another team’s interface needs?
.net magazine recently published an interview with six RWD experts. Here’s a gem of a quote from Tim Kadlec:
I think that our industry in general has it a little backwards: instead of the default being a framework or all these other little plugins and polyfills, the default should be just simple HTML and CSS. Then, as the project needs, you can start including things. But everything you add to a page or project adds something — be that weight, maintenance or complexity — and therefore everything needs to be justified before it gets thrown into play. Start light and vanilla and only add things in if they’re necessary.
And from Aaron Gustafson:
Opaque design thinking
Many of these frameworks are incredibly well-designed and executed. But how, and why? Why that corner radius? Why that font size? Why three button sizes… why not four, or five? How can we competently extend this design thinking without knowledge of its history or principles?
Trek Glowacki wrote a wonderful gist that describes this problem in detail:
Every design is like a little language with its own correct grammar and syntax nearly as specific as a programming language. It contains primitives but instead of concepts like maps, arrays, integers, and functions the primitives include size, weight, color, proportion, and texture.
Without first understanding that language it’s impossible to correctly express anything new. And that’s where the problems start for most people using these libraries. If they stay safely within the provided components they can make an application that looks designed (because it is) but no UI kit provides every possible component or even has guidance about all the ways existing components can be combined.
So why care about common patterns at all?
Our own responsive deliverables benefit from seeing what patterns emerge from those who’ve solved similar problems before. We can learn from their techniques while crafting new ones.
In the immortal words of Emil Faber, “Knowledge is Good.”
Sliding views (incoming views that “push” old ones off-screen) have become so commonplace in mobile design we tend to take them for granted. They’re useful because they allow content to be broken into bite-sized chunks while maintaining hierarchy through the use of spacial animation. They look pretty neat, too.
So we made SimpleSlideView, a plugin for jQuery or Zepto.
Check out the basic demo to see it in action. There’s also a responsive demo to show off how the plugin can activate or deactivate for different layouts.
What makes SimpleSlideView special? Since you asked…
You need a containing element and a way to select the views within it (a class of “view,” for example). That’s about it.
Views can be “pushed” (the new view “pushes” the old one from the right) or “popped” (the opposite). That’s it. No complex multi-step animations. No built-in history tracking.
popView methods to control navigation, or you can add some magical HTML5 data attributes (
data-popview) to links or anything else.
Plenty of frameworks do more. This one does push and pull.
Responsive by Design
Sliding views don’t always make sense when your viewport’s rather spacious. SimpleSlideView was developed for responsive layouts, and it handles them like a pro.
The plugin activates by default, but you can override that with the
deferOn setting. You can turn it on or off any time you’d like with the (creatively named)
It even has some nifty events you can use to activate or deactivate alternative functionality. See the responsive demo for an example.
Give It a Whirl
The plugin, source and documentation are available on GitHub… also an excellent place to report issues or contribute improvements. Let us know how you like it!
There are things that we put on web sites that we know annoy users. We know they annoy users because they annoy us as well.
But it can be hard to convince your boss or your stakeholders that they shouldn’t do something that is annoying when so many other sites are doing it.
That’s why it is so encouraging when Google decides to penalize sites that utilize these practices. Now you can say to your stakeholders:
So you want to add a full screen ad to encourage people to download your app before they can read your content?
Go ahead and do it if you want to decrease your search rankings.
Oh and by the way, people really hate these download my app pages.
So you’re going to redirect mobile users to your mobile home page?
Ok, but you’re going to piss people off, and it is going to affect your search engine rankings.
And really, URLs should just work no matter what device someone happens to be using at the time.
Oh hey, you’ve got a mobile design, but it is still downloading all of the desktop assets?
Well, now not only will people never see your wonderful design because it will take too long to load, but you’ll also be penalized by the search engines for serving such a slow site.
As I’ve said before, the first thing you should do to optimize your desktop site for mobile, is make it fast no matter how it looks on a phone.
In general, I think people spend too much time focusing on search engine optimization hacks and not enough time on writing and producing compelling content or products. But in this case, Google is changing their algorithms that penalize bad practices and create more better sites for users and we’d be foolish not to use this to try to win arguments.
So the next time you’re in a debate with someone who wants to put a big ad on every page to get people to download their app, appeal to their humanity. Remind them that they are hurting people.
And if that doesn’t persuade them, appeal to their wallet. Tell them that they will be shooting themselves in the foot when it comes to search engine rankings.