Tags: content

8

sparkline

Content Buddy

I have a new role at Clearleft. It’s not a full-time role. It’s in addition to my existing role of …um …whatever it is I do at Clearleft.

Anyway, my new part-time role is that of being a content buddy. Sounds a little dismissive when I put it like that. Let me put in capitals…

My new part-time role is that of being a Content Buddy.

This is Ellen’s idea. She’s been recruiting Content Guardians and Content Buddies. The Guardians will be responsible for coaxing content out of people, encouraging to write that blog post, article, or case study. The role of the Content Buddy is to help shepherd those pieces into the world.

I have let it be known throughout the office that I am available—day or night, rain or shine—for proof-reading, editing, and general brain-storming and rubber-ducking.

On my first official day as a Content Buddy on Friday I helped Ben polish off a really good blog post (watch this space), listened to a first run-through of Charlotte’s upcoming talk at the Up Front conference in Manchester (which is shaping up to be most excellent), and got together with Paul for a mutual brainstorming session for future conference talks. The fact that Paul is no longer a full-time employee at Clearleft is a mere technicality—Content Buddies for life!

Paul is preparing a talk on design systems for Smashing Conference in Freiburg in September. I’m preparing a talk on the A element for the HTML Special part of CSS Day in Amsterdam in just one month’s time (gulp!). We had both already done a bit of mind-mapping to get a jumble of ideas down on paper. We learned that from Ellen’s excellent workshop.

Talk prep, phase 1: doodling.

Then we started throwing ideas back and forth, offering suggestions, and spotting patterns. Once we had lots of discrete chunks of stuff outlined (but no idea how to piece them together), we did some short intense spurts of writing using the fiendish TheMostDangerousWritingApp.com. I looked at Paul’s mind map, chose a topic from it for him, and he had to write on that non-stop for three to five minutes. Meanwhile he picked a topic from my mind map and I had to do the same. It was exhausting but also exhilarating. Very quickly we had chunks of content that we could experiment with, putting them in together in different ways to find different narrative threads. I might experiment with publishing them as short standalone blog posts.

The point was not to have polished, finished content but rather to get to the “shitty first draft” stage quickly. We were following Hemingway’s advice:

Write drunk, edit sober.

…but not literally. Mind you, I could certainly imagine combining beer o’clock on Fridays with Content Buddiness. That wasn’t an option on this particular Friday though, as I had to run off to band practice with Salter Cane. A very different, and altogether darker form of content creation.

Storyforming

It was only last week that myself and Ellen were brainstorming ideas for a combined workshop. Our enthusiasm got the better of us, and we said “Let’s just do it!” Before we could think better of it, the room was booked, and the calendar invitations were sent.

Workshopping

The topic was “story.”

No wait, maybe it was …”narrative.”

That’s not quite right either.

“Content,” perhaps?

Basically, here’s the issue: at some point everyone at Clearleft needs to communicate something by telling a story. It might be a blog post. It might be a conference talk. It might be a proposal for a potential client. It might be a case study of our work. Whatever form it might take, it involves getting a message across …using words. Words are hard. We wanted to make them a little bit easier.

We did two workshops. Ellen’s was yesterday. Mine was today. They were both just about two hours in length.

Get out of my head!

Ellen’s workshop was all about getting thoughts out of your head and onto paper. But before we could even start to do that, we had to confront our first adversary: the inner critic.

You know the inner critic. It’s that voice inside you that says “You’ve got nothing new to say”, or “You’re rubbish at writing.” Ellen encouraged each of us to drag this inner critic out into the light—much like Paul Ford did with his AnxietyBox.

Each of us drew a cartoon of our inner critic, complete with speech bubbles of things our inner critic says to us.

Drawing our inner critic inner critics

In a bizarre coincidence, Chloe and I had exactly the same inner critic, complete with top hat and monocle.

With that foe vanquished, we proceeded with a mind map. The idea was to just dump everything out of our heads and onto paper, without worrying about what order to arrange things in.

I found it to be an immensely valuable exercise. Whenever I’ve tried to do this before, I’d open up a blank text file and start jotting stuff down. But because of the linear nature of a text file, there’s still going to be an order to what gets jotted down; without meaning to, I’ve imposed some kind of priority onto the still-unformed thoughts. Using a mind map allowed me get everything down first, and then form the connections later.

