Wednesday, September 5, 2012

Karen McGrane – Content Strategy for Mobile


Go to article

Sean Carmichael
August 8th, 2012
Karen McGrane
Your content is visible practically everywhere. Content strategists need to structure content to allow for viewing on an array of devices. What does that mean for your content management system? And what do you need to build into your content to make it flexible and adaptable?
Karen McGrane, author of the upcoming book Content Strategy for Mobile, believes you should deliver great content to wherever your users want to consume it. In her virtual seminar, Content Strategy for Mobile, Karen says that even your organizational structure may need to change in order to facilitate this delivery. There were a ton of great questions from our audience that Karen didn’t have time to answer in the live seminar. She tackles those questions with Adam Churchill in this podcast.
  • Are the days gone where you can use a WYSIWYG editor to edit HTML?
  • How can complex tables of technical information be refactored for mobile?
  • How do you recommend people use the desktop site in mobile?
  • How can you evaluate content management systems to ensure good content strategy?
If you’re looking to bring content strategy into your UX process, you’ll want to attend Karen McGrane’s daylong workshop, Integrating Content Strategy in Your UX Process at the User Interface 17 Conference in Boston, November 5-7.
As always, we love to hear what you’re thinking. Share your thoughts in our comments section.
Recorded: July, 2012
Subscribe to our podcast via Use iTunes to subscribe to UIE's RSS feed. ←This link will launch the iTunes application.]
Subscribe with other podcast applications.]

Full Transcript.


