Is responsive content easy?

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:

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, 

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.