mind mapping

There were plenty of other exercises, but the other one that really struck me was a simple framework of five questions. Whatever it is that you’re trying to say, write down the answers to these questions about your audience:

  1. What are they sceptical about?
  2. What problems do they have?
  3. What’s different now that you’ve communicated your message?
  4. Paint a pretty picture of life for them now that you’ve done that.
  5. Finally, what do they need to do next?

They’re straightforward questions, but the answers can really help to make sure you’re covering everything you need to.

There were many more exercises, and by the end of the two hours, everyone had masses of raw material, albeit in an unstructured form. My workshop was supposed to help them take that content and give it some kind of shape.

The structure of stories

Ellen and I have been enjoying some great philosophical discussions about exactly what a story is, and how does it differ from a narrative structure, or a plot. I really love Ellen’s working definition: Narrative. In Space. Over Time.

This led me to think that there’s a lot that we can borrow from the world of storytelling—films, novels, fairy tales—not necessarily about the stories themselves, but the kind of narrative structures we could use to tell those stories. After all, the story itself is often the same one that’s been told time and time again—The Hero’s Journey, or some variation thereof.

So I was interested in separating the plot of a story from the narrative device used to tell the story.

To start with, I gave some examples of well-known stories with relatively straightforward plots:

  • Star Wars,
  • Little Red Riding Hood,
  • Your CV,
  • Jurassic Park, and
  • Ghostbusters.

I asked everyone to take a story (either from that list, or think of another one) and write the plot down on post-it notes, one plot point per post-it. Before long, the walls were covered with post-its detailing the plot lines of:

  • Robocop,
  • Toy Story,
  • Back To The Future,
  • Elf,
  • E.T.,
  • The Three Little Pigs, and
  • Pretty Woman.

Okay. That’s plot. Next we looked at narrative frameworks.

Narrative frameworks as Oblique Strategies.

Flashback

Begin at a crucial moment, then back up to explain how you ended up there.

e.g. Citizen Kane “Rosebud!”

Dialogue

Instead of describing the action directly, have characters tell it to one another.

e.g. The Dialogues of Plato …or The Breakfast Club (or one of my favourite sci-fi short stories).

In Media Res

Begin in the middle of the action. No exposition allowed, but you can drop hints.

e.g. Mad Max: Fury Road (or Star Wars, if it didn’t have the opening crawl).

Backstory

Begin with a looooong zooooom into the past before taking up the story today.

e.g. 2001: A Space Odyssey.

Distancing Effect

Just the facts with no embellishment.

e.g. A police report.

You get the idea.

In a random draw, everyone received a card with a narrative device on it. Now they had to retell the story they chose using that framing. That led to some great results:

  • Toy Story, retold as a conversation between Andy and his psychiatrist (dialogue),
  • E.T., retold as a missing person’s report on an alien planet (distancing effect),
  • Elf, retold with an introduction about the very first Christmas (backstory),
  • Robocop, retold with Murphy already a cyborg, remembering his past (flashback),
  • The Three Little Pigs, retold with the wolf already at the door and no explanation as to why there’s straw everywhere (in media res).

Once everyone had the hang of it, I asked them to revisit their mind maps and other materials from the previous day’s workshop. Next, they arranged the “chunks” of that story into a linear narrative …but without worrying about getting it right—it’s not going to stay linear for long. Then, everyone is once again given a narrative structure. Now try rearranging and restructuring your story to use that framework. If something valuable comes out of that, great! If not, well, it’s still a fun creative exercise.

And that was pretty much it. I had no idea what I was doing, but it didn’t matter. It wasn’t really about me. It was about helping others take their existing material and play with it.

That said, I’m glad I finally got this process out into the world in some kind of semi-formalised way. I’ve been preparing talks and articles using these narrative exercises for a while, but this workshop was just the motivation I needed to put some structure on the process.

I think I might try to create a proper deck of cards—along the lines of Brian Eno’s Oblique Strategies or Stephen Andersons’s Mental Notes—so that everyone has the option of injecting a random narrative structural idea into the mix whenever they’re stuck.

At the very least, it would be a distraction from listening to that pesky inner critic.

