Responsive Design Won’t Fix Your Content Problem

by Karen McGrane

43 Reader Comments

Back to the Column
  1. Nice article, some interesting points. I do however think you can you serve up less content to mobile devices. Some content is superfluous or just there to reiterate. I think this can be stripped when used on smaller devices like a mobile. However I quite like the use of ‘Read more’ to reveal more text if the user wants it.  Easily achieved with Jquery show/hide.

    Copy & paste the code below to embed this comment.
  2. Great article. I feel the same as you, people doesn’t seem to understand what’s the real deal about mobile web and RWD. Content is the more important element in a website.  Content strategy is the key to a good designed RWD page. Well thought decisions about content will allow a good design.

    Copy & paste the code below to embed this comment.
  3. You have articulated this so well and it needed to be said. Content quality isn’t a fixed value and it needs to respond to the changes in what your audience needs in the same way your design should respond to changing viewports.

    Copy & paste the code below to embed this comment.
  4. This article makes a good case, even just for images you need different crops.

    Copy & paste the code below to embed this comment.
  5. I appreciate this article, thanks. At work, I’ve been spending a lot of time talking about content strategies and governance for the publishing of content on our CMS. It’s a university website, therefore the Information Architecture can be a challenge.

    RWD shouldn’t just be thought of as a complete solution , there are many more issues to address – content being the most important. The future will be disruptive and standards will break, it will take time to normalize them.

    When the content problem is properly addressed and coupled with RWD then perhaps a better, new standard can be sought out. I’m a bit of an infovore, so thanks for the lovely links :) Food for thought!

    Copy & paste the code below to embed this comment.
  6. Thank you, Karen. You are right: Responsive is providing an open window for getting content and strategy in order. And a big thumbs-up to long-term maintenance plans. There is nothing worse than making poor content “responsive” and walking away.

    Copy & paste the code below to embed this comment.
  7. Loved that last paragraph. Responsive design goes a long way to showing flaws in strategies at a departmental level and should push your team to correct those strategic failings and push on and the move the needle much further to the right instead of revisiting the same issues over and over again every time a new project comes up.

    Great food for thought. Thanks for this post.

    Copy & paste the code below to embed this comment.
  8. @Steve, since there are many, many people who use their smartphone as the only device to use the internet (according to Pew research), a content editor cannot decide for those people what they need to see or what not.

    If for what kind of reason information can be removed, than it should also be removed from the desktop version. Why keep it there in the first place. It’s like having an attic filled up with junk, and moved again and again when you change locations.

    Copy & paste the code below to embed this comment.
  9. @Steve Baker: I would encourage being very, very careful and precise when saying you think it’s okay to serve less content to mobile devices. What does that mean? Serving only a subset of the content? If you guess which subset a “mobile” user will want, you’re going to guess wrong. Mobile users deserve all the same information and content that desktop users get. Do you mean that some of the content doesn’t add value and can be suppressed on mobile? In most cases, if it doesn’t seem worth it to have the content on mobile, it shouldn’t be on the desktop either. I can think of a few specific scenarios—say, suppressing “decorative” images on mobile that might still appear on the desktop—where you might argue for serving less content. But even in those scenarios, the real answer is to treat the problem like a content strategy problem, and ask whether or not the content is providing value.

    Copy & paste the code below to embed this comment.
  10. Reading your article after coming home from a meeting with an e-commerce client. They “don’t have time” to develop new, quality articles because they’re understaffed even for order fulfillment, yet in the same day insistent about the next email blast. “But you don’t have anything new to say!”, I want to scream.

    Copy & paste the code below to embed this comment.
  11. Wow! It’s like you took the words out of my head Karen. Great read, we are facing a huge problem trying to educate clients on a whole new way of doing things, I’m finding the industry is having a tough time transitioning to a content first way of thinking.

    Copy & paste the code below to embed this comment.
  12. Karen thanks for reminding everyone of what they have been told for years. content is king! Maybe one day it will sink in.  In the meanwhile I am happy to write content for my clients. It removes the frustration of waiting for them to do it and provides a great revenue stream :)

    I understand what Steve Barker is saying and also have a number of clients who have adopted a hybrid solution

    Copy & paste the code below to embed this comment.
  13. I recently had a project manager asking me to build a new site an upcoming event. Sure, where’s the content? “We’ll figure it out later”. Okay… Maybe I pushed too hard asking for that one… “Can I have at least some sort of structure”? “Yeah, that will come too”. And now I’m scared… “We gotta have content, we gotta have structure, I need grow the site from inside out, content is king!…” and so on. And this was the answer I got: “why are you being so difficult?! We’ll use a CMS, we’ll add content later, that’s what they are for! Just pick a template!, Put something up already! You have two days!”. Well, but of course. Actually, I can have it after lunch: “Great!” “Oh, and make it responsive.”

    Copy & paste the code below to embed this comment.
  14. Are there any broad guidelines for adapting old content that I can use an low-level staffer to plow through? For example, inserting a break for “read more…” or putting all in line images in the HTML into a distinct container

    Copy & paste the code below to embed this comment.
  15. Great post Karen!  RWD is not a magic wand.  Don’t forget you also cant just add a bunch of CSS and push image processing to the client side.  You can’t take an already large page size, add more CSS, make it bigger and call it responsive.  You have to look at the content, look at server side tools, and balance design and function and serve a page that a user will not have to wait for.  You have to watch page load times, hiding a large image on a mobile device does not prevent it from downloading the image.

    Copy & paste the code below to embed this comment.
  16. Great piece! We’re planning our next meeting with the bosses along these lines. Question, though.

    “…content teams must also evolve away from reliance on Excel spreadsheets and Word documents to manage this process.”

    What do you have in mind for this evolution?

    Copy & paste the code below to embed this comment.
  17. I second scottbynum. How should we evolve away from reliance on spreadsheets and word documents? As a manager, I find such documents incredibly useful for workflows because it helps stakeholders gather up all their content (images in multiple sizes, links to videos and so forth) and get their ducks in a row before the migration takes place.

    Copy & paste the code below to embed this comment.
  18. Thank You !  I feel just a little less alone in the universe now.  It gets so tiring dealing with clients who know what they want their site to look like but don’t know what they want to say

    Copy & paste the code below to embed this comment.
  19. scottbynum PJMorse It depends on the scale of the project. I have worked with some editorial teams dealing with thousands or tens of thousands of pages that need to be reviewed, edited, combined, or deleted. A spreadsheet is one useful tool (love me some spreadsheets) but it’s rarely the best tool for managing the entire editorial process, especially if you have a team of internal people and freelancers working on it, and if content needs to go through a couple rounds of revision and approval. I have been moving teams toward managing the entire process in the CMS, even if it’s a lightweight version of a CMS designed only to support the rewrite and migration process. Tools like Gather Content (https://www.gathercontent.com/) are other alternatives to using Word docs, and they make the migration process easier through an API.

    Copy & paste the code below to embed this comment.
  20. Thank you for the link to Gather Content. That does look mighty tempting, and it would achieve the same goal as a spreadsheet, which is to help other team members a) track the content and b) realize how much content goes into a site that they aren’t aware of.

    Copy & paste the code below to embed this comment.
  21. Well said Karen! I’ve have experienced this situation. Sometimes the client just doesn’t have enough resources/manpower to do “all that content strategy” & some think “oh yeah the web guy is taking care of that”. Just as you opened this article outlining challenges of going responsive, it’s our job as #WebDesigners, #DigitalMarketingManagers, #WebDevelopers, #WebConsultants, etc. to educate the client up front about what you will be doing for them (building a #ResponsiveWebsite ) & what they will be doing for themselves (managing the content) to avoid common pitfalls.

    Copy & paste the code below to embed this comment.
  22. Karen, good stuff, as per usual.

    The NBT in the WordPress universe looks likely to be “front-end editing” – that is, the ability to create and edit content in situ.

    This strikes me as potentially being an even bigger distraction for quality content creation than RWD

    If content is being created within the context of the, presumably, desktop website then surely it can’t help but fail to be appropriate for other devices?

    So, just when you think you’ve successfully tackled one hurdle, another looms large on the horizon.

    Copy & paste the code below to embed this comment.
  23. Hi Karen
    Great article, thanks. You mentioned Gather Content (https://www.gathercontent.com/) in one of the posts; I’ve had a look and it seems great but doesn’t appear to manage track changes well. We are about to embark on a major transformation project and something like this which also has tracks changes functionality similar to Word would be great, without it it’s too hard to assess reviewer’s changes. Do you know of any products that can do this?

    Copy & paste the code below to embed this comment.
  24. @chris knowles: I talk a lot about the risks of inline editing and WYSIWYG in the context of the desktop interface. See my Drupalcon keynote and transcript for more of my ranting on this subject: http://karenmcgrane.com/2013/05/23/drupalcon-keynote-video-and-talk-notes/

    Copy & paste the code below to embed this comment.
  25. @jo williams: Yes, track changes. I have worked on a couple of projects where the team uses a very lightweight Drupal install to manage this process. Track changes doesn’t work exactly the same way it does in Word, but version control is built in, and Drupal Views can easily spin off some admin interfaces to help manage the process. If nothing else, I would encourage people to use an editor like Google Docs or Editorially rather than Word, as the markup is cleaner and an API will make migration easier.

    Copy & paste the code below to embed this comment.
  26. I get confused with:

    “-Assessing the amount of content that can appear on a “page” on different devices, and striking a balance for different form factors
    -Creating multiple forms of headlines, teasers, or body text, so valuable information doesn’t get truncated randomly “

    and

    “Mobile users deserve all the same information and content that desktop users get. “

    If we’re not serving different content to mobile and desktop, and I agree we shouldn’t, what does striking a balance for different form factors mean? Things like collapsing accordion navigation in mobile but not in desktop?

    Copy & paste the code below to embed this comment.
  27. @lois nilsen: As a general rule, it’s best to serve the same content to all devices whenever possible. However, that doesn’t mean you can just take a “page” from the desktop and make it one long scroll on mobile. Striking the right balance for both may mean you do something different with the density of content and the architecture from what you would do if you were considering only the desktop or only smartphone form factors in making your decision. I use the example of a page from Amazon to explain this—what makes a good “page” on the desktop wouldn’t be the same as a good “page” for a responsive implementation of the same information.

    Serving the same content to all platforms doesn’t always mean serving exactly identical information. I use the example of image crops to make this point. Publishers cut a handful of different crop sizes for use in different contexts. They are the “same image” but are not “identical images.” If that makes sense, then you can wrap your head around the idea that you might cut different sizes of headlines or teasers for different form factors—same information, just different lengths. Slate has increased Twitter clickthrough 100% by cutting an alternate version of their headlines. Those shorter headlines might also work better on mobile than, say, the truncated headlines used by the Guardian.

    Copy & paste the code below to embed this comment.
  28. “Pretending you don’t have to solve these problems just makes the job harder.” Love it. Thanks, Karen, for keeping common sense in the conversation.

    Copy & paste the code below to embed this comment.
  29. Karen, thanks for this great piece. It also reminded me I still need to read your book. Here is my 2 cents.

    If a site is going to have consistently changing content, the content needs better management. Everything I have read in this post rings true. Better management of content is needed. GatherContent looks like a great start. API and markdown support will make it better.  I like the idea of using markdown tools like Draft – https://draftin.com/  or Editorially – https://editorially.com/ (I wrote these comments using Draft) but doing that seems like a band aid to me.

    Having worked on a project where there was much magazine article type content, I found the traditional CMS to be a failure. All the content was forced into the CMS and its templates. A true redesign will break the content and require it to be re-entered. Some of the issues I saw were like Karen explained: “Separating content from presentation in the CMS, so content and markup aren’t all dumped into the same blob of a field”—The one blob approach just seems dumb to me. I do not know what the solution is to solve all this. The good news is people are discussing these issues and trying to solve them. I think the use of markdown will help but it alone will not solve the issues. Content is not a blob. It is made up of many pieces that are both visible and invisible to the content consumer. Our content also has to speak to the search engine bots that index our content. There is a lot of work on the road ahead.

    Copy & paste the code below to embed this comment.
  30. I don’t understand why a responsive website project would specifically be a good time for content strategy. It seems that any time a major project is being undertaken there is an opportunity to tackle the larger content issue. I assume that is what you are saying and since clients confuse responsive for content strategy (probably due the phrase “mobile first”), it simply makes it an almost necessary and natural time to sell content strategy.
    Good article. Thanks for sharing your thoughts on this topic.

    Copy & paste the code below to embed this comment.
  31. Thanks for a great read with lots of snickers at familiar scenarios.  If I had a nickle for every time and so on…

    Atm we’re rebuilding all our 10 news sites on our own framework and they’re all responsive. I’ve been part of a lot of site redesigns that consisted of putting makeup on a pig and I’m happy that this time around we’ve also redesigned the workflow!

    Reading your post reminded me of a discussion the other day when someone asked how to preview the site on three different screen sizes. Our answer was that you should spend less time checking that your headline is pixel-perfect and more time on writing a great story. Another reporter had a less smirk remark though and suggested that you could check Analytics to see which device is hottest at the moment and only check that screen size since that is where the majority of the audience is. Makes sense.

    Copy & paste the code below to embed this comment.
  32. Tempted to quote from “Throw Momma from the Train”, but the essence will always be content. So, if the content works, this becomes a(n) (RD) presentation issue (as in re-presenting), no? Otherwise the content needed revising anyway. I find the parallel to film production striking: bad scripts always yield bad movies, no matter who directs. The definition of content strategy becomes paramount – and a very personal (organizational) matter. Change is always explicit in improvement, implicit in all other permutations. Karen’s article and the accompanying comments have provided me with a new way of thinking about…everything.

    Copy & paste the code below to embed this comment.
  33. I design the core mobile apps for Engadget and TechCrunch. At the inception of smartphones, people were just grateful you had an app or a mobile website. But, familiarity breeds contempt. (Maybe be my choice of words is makes this sound too severe.)  -  These days our readers are very tech savvy and very vocal, and they want everything on the desktop to exist on the mobile experience, even if it is optimized or in a slightly form factor. As long as it’s there.

    This is difficult if you consider the backlog of content that exists that is not mobile friendly, videos, galleries, certain audio components etc. But we’ve always designed/developed with the understanding that we’d simplify but allow for back-end complexity. And all of this hinges on the editors, writers, contributors and even interns publishing their new content within mobile friendly guidelines on a day to day basis.

    With a responsive site, they can no longer assume just because it works in the emulator or snaps to a new configuration at the predetermined break points, it will work on the actual device. We tell folks to test it on their phones/tablets – if it’s not working on your end, it won’t work on our end either.

    Copy & paste the code below to embed this comment.
  34. I still believe there is some content that simply is not appropriate for little screens like phones. A case in point: a page that (on a desktop) consists mainly of a single table of data that fills the 900px width of the content area, with text size set at 10px. This is a table that holds more information than can be seen on one page, but with the use of jQuery, users can flick quickly through pages of the table, set the number of rows to show etc. (some of you may have come across this jQuery – pager plugin), but my point is, there is no real way to represent this content heavy table with many rows and columns on a phone screen. You can just get away with it on a tablet, but if phone browsers want to use this table, they really are going to have to view it on a desktop or something big enough to be able to read it.
    This, I believe, is a case for omitting content for phones. When the whole point of the page is this interactive table, and there is no practical way to display it or use it on a phone, you really have to leave it out.
    And before anyone says “then why not leave it out of the desktop version too”, the whole point of the page is this interactive table and it gets heavy use. It would be madness to get rid of it, just because you can’t use it on a phone.
    I definitely get the ideas put forward in the article and agree with most of them, I am just saying, there is always the exceptions that need to be taken into account, and I believe we can go too far in pandering to phone users.

    Copy & paste the code below to embed this comment.
  35. True, and likewise a responsive design is pretty pointless if the content on your website is completely awful. I’ve seen plenty of amazingly designed websites that have broken pages, thin content and blogs that haven’t been updated for years. If anything I’d suggest getting the base content right before you do a responsive design. At least then when you relaunch you’ll have something for people to look at.

    Copy & paste the code below to embed this comment.
  36. There is no compromise for ‘mobile content’, and it appears the burden is on frontenders. That example above about the table: mobile being what it is and tables what they are, a genuinely mobile user’s likely not fully engaging in such an expansive interactive UX ; more likely they’re querying aspects of that data while on the move. Yet responsibly, all table data must still be made available (timetables, e.g.). So again the content itself need not change, but rather how it’s presented in the UX. We all want/expect uniform content; but “…when I’m mobile I only want the mobile version [of that content] and I want the machine to know the difference” (actual client statement). As said by others earlier, this can be achieved via strategic breakpoints & clever code, and of course I agree, but…the wisdom in developing frontend solutions for problems that are perceived by some as backend…perhaps those lines are beginning to blur?

    Copy & paste the code below to embed this comment.
  37. @alan netherclift: No user ever has a goal to “look at a table”. Users want to do things like “compare two products” or “figure out which size will fit me”.  The “whole point of the page” is never an interactive table. It is always what the user came to accomplish.

    That is why I argue so strongly for separation of content from presentation. The best way to present a product comparison or a sizing chart on the desktop might very well be a table. But that’s not the only way to present that information. Perhaps on smaller screen sizes we need to offer a different option.

    But to say that mobile users shouldn’t get access to valuable information simply because the best way to present that content on a larger screen is a table is a total cop-out. We’re better than that. Separate the content from its form, and use the right presentation for the right context.

    Copy & paste the code below to embed this comment.
  38. Hey Karen! We loved your article and included in this Month’s Resource Roundup http://www.wiredtree.com/blog/novembers-best-web-designdevelopment-cms-security-content/

    Copy & paste the code below to embed this comment.
  39. This article made my stomach collapse in a most unplesant way.  Not because it’s not good or truthful, but because I have a draft with a very similar name and very similar subject in my outbox and you beat me to the punch. I will debate whether to bother, but I’m glad at least the message is out there.

    Copy & paste the code below to embed this comment.
  40. “Design deliverables like wireframes and comps are evolving—content teams must also evolve away from reliance on Excel spreadsheets and Word documents to manage this process.”

    I’m working on an academic blog about sponsorship and our collaborators are very conservative in their workflows. Draft, review, V2, V3, V4… etc. Moving away from this is painful but necessary. After reading that part I felt a bit bad about using Excel and Word to manage content.

    I started using DraftIn (thanks to David!) and so for it’s working well.

    Responsive didn’t fix our content problem. Hopefully, a good strategy + agile workflow will.

    Copy & paste the code below to embed this comment.
  41. Great article, Karen, and you can see the effects of the “content second” mentality all over the sites we evaluate over here at siteIQ.

    Fact is: classic “inside out” marketing content can’t be shoehorned into new responsive designs. It just makes the site look clueless.

    In our client group, the sites that have made the transition successfully started by creating a small editorial team dedicated to rewriting the content for the site. Then they created standards and trained the marketing stakeholders.

    Copy & paste the code below to embed this comment.
  42. Ah..Haaa… No wonder Apple.com website is not RWD.

    Copy & paste the code below to embed this comment.
  43. A good read. A responsive web design has to go hand in hand with content optimization. Brands can use this as an opportunity to streamline content production too. Got some good points out of this post.

    Copy & paste the code below to embed this comment.