Adam Churchill: Welcome, everyone, to another edition of the SpoolCast. Earlier this month, Karen McGrane joined us for her virtual seminar, “Content Strategy for Mobile.” In the seminar, Karen talks about adaptive structured content and the strategy you’ll need to achieve it.
“Content Strategy for Mobile” has been added to UIE’s User Experience Training Library, which has over 95 recorded seminars from wonderful topic experts just like Karen. Giving you the tips and techniques you need to create great design.
Hey, Karen. Welcome back.
Karen McGrane: Hey, thanks for having me back.
Adam: Now, for the folks listening who weren’t with us for your presentation, can you give us an overview of what they might have missed?
Karen: Sure. I’ve been talking about content strategy for mobile. Really, what I’m talking about is content strategy for figuring out how you’re going to get all of your content out onto this crazy new array of devices and platforms and screen sizes. It’s not just your mobile phone. It’s everything from your smartphone to tablets to, gosh, even your TV or your car or your refrigerator, if someday you want to consume content that way.
What I talked about in the seminar was figuring out how you’re going to structure your content in order to make that happen. What new flexibility, what new adaptability do you need to build into your content so that it’ll be ready to go other places? What’s going to need to change in your internal structure, in your content management system in the way that your editorial process works?
Even your organizational structure might need to change in order to support delivering great content to wherever your user wants to consume it.
Adam: There were some really good questions from our audience, Karen, and we thought we’d take a shot at answering some of them, the things that we didn’t get to. David wanted to know, “What about content contributors and other managers that have their fingers on the content and are thinking of editing the content as an exercise using a WYSIWYG editor to edit the HTML? Are those days gone, or can they leverage that experience as well?”
Karen: One of the things that I talked about in the seminar was this myth of the preview button, that a lot of content management systems today work a lot like your laser printer worked. When it was hooked up to your computer and you could use a desktop publishing package or Microsoft Word to essentially style and format your document, so what you saw on the screen was what you got when it was printed out.
A lot of desktop web content management systems kind of let you think the same way, or they try to help you imagine that the web is as fixed and as controlled as ink is on paper. Unfortunately, it’s never really been that way, and you’re never going to see that happen more than when you get your content onto a variety of different new devices.
If you click a button in your content management system and it takes you to a picture or takes you to a screen that shows you what your desktop web page looks like, you’re missing out on the context of all the other places where that content’s going to live.
This is a vexing problem. I’ve talked to some super-smart people at content management firms that have all been scratching their heads about, “What are we going to do with this?” It’s a variety of things. There’s still some room for using WYSIWYG-style formatting.
Things like bold or bulleted lists are fine, because you can give your content creators a tool to apply that style and then make it semantic on the back end. But the idea that the content creator is going to be able to imagine where their content is going to live on the page, we might need to do some work to break people out of that.
The analogy that I like to give is some of the examples of the way graphic designers have had to think about their work differently when they moved from doing print to the web. They had to break out of this notion of having pixel perfect control. Break out of the notion that they could dictate every single thing about the way that their design would look and work.
And I think in a lot of ways, content creators haven’t been forced to make that leap, or we’ve given them this illusion that they don’t have to make that leap. And now, frankly, it’s time that they have to.
While I love to look at my work in context as much as the next person, I clicked the “Preview” button on my blog today. We’ve got to get content creators imagining that their content is going to live in a variety of different places. That might mean not letting them imagine that they can preview their WYSIWYG work and it’s going to look exactly like that.
Adam: What about situations where there are very complex tables of technical information that need to appear? How do you recommend that they be redesigned or refactored to appear on mobile?
Karen: Oi. Yeah I think that tables and images are two of the most vexing problems that we will have as we attempt to get our content onto mobile. There’s not great answers for everything. Or it’s not like, I do not have a magic wand that I can wave that will automatically refactor your tables for you, or that will automatically allow you to shrink your images appropriately.
There’s going to be some production work involved. For tables, the question really does come down to is this a table that could reasonably be shrunk or could some columns be hidden?
Could you employ sort of a progressive disclosure approach to the table where a user on a smaller screen size would see only three or four columns of information and then the user could take an action to see more?
For some types of tables, like, some financial data, that’ll work really well. For other types of tables, I use an example of a garment size chart.
That’s not going to work so well. You certainly can’t go in and say, “I’ve decided that only users who care about these sizes will see this table, and then the other users will have to expand the table to see more.” That’s not going to work.
In those cases it really does take you digging into that content and trying to evaluate, is the tabular information the only way to present it? Could we present it as a list? Could we present it as something that could be scaled or scanned in different ways?
There’s no one-size fits all approach to solving this problem. It’s really going to be taking a variety of different strategies and then figuring out what’s going to work for your specific content.
Adam: Karen, in the seminar you actually showed some examples of, you were using “TV Guide” to demonstrate a point. A question came in, “Doesn’t writing three variations of a summary for one of those, isn’t that the same thing as writing three versions of a page?”
Karen: Right. I love this question. I really wanted to be able to get to this, because it gets to the essence of what I’m talking about. It can be a little elusive. I like to talk about not creating content for a specific context.
If you’re imagining that you have a separate mobile website, I described that as forking your content. What it means if you have a separate site, if you have a separate process, if you have a separate workflow, to update your content for the desktop side and the mobile side, you’ve just doubled your workload.
You’ve just put your content creators in a position of having to remember to make changes in multiple places, or you’ve set yourself up for things getting out of sync, and that’s a hassle. That’s one of the biggest things that people need to guard against.
Then I’ll come back and say, “Well, what you should be doing is you should be creating content packages.” I often suggest, so you can create multiple structures of content. You can write multiple headlines, you can write multiple summaries, you might chunk things out differently.
It’s pretty reasonable to ask, “Well, aren’t you doing the same work, then? Isn’t that the same? If you’re writing three different chunks for something, what’s the difference between whether it’s three different pages or three different chunks?”
The answer is that one of those things is happening on the backend. It’s that you’ve set up a content management interface and workflow, that is designed to make it as easy as possible for the content creator to manage and maintain all of that content in one place.
Someone can go in and they can look at a single screen or a single workflow and see all of the different content elements that are attached to that object, and update them all in one place.
That means that then the CMS’ job to figure out where to send each one of those content elements. It’s like, “OK. Send this long form of the headline to the desktop website and send this short form of the summary to the mobile site.”
It just lets the content creator imagine that what they have is this one unified package, as opposed to thinking of it as completely separate websites and completely separate workflows.
Really, when you start squinting at this problem and saying, “Oh, my goodness. Right. We’re going to have to manage and maintain all of this stuff, and we are going to have different content elements and we are going to need different content objects.”
Figuring out what that workflow is going to be, figuring out how that CMS interface and how that CMS process and editorial process needs to support it, is really the name of the game.
There’s one thing that anybody takes away from anything that I have to say about this. It’s, “Let’s try to make the job for our content creators as easy as possible, and let’s build the tools and the infrastructure that we need to support them in creating great content.”
Adam: The team at UC Berkeley wanted to know some ways that you recommend how people use the desktop in mobile.
Karen: So I think we have barely scratched the surface here in terms of what kind of research and analytics people can use to evaluate their desktop website and their mobile website, and really what kind of experience people can have on mobile.
I first tell people, “You can start right now by looking at the analytics data that you have about how people are using your site on mobile devices.” If you have a mobile website, maybe for most people it’s they probably have a mobile website that only delivers a subset of content or functionality, you should be really evaluating what’s happening with that analytics data.
What percentage of your visits are coming from mobile? What places are people, for example, jumping out of your mobile website and hopping back to the desktop? Are there places where people are trying to search for something that they can’t find on the mobile website? Which proportion of number of searches coming from mobile? What can you tell people are doing on mobile?
I really caution people to say, “Don’t necessarily take what people are asking for on mobile as gospel right now,” because, right now, people are getting a terrible experience. They’re getting a terrible experience from you and they’re getting a terrible experience on most other websites.
You can’t necessarily assume that what they’re saying right now is what they really want. You can at least evaluate that data and use it to start asking yourself some questions about, “What should we be doing better?”
To add to that the analytics data isn’t everything. It is time that you all started doing some user research or usability testing on mobile devices. One of the things I just wish more people would do is if you believe that having a link to your full desktop website is an adequate user experience. Then I would like you to go test that.
Go watch people in your target audience. And don’t just recruit iPhone 4, people with the retina displays who are experts at being consumers on their phones. Go find some ordinary people who are expected to know how to navigate around a desktop screen that was designed for a monitor five times the size, and ask them to look at it through the tiny little viewport on their phone and see how well they do.
There’s a variety of techniques that we’ve been deploying on the desktop web for, or even in software, for decades that now, like, go and use those observational techniques to watch people, what they’re doing, talk to them about what they want. And feed that back into your strategy. This can be a longer term process, but at least they’re doing the research now.
Adam: One of the things that happens in our virtual seminars, Karen, is that once we’ve got an expert like yourself in front of the audience, they are dying to know your thoughts on tools and resources that are available to them. Judy asked a specific question, looking for some tips on how to evaluate CMS systems to enable this good content strategy.
Karen: I said I would answer this question simply because I get asked after every talk that I give. Somebody asks me, like, “Well, what do you think the best CMS is?”
I have to laugh and say, “That is a decision of such complexity and such magnitude that I can’t even hope to begin to answer a question like that.”
[laughter]
Karen: There’s no go-to CMS. There’s only the best CMS for you. But from a content-strategy standpoint, there’s a couple things that I talk about. One is the difference between a coupled system and a decoupled system. I’m kind of embarrassed to even be talking about this because I am so not a technical architect.
But the way this works is sort of what I was alluding to earlier, talking about WYSIWYG on a preview button, that a lot of desktop web CMSs. They’re coupled. So what that means is that all of the content authoring and content storage functions are tightly connected to content display and content publishing.
It’s not unlike your desktop publishing package believing that what it’s going to output to is your laser printer. Those two functions are really tightly combined. That’s great, if all you have is a desktop website.
If your CMS believes that what it is publishing to is one and only once place, and that’s the desktop web, then having authoring and display coupled together is not such a problem, except when you want to go to multi-channel publishing.
A lot of larger enterprise systems are what’s called decoupled, which means that those functions are handled by two separate systems and then there’s an API or some way that those systems talk to each other.
I’m not a technical architect, but for a lot of organizations, when they really start looking at what they want to do with multi-channel publishing over the next three to five years.
They’re going to recognize, “Oh, man, our content-management system just wasn’t built to work this way, and we might need to think about how we decouple authoring and display functions and treat them differently.”
From a content management standpoint, then, I’m really interested in the authoring side of things. I’m really interested in organizations recognizing that they may not want to use an authoring model right out of the box, that instead they need to do user-experience design work on the interfaces and work flows in their CMS, to customize them and tailor them for the way that they want to work.
There’s a lot of CMS vendors out there that have sold organizations a bill of goods, claiming that, out-of-box, their system will work perfectly. It doesn’t. Really, what you need to do is you need to sit down and you need to model your content.
You need to talk to your content creators about their work flow, and you may need to do some work to tailor that experience so that it works right for your organization.
Adam: And a very important question. You are tying a couple of really neat topics together and are writing a book about it, and a lot of people were asking for more information about when that’s going to be available. Tell us more.
Karen: I’m currently writing a book, called, coincidentally, “Content Strategy for Mobile,” and it’s going to be published by A Book Apart sometime this fall. I have handed off the manuscript to the editor, and we are in the editing process right now. So I’m really excited. Hopefully that’ll be out sometime in October.
Adam: Very exciting. They’re doing a nice job with the books they’re putting out, so that’s a great thing to look forward to.
Karen: I’m glad to be a part of it. I am as excited for my book to come out as I am to have read all of the other books in that series.
Adam: Excellent. Karen, thanks for joining us again.
Karen: Thank you so much. I really appreciate you having me back.
Adam: Thanks, everyone, for listening in and for your support of the UIE virtual seminar program. Remember, you can get all the details on upcoming seminars at UIEVS.com.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.