10 Commandments of Web Design by Jeffrey Zeldman

I’m at An Event Apart in Atlanta, the first show of the year.

Jeffrey is opening the show with a talk called 10 Commandments of Web Design. He jokes that the W3C asked him to change it to 10 Recommendations of Web Design.

1. Thou Shalt Entertain

Have fun. We spend a lot of time thinking about accessibility, usability, performance, all that good stuff …but we sometimes forget about making it delightful and entertaining—the kind of thing that TV people have to think of all the time.

Take Panic Software, for example. Their logos—designed by Icon Factory—look beautiful, unlike your typical logo. Think about every website you’ve ever visited with a corporate philosophy or mission statement that nobody reads or is interested in …well, Panic’s personality is embodied in their design, their typeface choices, and their icons.

A List Apart uses Kevin Cornell’s illustrations to make technical-sounding articles into something more fun. It’s a lesson learned from the advertising world: the headline and the visual play together (and don’t forget: James Thurber wasn’t a good illustrator, but his work became immensely popular and is often emulated).

Jeffrey shows an example of a 404 page from Rdio, which doesn’t entertain. It just states the facts: page not found. Not very fun. Style-architects, on the other hand, refer to their missing page as a wardrobe malfunction. You don’t have to be Louis C.K., but try to be a bit witty. A Canadian political party’s 404 page states: “Ottawa’s broken. And so is this link. We’re working to fix both.” Nice. The New York Daily News website has a great illustration for its 404 page.

Gnu bars are fibre bars …that help you go to the bathroom. This could have been the worst website assignment ever, but they worked hard to get the joy of going to the bathroom in there. They have a Gnusletter (groan). On their serious medical pages, however, the tone isn’t so playful.

Flickr has its greeting in different languages. There’s no real point to this feature apart from providing some delight. A little touch, a little detail that didn’t need to be there, but it’s fun. But you probably wouldn’t want to do it on a military site about how to launch atomic weapons.

2. Test Everything (including assumptions)

“Who here has a test suite of devices?”, asks Jeffrey. You need one. Brad Frost has written a great post to get you started. There’s also technology like Remote Preview. Ryan Irelan wrote an article about putting together the Happy Cog device lab by getting a bunch of used equipment.

But let’s also test our assumptions. On the redesign of An Event Apart, there were some decisions that went against the accepted best practices. So they wrote about why they made those decisions, such as deciding to have empty alt text on photos in author bios because the author’s name (which would have been the alt text) is already in the headline. There were lots of comments, and many of them were really angry.

To get meta, Cennydd wrote a post about challenging the assumption that we should challenge our assumptions. Inception! Sort of. It was challenging the accepted wisdom that user-centred design is always the superior approach (compared to, for example, genius design). So, if Luke Wroblewski is putting a form together, given his years of experience, maybe he doesn’t need to test every little thing this time. Pushing user-centred design was important in the wild-west days of the web, but now we’re in a position to question it.

3. Thou Shalt Iterate

The website for A List Apart looks quite different from the original design ideas. Milton Glaser once said that the way he designs is by “moving stuff around on the page until it looks right.”

A List Apart used to have sharing links at the bottom of its articles. Logical, right? Who would want to share before reading the article? In the new design, those links are at the top of the page, and they got rid of the pretty buttons. You’d think they’d get less usage. In fact, they get much more usage: the Twitter link is just a simple link with pre-filled text. It turns out that users share and retweet before reading—they want to be the first to share. Jeffrey jokes that, as an experiment, he’d like to put something awful half-way through an article just to see if everyone would still share it (and I’m sitting next to Rey Bango who says, “That’s my fear!” “You share before reading?”, I ask him. He nods).

Amazon is constantly iterating, but in very small, subtle ways. And they test those changes.

4. Thou Shalt Ship

Good is the enemy of great …but great is the enemy of shipping. Sometimes we get so hung up on making something great, it gets in the way of shipping.

Jeffrey used to work at a company that had a perfectionist as a president, which is good in some ways, but they never shipped their product. Then the competition shipped. The company went out of business. They were so concerned about being great, they forgot to ship.

A friend of Jeffrey’s raises his rates when his clients don’t ship. The client questions, “Why does this now cost this much?” “Because you were supposed to have launched by now — and that’s preventing me from moving on to the next project.”

