One of the huge draw cards for responsive design is the ability to write once and publish any/every where. And why shouldn’t that be a massive draw card? The ability to write content that can be used on any device in the present or future means that the words that I’m writing right now will forever be etched into the internet archives (or at least as long as my server remains up).
When you actually look to put that into practice you will find that this statement is very much like Communism, great on paper but when it comes to practice there’s a few flaws.
But with a responsive layout your content adapts to the device
Yes, yes you have me there. With a responsive fluid grid the text within the container will become shorter as the view port decreases and inversely become larger as it increases.
If you really want to impress then you might even add a few additional breakpoints to your style sheets that change the font-size and line-height depending on the width of the text.
You would also be right if you were thinking about some jQuery solutions like FitText.js and SlabText.js that recalculate the best size for the text as you resize the browser, although points off if you’re using these tools for your body copy instead of just the headlines.
If fact there are some great articles about the responsive nature of text and how you can ensure it remains in it’s most readable layout as the view port chagnes, such and such was even nice enough to create a tool to help us along.
So then what’s your point, seriously?!?
These are great techniques when it comes to plain text. They’re great for stories, articles, blogs etc, but what happens when the content takes on a different form.
Tables for instance are really difficult to deal with. For me there are a few key issues to look at:
- The content is of a technical nature, and needs to remain in a structure to preserve understanding.
- The content waffles for the purpose of filling a design.
We will take a look at the second issue first (who’s on third?).
I’ve spent a lot of time with clients that are beat their copywriters over the head because the product page must be 200 words or the the image gallery slips up next to the image of the product.
Why explain something in 200 words when you can do it in 20?
The issue here is that the design is done in isolation of the content. Had the designer had access to the website content at the beginning of the project they could have come up with a better design that accommodated both the 20 and 200 word descriptions. Alright sure, you could come up with some minimum and maximum rules around the content but it shouldn’t be the design that drives those decisions, it should be purpose of the content.
If you get a request for a mobile specific website because the client wants a cut down version of the content that only provides what the user needs it means that the website content is full of waffle.
Now lets get back to 3rd base. Or was it first.
Technical information are bits of content too, just arranged in a more rigid way.
You can’t create fluid tabular data. Correction. You can’t create fluid tabular data that is still easy to understand.
There are a few solutions to responsive tables,
- Responsive Tables
Things like pricing tables, technical product specifications, responsive resumes, event line ups are all examples of content that needs to have a little bit more time spent on it than you would usually take.
There isn’t one. Well at least not yet, but there is a path towards a solution. Rather than litter our webpages with numerous non-semantic mark up to allow us more visual control over the design, we should be looking at providing more metadata around what the context of the content really is. If we want to start preaching responsive design for all content everywhere, then we need to start marking up the content so that it be used everywhere. With the step towards a responsive site you should be educating your authors to include WAI-ARIA or data attributes to the content to make it more machine readable.
Google has said that REsponsive Design is a preferred option when it comes to SEO. You know what else is preferred, content that Google can understand the context of.
So the Content <em>is</em> really hard in responsive design
Thankfully it is not. You can still provide the same content that you already have for the responsive design and the world will not end, however if you take a few moments to step back and consider all of the content that you have on the site then you will have a much easier job when it comes to developing your responsive website.