I spoke to a digital team at a large corporation a while back, and outlined some of the many challenges they were likely to face in creating, revising, and publishing their content so it would work well on smartphone, tablet, and desktop interfaces.
These included:
- Evaluating whether content is useful, valuable, actually worthy of being on mobile (or the desktop, for that matter)
- 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
- Planning to develop alternate versions of some assets—such as different image sizes and crops, alternatives to large infographics or tables, new demo videos showing both desktop and mobile versions of the interface
- Separating content from presentation in the CMS, so content and markup aren’t all dumped into the same blob of a field
An attendee raised her hand and said “I’ve been wondering when you would mention responsive web design. We’re going to use responsive design.” I responded “Well, responsive design won’t fix your content problem.”
Who thinks that, anyway?#section2
I recently posted a link to an article that called responsive design a “poor man’s content strategy.” Then my Twitter feed exploded with people heavily sighing and rolling their eyes, insisting no one would ever conflate the two. Why, everyone knows that the container and what you put in the container aren’t the same thing. Everyone knows that just rearranging modules from the desktop to make them squishy is not a content strategy for mobile. Everyone knows if organizations discover problems that go beyond the specific layout solutions offered by responsive design, that’s not the fault of the technique.
Except not everyone knows that. These are just a few of the anecdotes I’ve heard recently from people working on mobile websites for major corporations—projects with large budgets, committed teams, and executive buy-in:
- We recently finished a massive CMS replatforming which necessitated a redesign of the desktop website. There is zero enthusiasm for going back through the content structuring, editing, and approval process with our business stakeholders and our legal review team. Whatever we wind up doing on mobile, we must use the exact same content we have on our brand-new desktop site.
- We just spent [insert unfathomably large number here] trying to take our existing desktop website and make it responsive. We genuinely believed this process would be faster and easier if we based it on what we already have. It’s not going well, and we’ll probably need to throw it all out and start over. We would have been better off if we’d started from scratch six months ago.
- I was hired as a developer to build a new responsive website, but I’m being asked to make all kinds of decisions about how to edit and restructure the content—decisions I don’t feel entirely qualified to make. I keep telling my client they need to bring someone in to deal with the content questions, but they think responsive design is just a front-end design and development problem.
- Our executives assume that since they made the decision to go responsive, every other decision would just be tactical details. In fact, implementing responsive web design raises issues that strike right at the heart of our business and the way we work. We need to fix our review and approval processes, our content management system, our asset management system, our design standards and governance. We need to clean up our outdated, useless content. But it’s hard to get people to step up to solve these bigger problems, because they don’t think they’re part of “responsive design.”
Seems like a lot of people are laboring under the mistaken impression that using responsive design means they can make a mobile website without dealing with their content problem.
Where’d they get that dumb idea?#section3
We told them so. And, okay, yes, they’re using some magical thinking. But straight up, we told them that the mobile website should be the same as the desktop, and that’s why they should use responsive web design. We sold them on the value of responsive design by promising that they could manage and maintain one set of content and it would work across all devices.
We also insisted there’s no good reason to serve different content by platform. We got twitchy whenever anyone started talking about sending different content or less content to mobile devices (rightly so). We pointed out that you can’t discern user context or intent just from knowing screen size or device type. We told them content parity was the first and most important goal when developing a responsive website.
Is it any wonder they assume (hope?) they can just take what they already have, wave a responsive magic wand over it, and have their existing content automagically work on mobile? Why should it be different? We said it shouldn’t be.
Even companies that want to take a “mobile first” approach can’t just throw off the shackles of their desktop content. For some, suggesting the organization “start fresh” with new content would be organizational suicide, touching the political third rail of stakeholders and competing interests. Others acknowledge it’s time for a new approach, but need processes that will enable them to clean up and restructure existing content to make it appropriate for a responsive design. Responsive design won’t fix their content problem—but content strategy will.
Responsive design + content strategy = BFF 4 EVAH#section4
It’s time we acknowledged that every responsive web design project is also a content strategy project. For designers and developers who might not know what to emphasize, here are a few talking points:
Your content must be revised#section5
Even though the long-term goal is to serve the same content to every platform, organizations can’t just use what they already have. Smart companies will seize this opportunity to do what they should have done years ago: clean up and pare down their desktop content. You’ll never get a better chance to fix your content and publishing processes.
You may need to deal with legacy systems#section6
The tantalizing prospect of responsive web design is being able to solve the problem of “mobile” completely on the front end. The front end is so much more malleable than the back end, so of course we want to start there. But many responsive projects require changes to the way content and data are structured and published from the CMS or other legacy systems. For some, an approach to APIs will be needed; for many others, it will be an overhaul of content management and asset management systems.
Design your editorial workflow first#section7
The chicken-and-egg problem of content informing design (and vice versa) just got bigger—call it an ostrich-and-egg problem. While smart people have talked about the responsive design workflow and how design deliverables and processes must change, the editorial workflow also needs attention. Planning for how and when the content team will migrate, edit, and restructure content will help everyone ensure that the content and the design work together. 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.
You won’t have time to edit everything#section8
Even the most dedicated and ambitious teams won’t have the capacity to revise and restructure every page of their existing desktop website. Making informed and realistic decisions about what to focus on (and what to punt on) will help with overall planning, migration processes, and design decisions. Acknowledging this early will help get teams and stakeholders on board with the fact that not everything will be perfect.
Plan for long-term governance#section9
Responsive design also won’t fix your design standards and governance model, but we still need to include long-term maintenance in our objectives. I heard a story from one group who said they convinced their company that it wasn’t possible to do responsive design properly unless they also created and enforced a design system. The same argument could be made for developing and encouraging adherence to content standards.
Responsive design itself won’t fix your content—no one ever said it would. But the opportunity to implement a responsive redesign is also the opportunity to fix your content and its underlying strategy. It may seem more complicated to edit your content and fix your processes and systems at the same time you’re designing a new site—but in fact, pretending you don’t have to solve these problems just makes the job harder. Smart organizations will see this as a benefit, not a drawback, and will use this chance to make a better website, not just a squishy one.
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.
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.
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.
This article makes a good case, even just for images you need different crops.
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!
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.
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.
@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.
@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.
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.
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.
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
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.”
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
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.
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?
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.
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
@ 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.
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.
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.
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.
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?
@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/
@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.
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?
@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.
“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.
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.
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.
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.
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.
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.
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.
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.
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?
@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.
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/
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.
“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.
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.
Ah..Haaa… No wonder Apple.com website is not RWD.
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.
I agree that you can’t just serve up less content on mobile platforms, especially when so many people are now accessing the web on mobile devices. Do people still really think those users need less content, rather than better content?
Thanks Karen for helping to point out upgrading to a responsive website isn’t just a case of updating the template.
I am going through this at the moment with a client and didn’t pay much attention to the current content until the migration was complete and realised that many of the pages had originally been set up with tables and fixed image sizes which works fine on a fixed width page but not very well on mobiles.
Delving in to the template documentation has helped as I now realise I can apply CSS classes included with the template to create various width columns which collapse nicely on mobiles.
Keep up the good work!
Great article,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!