5. Engage Thy Community

Instagram did a poor job of relating their change of terms of service. This was actually pretty good for Flickr, who had just launched their great iPhone app.

Big companies buy small companies to get the cachet that the small companies have. “Isn’t that right?”, Jeffrey asks Rey. “Yes.”

Fonts.com are beginning to get more playful and engage with the type community. It’ll never be as cool as something like Dribbble (because fonts.com is a big company) but they can still push things forward.

The Happy Cog website has comments via Twitter (because, hey, who comments on blogs anymore?). A List Apart has embeddable comments: you can take a comment with you and embed it on your own website.

6. Love Thy User As Thyself

The first five commandments are really about this: knowing your user, and making sure they have a good experience, regardless of browser or device. Be responsive — not just in the technical definition of responsive web design, but in your mindset. Don’t make dumb assumptions just because someone is using a phone.

7. Remember The Content

Jeffrey brings up my blog post about Content First. And, of course, Mark has been writing about A Richer Canvas. Jeffrey took our words and wrote about them thusly: put the content first always. Instead of asking “Where should we put the sidebar?”, ask “Do we need a sidebar?”

Karen McGrane talks about content strategy for mobile and how it is literally becoming the law of the land: governments are mandating that content must be accessible on mobile. You don’t want to be the test case in a law suit.

8. Ignore Workflow At Thy Peril

Instagram nailed the workflow of sharing images. It starts uploading the picture in the background, even while you’re still futzing around with titles and descriptions. There are other things they don’t do particularly well, and it was more of a walled garden for a long time, but they prioritised the workflow of uploading images. Which leads us nicely to…

9. Thou Shalt Prioritize

Github allows you to label bugs and to-dos according to how important they are. That helps you nail the most important stuff without stopping you from shipping.

Kevin Hoffman wrote a great article about meetings, of all things. It’s all about coming to agreement on priorities.

10. To Thine Own Self Be True

Ah, the old Hay.net site: have hay, need hay. The site has since changed, but it’s still about hay. It didn’t “pivot.”

Smart talented people get promoted to being directors, but they might not be as good or as happy at that.

11. Think For Yourself

A bonus eleventh commandment. Don’t be a lemming.

Returning control

In his tap essay Fish, Robin sloan said:

On the internet today, reading something twice is an act of love.

I’ve found a few services recently that encourage me to return to things I’ve already read.

Findings is looking quite lovely since its recent redesign. They may have screwed up with their email notification anti-pattern but they were quick to own up to the problem. I’ve been taking the time to read back through quotations I’ve posted, which in turn leads me to revisit the original pieces that the quotations were taken from.

Take, for example, this quote from Dave Winer:

We need to break out of the model where all these systems are monolithic and standalone. There’s art in each individual system, but there’s a much greater art in the union of all the systems we create.

…which leads me back to the beautifully-worded piece he wrote on Medium.

At the other end of the scale, reading this quote led me to revisit Rob’s review of Not Of This Earth on NotComing.com:

Not of This Earth is an early example of a premise conceivably determined by the proverbial writer’s room dartboard. In this case, the first two darts landed on “space” and “vampire.” There was no need to throw a third.

Although I think perhaps my favourite movie-related quotation comes from Gavin Rothery’s review of Saturn 3:

You could look at this film superficially and see it as a robot gone mental chasing Farrah Fawcett around a moonbase trying to get it on with her and killing everybody that gets in its way. Or, you could see through that into brilliance of this film and see that is in fact a story about a robot gone mental chasing Farrah Fawcett around a moonbase trying to get it on with her and killing everybody that gets in its way.

The other service that is encouraging me to revisit articles that I’ve previously read is Readlists. I’ve been using it to gather together pieces of writing that I’ve previously linked to about the Internet of Things, the infrastructure of the internet, digital preservation, or simply sci-fi short stories.

Frank mentioned Readlists when he wrote about The Anthologists:

Anthologies have the potential to finally make good on the purpose of all our automated archiving and collecting: that we would actually go back to the library, look at the stuff again, and, holy moses, do something with it. A collection that isn’t revisited might as well be a garbage heap.

I really like the fact that while Readlists is very much a tool that relies on the network, the collected content no longer requires a network connection: you can send a group of articles to your Kindle, or download them as one epub file.

I love tools like this—user style sheets, greasemonkey scripts, Readability, Instapaper, bookmarklets of all kinds—that allow the end user to exercise control over the content they want to revisit. Or, as Frank puts it:

…users gain new ways to select, sequence, recontextualize, and publish the content they consume.

I think the first technology that really brought this notion to the fore was RSS. The idea that the reader could choose not only to read your content at a later time, but also to read it in a different place—their RSS reader rather than your website—seemed quite radical. It was a bitter pill for the old guard to swallow, but once publishing RSS feeds became the norm, even the stodgiest of old media producers learned to let go of the illusion of control.

That’s why I was very surprised when Aral pushed back against RSS. I understand his reasoning for not providing a full RSS feed:

every RSS reader I tested it in displayed the articles differently — completely destroying my line widths, pull quotes, image captions, footers, and the layout of the high‐DPI images I was using.

…but that kind of illusory control just seems antithetical to the way the web works.

The heart of the issue, I think, is when Aral talks about:

the author’s moral rights over the form and presentation of their work.

I understand his point, but I also value the reader’s ideas about the form and presentation of the work they are going to be reading. The attempt to constrain and restrict the reader’s recontextualising reminds me of emails I used to read on Steve Champeon’s Webdesign-L mailing list back in the 90s that would begin:

How can I force the user to …?

or

How do I stop the user from …?

The questions usually involved attempts to stop users “getting at” images or viewing the markup source. Again, I understand where those views come from, but they just don’t fit comfortably with the sprit of the web.

And, of course, the truth was always that once something was out there on the web, users could always find a way to read it, alter it, store it, or revisit it. For Aral’s site, for example, although he refuses to provide a full RSS feed, all I have to is use Reeder with its built-in Readability functionality to get the full content.

Breaking Things

This is an important point: attempting to exert too much control will be interpreted as damage and routed around. That’s exactly why RSS exists. That’s why Readability and Instapaper exist. That’s why Findings and Readlists exist. Heck, it’s why Huffduffer exists.

To paraphrase Princess Leia, the more you tighten your grip, the more content will slip through your fingers. Rather than trying to battle against the tide, go with the flow and embrace the reality of what Cameron Koczon calls Orbital Content and what Sara Wachter-Boettcher calls Future-Ready Content.

Both of those articles were published on A List Apart. But feel free to put them into a Readlist, or quote your favourite bits on Findings. And then, later, maybe you’ll return to them. Maybe you’ll read them twice. Maybe you’ll love them.

Re-tabulate

Right after I wrote about combining flexbox with responsive design—to switch the display of content and navigation based on browser size—I received an email from Raphaël Goetter. He pointed out a really elegant solution to the same use-case that makes use of display:table.

Let’s take the same markup as before:

<body>
<div role="main">
<p>This is the main content.</p>
</div>
<nav role="navigation">
<p>This is the navigation.</p>
<ol>
<li><a href="#">foo</a></li>
<li><a href="#">bar</a></li>
<li><a href="#">baz</a></li>
</ol>
</nav>
</body>

The source order reflects the order I want on small-screen devices (feature phones, smart phones, etc.). Once the viewport allows it, I’d like to put that navigation at the top. I can do this by wrapping some display declarations in a media query:

@media screen and (min-width: 30em) {
    body {
        display: table;
        caption-side: top;
    }
    [role="navigation"] {
        display: table-caption;
    }
}

That’s it. It works much like box-orient:vertical with box-direction:reverse but because this is good ol’ CSS 2.1, it’s very well supported.

We can solve the other issue too: making those list items display horizontally on larger screens:

[role="navigation"] ol {
    display: table-row;
}
[role="navigation"] ol li {
    display: table-cell;
}

Once again, I’ve put a gist up on Github (get me! I’m like a proper computer nerd).

Update: And Remy has put it on JSbin so you can see it in action (resize the live preview pane).

So there you go: we’ve at least two different mechanisms in CSS to re-order the display of content and navigation in response to screen real-estate. The default is content first, navigation second—a pattern that Luke talked about in this interview with Jared:

Yeah, one of the design principles that I’ll be talking on the tour about, for mobile, is content first, navigation second; which is just really putting something up right away that somebody can engage with, and saving the pivoting and the navigating for later.

There’s, basically, UI patterns that you can use to make that happen. I’m still surprised at how many, both mobile websites and applications, the first thing they give you is a menu of choices, instead of content.

Don’t get me wrong, the menu’s important, and you can get to it, but it’s actually the content that the immediacy of mobile, and the fact that you’re probably on a slower network, and in some cases you’re even paying for your data transfers, right? Giving you a list of choices as your first time experience tends not to work so well.

Luke Wroblewski — Designing Mobile Web Experiences » UIE Brain Sparks on Huffduffer

Content First

Andy recently published 320 and up, a fork of Mobile Boilerplate that inverts his previous boilerplate media queries i.e. now it starts with the small-screen styles and layers on the styles for larger widths, rather than beginning with larger-width styles and nullifying them for smaller screens.

This is definitely the best way to apply width-specific styles, be it with media queries or with JavaScript. But I get a little nervous when I see pixel values that correspond to specific device widths: 320 pixels, 480 pixels, etc.—it’s certainly an improvement on relying on one mythical width like 960 pixels, but I worry that it still means crafting the display of content to match the dimensions of currently fashionable viewports. This is what Mark describes as the “canvas in” approach:

It’s my belief that in order to embrace designing native layouts for the web – whatever the device – we need to shed the notion that we create layouts from a canvas in. We need to flip it on its head, and create layouts from the content out.

Now it may well be that your content is pixel-based—images or video perhaps—and the dimensions happen to correspond to the viewport widths of specific devices, but in my experience most of the content I deal with is still very much of the written word variety …and pixels aren’t necessarily the best unit for dealing with text. That’s one of the reasons why I tend to use em-based media queries.

My basic point is that it should be the content that dictates the media queries. For some sites, it might be appropriate to only serve up a linearised layout to very small screens while applying a columnar layout for slightly larger devices like tablets. For other sites, tablet-sized screens should get a linearised layout—it all depends on the content.

One of my favourite examples of content-out thinking is Dan’s article on type-inspired interfaces. I think there’s a general agreement amongst web designers that we should be designing from the content out but there’s still an over-reliance on canvas-in tools like predefined grids. Likewise in the world of wireframing and information architecture, when we should be concentrating on the content we often gravitate towards designing the menus and navigation first.

This is something that Luke talked about with Jared recently, mentioning his design principle of “content first, navigation second.”

Luke Wroblewski — Designing Mobile Web Experiences » UIE Brain Sparks on Huffduffer

Luke has famously advocated a mobile first approach to web development, which is a great way of focusing on what’s most important to deliver to the user. But don’t take it too literally. In some ways it would be equally viable to try out “print-stylesheet first” or any other “non-desktop environment first” strategy. The key point is that you’re thinking about the content first and foremost:

Losing 80% of your screen space forces you to focus. You need to make sure that what stays on the screen is the most important set of features for your customers and your business. There simply isn’t room for any interface debris or content of questionable value. You need to know what matters most.

That isn’t to say that you can’t serve up some extra nice-to-have content to wider screens, but that should be added on—possibly with conditional lazy loading—rather than having everything including the kitchen sink thrown in from the start.

Mobile web design has already established a number of excellent best practices whereas traditional “desktop” web design has become the domain of laziness and complacency. The result is a web of bloated documents with buried content, as documented in Merlin’s Flickr set, Noise to Noise Ratio:

Sure. There’s definitely some excellent original work in there — in the middle of all those ads and self-links and chrome and value-added “journalism.”

Yeah. Keep looking. No, seriously. There’s gotta be something in there.

Right?

NTNR - All Things Chrome Inspiration, of a kind

There’s a general agreement that the “mobile” user is not to be trifled with; give them the content they want as quickly as possible ‘cause they’re in a hurry. But the corollary does not hold true. Why do we think that the “desktop” user is more willing to put up with having unnecessary crap thrown at them?

Unnecessary page cruft is being interpreted as damage and routed around with tools like the Readability bookmarklet, Safari’s Reader functionality, and Instapaper. These services exist partly to free up content from having a single endpoint but they also serve to break content free from the shackles of stifling overwrought containers. This isn’t anything new, of course; we’ve been here before with RSS. But the existence of these new reader-empowering tools should be taken as a warning …and a challenge—how can we design for our content in such a way that the reader won’t need or want to reach for Readability or Instapaper?

Some of the worst offenders in creating bloated content-crushing designs—often news sites—have separate mobile versions, usually at an m. subdomain. There the content is served up without the frills, cruft and pagination of the “desktop” version. I’ve started noticing that when people are sharing links—via Twitter, email, or whatever—it’s often these leaner m. versions that are getting passed around …precisely because they are often easier to read, no matter what device you’re using.

We’ve been here before, as I pointed out in a comment to Paul’s misguided post on mobile design:

In the bad ol’ days, it was common practice to create a “separate but equal” text-only site for screenreader users. It ghetto-ised those users and it was, frankly, a cop out. These days, it’s understood that screenreader users should get the same content as everyone else, but that the site should be built the right way to begin with. (interestingly, some sites noticed that “regular” non-screenreader users were choosing to go to the “accessible” version because it was faster and simpler—there’s a lesson to be learned there for those who still think of desktop and mobile sites as different things)

Needless to say, I disagree completely with this proclamation from Jakob Nielsen:

Desktop computers and mobile devices are so different that the only way to offer a great user experience is to create two separate designs — typically with fewer features for mobile.

I’m perplexed by the reasoning that concludes that if a website is suffering from clear usability issues, the solution is to create a splinter site for some users while leaving everyone else to suffer on. Note that I’m not suggesting that everyone get the same experience—far from it. Thanks to progressive enhancement (and let’s face it, responsive design done right is a perfect example of progressive enhancement) we can serve up the content that people want and display it to the best ability of any particular device.

That’s the key difference: start with the content, not the device.

This is a really exciting time for web design. The increasing diversity of devices is throwing into sharp relief just how complacent and wrong-headed our traditional fixed-width bloated desktop-centric approach has been. As with any period of change, there’s plenty of nervousness too. People are scrambling to figure out how best to deal with mobile devices:

  • “Should I be learning Objective-C?”
  • “Should I be mastering HTML5?”
  • “Should I be learning a mobile app framework?”

You could be doing any or all of those things. But don’t skimp on the content strategy.

Reminder: the usual caveat applies.

Optimisation

Derek Powazek gave up smoking recently so any outward signs of irritability should be forgiven. That said, the anger in two of his recent posts is completely understandable: Spammers, Evildoers, and Opportunists and the follow-up, SEO FAQ.

His basic premise is money spent on hiring someone who labels themselves as an SEO expert would be better spent in producing well marked-up relevant content. I think he’s right. In the comments, the more reasonable remarks are based on semantics. Good SEO, they argue, is all about producing well marked-up relevant content.

Fair enough. But does it really need its own separate label? Personally, I would always suggest hiring a good content strategist or copy writer over hiring an SEO consultant any day. Here’s why:

Google—or at least the search arm of the company—is dedicated to a simple goal: giving people the most relevant content for their search. Google search is facilitated by ‘bots and algorithms, but it is fundamentally very human-centric.

Search Engine Optimisation is an industry based around optimising for the ‘bots and algorithms at Google.

But if those searchbots are dedicated to finding the best content for humans, why not cut out the middleman and go straight to optimising for humans?

If you optimise for people, which usually involves producing well marked-up relevant content, then you will get the approval of the ‘bots and algorithms by default …because that’s exactly the kind of content that they are trying to find and rank. This is the approach taken by Aarron Walter in his excellent book Building Findable Websites.

On Twitter, Mike Migurski said:

I think SEO is just user-centered design for robots.

…which would make it robot-centred design. But that’s only half the story. SEO is really robot-centred design for robots that are practising user-centred design.

Ask yourself this: do you think Wikipedia ever hired an SEO consultant in order to get its high rankings on Google?

Content First

Because it takes two people to replace Eric Meyer, Kristina Halvorson has stepped into the breach at An Event Apart in Boston. At last week’s UX London, Dan described her as the patron saint of content strategy. Her talk is called Content First. She begins by listing a bunch of Twitter hashtags and pointing out the excellent A Feed Apart.

Kristina started out as a Copy Writer and morphed into being a Web Writer. For a long time, there was no such role as Content Strategist. That meant that the Web Writer was divorced from the rest of the team. Everyone was talking about user experience but nobody was talking about the content. We’ve got user flows, mental models, eventually the site map. At this point, everyone’s happy. Then someone looks at the schedule. Copy writing (usually lumped in with SEO) is allocated a couple of weeks at most. They call in the Copy Writer, show the diagrams and functional specs and say, off you go! Now you’ve got two weeks (tops) to figure out the content requirements and deliver the content. How did we allow this to happen?

Content isn’t a three-step create, revise and approve process. It’s much more complex than that. And it’s never done.

Kristina quotes the origin of the phrase information architecture. Then Tufte came along. Designers took it upon themselves to craft information that was understandable and digestable. Then the web came along. To begin with, it was treated as a visual medium. Jesse James Garrett changed the emphasis to user experience. But where is content in Jesse’s diagram? It’s on the second level. Then it disappears. We were approaching content on the same level as functional specs; a feature than can be ticked off a list. But content is a living, breathing thing that evolves over time. Once you put it online, you are required to feed it and take care of it.

Content is almost always the last thing to be considered and the last thing to be deliverd. This is the Content Delay Syndrome. In Kelly’s book, she says Accept it. Plan for it. Charge for it. Kristina thinks that sucks. Content Strategy is a better way.

Content can be text, graphics, video and audio. Kristina mostly works with text.

Strategy is often seen as what we’re going to do. But most people conflate tactics with strategy. Strategy is actually about answering all those good journalistic questions, why are we doing this?, who is this for?, what do we have to work with?

Here’s the homepage for Quicken. First thing you see is the happy guy. Then you see four red boxes for four different products. Then you see price points; a consideration to be sure, but this is your financial well-being we’re talking about. This probably all looked great in a wireframe. The content got poured in to the layout at the end.

Mint has an awesome content strategy even though they don’t have much content. The content is focused on you.

Plan. Create. Publish. Govern.

Governance is important. The Swiffer “live” YouTube channel has been left to rot. People still leave comments but the last curator login was nine months ago.

Right now, the mind set is launch and leave it. But content is cyclical. It needs a process.

Audit. Analysis. Strategy.

  • Auditing content is usually thought of as cataloguing pages. That’s a quantitative audit. It tells you where? and how much? Qualitative audits are more useful by telling you how useful content is. There’s also specialised auditing such as dealing with metadata.
  • Analysis is one of the most important things that a content strategist can do but it’s also often overlooked. Don’t just jump into action. You might think you don’t have the time or budget for this part; invest in it. You need to consider brand and messaging, the channels you will be using to deliver content, user research… Kristina is aware that most people don’t have the budget for all of this but you can still start introducing it a little at a time. There’s a whole bucket of other stuff to consider; technical infrastructure, internal politics, stakeholder swoop’n’poop.
  • Finally you can put a strategy together. This is where the content strategist really takes ownership of the content. That’s often the problem with content, right? Nobody takes ownership of it. Maybe it’ll be the information architect, maybe it’ll be the user experience designer. The important thing is that someone is in charge of it. Always consider what will happen when the content is out there. Don’t launch a blog, for example, unless you’re willing to invest time in it.

The page stack symbol in IA diagrams will kick your ass. As far as the information architect is concerned, this is where the magic happens.

The page template, usually filled with lorem ipsum, is a useful tool but it only shows you structure. It doesn’t answer any questions about what your users need.

Page tables are a new tool. They identify structure, but also the details and, importantly, the implications. It also poses questions, who is in charge of this?, how will this be accomplished? This is dirty work but someone has to do it. Of course, if you have 1200 pages, you won’t build page tables for each one but you should build a page table for pages with specific objectives and specific user needs.

Content inventory involves mapping out what you’ve got and what you’re going to need. This is usually a spreadsheet.

This is all something we can do. Imagine having this instead of lorem ipsum …lorem ipsum must die!

Why do this? Think about why people go online. They want content. Support your users in their quest.

How can you start? The reality is probably that you can’t just hire a content strategist tomorrow. But you can change your mindset. When we talk about user experience, content is missing from the discussion. Let’s change that.