Scriptorium Publishing

content strategy consulting

Uber, disruption, and content strategy

March 30, 2015 by

I used Uber and lived to tell the tale. And I found a lesson for content strategy in my rides to and from the airport in San Francisco.

Uber competes with taxi and car services. It is controversial and possibly disruptive.

From the customer’s point of view, Uber is an incredible improvement. It fixes all the bad things about the traditional taxi experiences—you get cashless transactions, a map on which you can watch your ride approach, and lower fares than taxis (sometimes). No tipping. Near-instant response.

But look a little deeper, and I’m troubled by the business model that seems unfair to taxi drivers, who have been thoroughly vetted and who paid a lot of money for their taxi licenses. Uber undercuts this model by providing the technology layer that connects drivers to riders, and arguing that they are not in fact a transportation company, only a match-maker for ride-sharing. The German government disagrees, and has banned some Uber services, as has the city of Portland, Oregon and several other jurisdictions around the world. Uber has also engaged in some…questionable…business strategies.

But my misgivings about using them were outweighed by the convenience and, critically, the strong recommendations from Val Swisher and Scott Abel, both of whom are Bay Area locals. After using Uber and emerging unscathed, I offer some lessons for content strategists:

  • The customer wants a good experience. They don’t really care about how you achieve the good experience. Your organizational problems are of no interest to the customer, only your interaction with the customer. A few companies have made their ethics a key reason to buy (Patagonia and Ben & Jerry’s come to mind), but without an explicit story, customers will not make this connection on your behalf. (Possible content marketing strategy for taxi companies: Tell the story of their cabbies—the plucky immigrant who is living the American dream, the New York native who loves working on cars and knows all the back roads, and so on.)
  • Your regulatory problems are of little interest to me, er, them. (Possible exception: life-and-death content, such as medical information or aircraft maintenance information.) Uber has aggressively positioned taxi regulations as outdated and inconvenient. The taxi companies need to tell the story of why the regulations are necessary and good, such as launching a sustained campaign around Uber’s infamous surge pricing policy.
  • Banning your unauthorized competitor is probably not going to work. (It doesn’t work with Uber; it’s definitely not going to work with information.) So figure out how to accommodate illicit content as part of your strategy. Or improve your customer experience so that people don’t go looking for a (possibly sketchy) alternative. (Unauthorized translations by resellers come to mind. They usually happen when the content owner fails to make the content available in the needed languages.)

Uber is a cautionary tale for anyone who makes their living in a closed market.

After finishing this article on Friday afternoon (March 28) and scheduling it for publication on Monday morning, I received this email late Friday night:

They are your drivers, and we want to celebrate them. Meet the people behind the wheel who make it all possible. (Image of smiling driver.)

Well played, Uber. Well played.

Buyer’s guide to CCMS evaluation and selection (premium)

March 2, 2015 by

“What CCMS should we buy?”

It’s a common question with no easy answer. This article provides a roadmap for CCMS evaluation and selection.

First, a few definitions. A CCMS (component content management system) is different from a CMS (content management system). You need a CCMS to manage chunks of information, such as reusable warnings, topics, or other small bits of information that are then assembled into larger documents. A CMS is for managing the results, like white papers, user manuals, and other documents.

1. Why do you need a CCMS?

assortment of yarns in store

Why do you need a CCMS? // flickr: lollyknit

The very first step in CCMS evaluation is to determine why you need a CCMS. (Sorry, this sounds like a Fight Club reference.) What business problem are you trying to solve? I am amazed at the number of people who think they need a CCMS but cannot articulate why. Some common reasons for CCMS implementation are increases in:

  • Volume of content
  • Translation requirements
  • Velocity of content
  • Versioning

Before you do anything, understand the scope of your problem and whether a CCMS can solve it. What is broken? Is it more broken than last year? Why? Some common examples of problems that a CCMS will not solve are:

  • Content is inaccurate.
  • Writers lack necessary technical expertise.
  • Departments are siloed because of a lack of mutual professional respect.
  • Content creators refuse to follow style guides because their content is special.
  • In short, all of the People Things™.

If you have issues with People Things, you need to address those in addition to (and preferably before) any CCMS initiatives.

2. What is your ROI?

CCMS implementation is expensive. The cost of CCMS software varies, but implementation is expensive no matter what. Assuming you have a problem that a CCMS will address, your next step is to calculate your approximate return on investment. You’re looking for a rough order of magnitude here, and much of this calculation is driven by your scale. If, for example, you have 50 full-time content creators, and you assume a loaded cost of $100,000 per person per year, then a 10 percent improvement in efficiency is equal to around $500,000 in yearly savings.

By contrast, if your annual translation budget is $50,000, you probably won’t find ROI justification in cutting translation costs.

You can build ROI based on:

  • Cost avoidance
  • Increased revenue
  • Time

Cost avoidance is an efficiency argument: “If we buy X, we can do task Y with less effort.”

Increased revenue is an investment argument: “If we buy X, we will get more income from Y.”

Time is usually a time-to-market argument: “If we buy X, we can deliver Y in two months instead of six months.”

Our XML business case calculator lets you estimate your potential ROI from a transition from desktop publishing to XML.

Once you have some sort of idea of the cost improvement (the “return” part of ROI), you can move on to figure out the other side of the equation–how much do you need to invest? Your initial cost estimates will tell you what class of CCMS you should be looking at. For general guidance, refer to our XML workflow costs article.

3. There is no bad CCMS. Only bad fits for you.

The trick to buying the right CCMS is to find the one that meets your requirements. Every system on the market has strengths and weaknesses. There is no single Best CCMS, nor is there a Bad CCMS. What we have is systems that are better in some scenarios than others. Therefore, you need to figure out the following:

  • What are your priorities?
  • Which system best matches your priorities?

Figuring out your own requirements is your job. Once you have some vague idea of what you need and have done preliminary research, consider issuing a formal RFI (request for information) to get better vendor information.

At this point, you should not be issuing an RFP (request for proposal). You don’t know exactly what you want to ask for yet.

4. What features do you need?

Knitting markers in various shapes

Pay attention to features // flickr: trilliumdesign

“What features do you need in a CCMS?”

“Version control.”

Well, duh. Let’s ask a better question: “What features do you need beyond the basics?” Answers in the past few years from different clients have included items such as:

  • “We have no IT support, so the system needs to be SaaS  (software-as-a-service).”
  • “The system must not be SaaS.”
  • “The system must integrate with [SAP | web CMS | others].”
  • “The system must generate output via [this protocol] to [this format].”
  • “The interface must be available in [this language].”
  • “The system must cost less than [this amount].”
  • “The system must align with the branching techniques we use in [this software development tool].”
  • “The system must be installed and running by [some very soon date].”
  • “The system must support [this content model].”

You want to thoroughly understand your exact requirements and constraints so that you can narrow down your choices quickly. Don’t make a list of boring stuff that every CCMS does. It’s a waste of everyone’s time, especially yours.

Instead, do the following:

  • Identify your most unique requirements (regulatory? system architecture? content volume? languages?)
  • Write up detailed use cases for your most critical requirements and use those to evaluate the systems

Your use case scenarios will help you evaluate the candidates and figure out whether they really meet your requirements.

5. Is extensibility important?

How will your CCMS interact with other systems? Which other systems do you need to interact with? If extensibility is important, focus on the systems that provide a good starting point for this type of integration.

6. What is your exit strategy?

Start planning your exit strategy on the way in. If you ever decide you want to take your content and shift it to another system, will you be able to do so? What is your exit strategy?

7. Vendor relationship

Can you communicate successfully with the CCMS vendor? If not, the implementation and integration process is going to be extremely painful.

Don’t play games with your vendors. The CCMS world is extremely small. People move from one software vendor to another constantly. As a result, there is an excellent industry grapevine. Bad behavior, whether by CCMS vendors, by consultants, or by potential CCMS buyers, is not an option–word gets around quickly.

Not too long ago, I asked a colleague about working with a particular prospect, who seemed a bit….difficult. His response? “Run. Run fast. Then hide.”

Test your vendor relationship with a low-budget, low-commitment pilot project.

Additional resources

This brief overview only scratches the surface of what you need to consider. More resources:

Conditional content in DITA (premium)

February 9, 2015 by

This post provides an overview of techniques you can use to handle conditional content in DITA. The need for complex conditions is a common reason organizations choose DITA as their content model. As conditional requirements get more complex, the basic Show/Hide functionality offered in many desktop publishing tools is no longer sufficient.

Conditional processing is especially interesting–or maybe problematic—when you combine it with reuse requirements. You identify a piece of content that could be reused except for one small bit that needs to be different in the two reuse scenarios.

The first step in establishing a strategy for conditional content is to clarify your requirements and ensure that you understand what you are trying to accomplish.

Classes of text variants

DITA offers two basic types of variants:

  • Variables (implemented through DITA keys): a short snippet, like a product name, that often changes.
  • Conditional information: an element or group of elements that needs to be included or excluded selectively. Conditional information can occur at the topic, block, or inline level. Graphics and tables can also be conditionalized.

In DITA, your conditional assignments need to correspond to an element. In unstructured desktop publishing tools, it’s possible to assign conditions to an arbitrary chunk of content. This is not the case in DITA because you need to attach the conditional labeling to an element. (In theory, it’s possible to use processing instructions to mimic the arbitrary labeling, but just…don’t.)

Variables

Here’s what a simple variable looks like. First, you define the variable as a key (in this case, clientname) in the map file.

<map>
    <title>DITA Topic Map</title>
    <keydef keys=“clientname”>
       
<topicmeta>
            <keywords>
                <keyword>My First Client</keyword>
           
</keywords>
        </topicmeta>
    </keydef>
    <topicref href=“sample.dita”/>
</map>

Inside the topics, you reference the key:

<p>When we deliver this information to <keyword keyref=“clientname”/>

You use a placeholder for the keyword in your text, and you use the map file to define the value of the placeholder. Therefore, you can use a single topic with a keyref along with multiple map files. The result will be different output for the key reference for each of the maps. (DITA 1.3 adds scoped keys, which allow you to change the key’s value inside a single map file.)

Conditions

In DITA, you use attributes to identify conditional content:

<p>This paragraph is for everyone.</p>
<p
audience=“advanced”>This paragraph is only for advanced users.</p>

<note><p>
      It’s possible to do conditional content at the phrase level<ph platform=“badidea”>, but it’s a really terrible idea</ph>.
</p></note>

If you have more complex combinations, you use more than one attribute:

 <p audience=“expert”

      platform=“windows”

      product=“X”>content goes here</p>
<p audience=“expert” 

           platform=“windows mac”

           product=“X Y Z”>other content here</p>

Do not use conditions below the sentence—preferably paragraph—level.

Why not, you ask?

<p>The colo<ph xml:lang=“en-uk”>u</ph>r of money is a very speciali<ph xml:lang=“en-uk”>s</ph><ph xml:lang=“en-uk”>z</ph>ed topic.</p>

Two reasons:

  1. Your translator will hate it.
  2. You will go insane.

Specifying conditional output

Once you have assigned your attribute values, you use a ditaval file to specify what to include and exclude when you generate output through the DITA Open Toolkit. Here is a simple example:

<val>
<prop action=“include” att=“audience” val=“expert”/>
<prop action=“include” att=“product” val=“X”/>
</val>

Markup is the small(er) challenge

You assign attributes to an element to make it conditional. You can assign conditions, therefore, to anything that has an element, all the way down to phrases, words, or even letters (but again, don’t go below sentences). DITA gives you three attributes out of the box (audience, product, platform) for conditional processing. If you need more or different attributes, you’ll need to specialize.

Establishing a reasonable taxonomy and information architecture presents a much more difficult challenge that the actual assignment of conditional markup. You have to figure out which attributes to create, what values they should have available, and how you might combine the attributes to generate the variants you need.

Consider the case of information that is applicable only to a specific region, like California:

<warning audience=“ca”>
     <p> This product contains chemicals known to the State of California to cause cancer and birth defects or other reproductive harm.</p>
   </warning>

This works, provided that your regions are limited to the fifty U.S. states. If you needed to flag information for Canada, that “ca” designator would suddenly become problematic. Perhaps you’d try specifying the country in addition to the state:

<warning audience=“usa-ca”>…California content… </warning>

<warning audience=“ca”>…Canada content…</warning>

As long as you planned for California and Canada, everything will be OK. The problem occurs when you start with a list of states and an assumption that you’ll never need non-US regions, and then suddenly you do.

Conditions and reuse

The combination of conditional variants and reuse is especially problematic. One interesting solution is to use a conref push. A conref push allows you to insert (or “push”) information into a topic.

We use this technique in some of our software assessments. We have a general overview of a particular piece of software with information our clients need, like cost, licensing terms, supported platforms, and so on. But we also need to include our overall recommendation for or against that software. This final bit of information is different for each customer.

To accommodate this, we set up the location where the information is needed with an ID. In our case, this is the last paragraph in the assessment of XYZ tool:

<p id=“xyz”>We recommend XYZ if ABC is a critical requirement.</p>

We then create another topic, referenced in the parent map file as a resource, that provides the information to be inserted:

<p conref=“file.dita#id/xyz” conaction=“mark”/>
      <p conaction=“pushafter”>Using XYZ would eliminate the manual formatting that currently takes up so much production time at ClientA.</p>

For another client, we have a different map file and a different piece of content to be inserted:

<p conref=“file.dita#id/xyz” conaction=“mark”/>
      <p conaction=“pushafter”>XYZ does not support right-to-left languages (such as Arabic), which ClientB needs.
</p>

 

What are your experiences with DITA conditional content?

The talent deficit in content strategy

February 2, 2015 by

Content strategy is taking hold across numerous organizations. Bad content is riskier and riskier because of the transparency and accountability in today’s social media–driven world.

But now, we have a new problem: a talent deficit in content strategy.

Our industry has talented people; it’s just that the demand for content strategists exceeds the available supply. Furthermore, we have an even bigger problem in writing, editing, and production. Enterprise content strategy very often means the introduction of professional-grade tools and workflows (such as XML, CMS, and rigorous terminology and style guides), but many content creators are unprepared for this new environment.

Technical deficit

On the technical side, writers need new skills, such as structured authoring, XML, DITA, and CMS usage. Editors—who move into information architecture roles—must understand how to apply metadata and how to build an effective set of metadata for specific requirements. Deep knowledge of reuse types and applying them is critical. An understanding of localization best practices is helpful for any global organization.

The most technical roles, XSLT stylesheet developers and CMS administrators, must be filled by individuals with a hybrid of IT and publishing skill sets.

Business analysis deficit

Organizations need to first understand their business goals and then use the identified goals to decide on an appropriate content strategy. Here, we face another major skill gap. Although lots of people understand that XML is useful, and some can spell out how XML might be useful, the ability to connect “useful things XML can do” to “what the business needs” is rare. Most publishing people love books. The business component is only of incidental interest.

This presents a problem (or maybe an opportunity) for content strategy consultants.

Why is this a problem

It’s a good time to be a content strategist, a writer with the right technical skills, a stylesheet developer, or a CMS administrator. From your point of view, there are tons of job opportunities, which likely means higher salaries.

When we look at the overall industry, though, we have a problem. Several of our clients have open positions that they are struggling to fill. They are having an especially difficult time finding information architects for DITA. If this continues, the benefits of a very challenging toolset (like DITA) may be outweighed by the lack of available staff. From an executive’s point of view, there are a lot of negatives: more skilled individuals command higher salaries and are hard to find.

Closing the gap

Mind the gap warning next to railroad tracks.

Be aware of the talent gap // flickr: cgpgrey

We won’t close the talent gap any time soon, but here are some suggestions for management:

  • Identify high-potential employees and support them in learning what they need.
  • Recognize that the best employers will get the best talent. If you are not a preferred employer, you may have a long road ahead.
  • Turnover is expensive. Do what you need to do to avoid it.

What’s needed is some really excellent training to start expanding the pipeline of qualified people.

Scriptorium job placement policy

Given the discussion about hiring and recruiting, it seems wise to include a note about our job placement policy.

As consultants, we have unique access to staff across a variety of companies. The tight market is leading to a lot of inquiries about job opportunities. To avoid conflicts of interest, we have a few simple rules:

  1. We do not poach staff from customers.
  2. We do not recruit staff from one customer to another customer.
  3. As long as there is no conflict with these first two items, we provide informal matchmaking assistance to our customers looking for candidates and to individuals seeking new positions. We do not charge for these services.

Are you facing a talent deficit? What’s your plan to address it?

Speaking of talent issues, I give you this gratuitous video:

XML overview for executives

January 20, 2015 by

Over the past year or two, our typical XML customer has changed. Until recently, most XML publishing efforts were driven by marketing communications, technical publications, or IT, usually by a technical expert. But today’s customer is much more likely to be an executive who understands the potential business benefits of XML publishing but not the technical details. This article provides an XML overview for executives. What do you need to know before you decide to lead your organization into an XML world?

1. What is the actual problem?

What is the problem that you are solving? The answer is not “we want XML.” Why do you want XML? Are there other ways of solving the business problem? Make sure that the organization has a solid content strategy. At a minimum, the strategy document should include the following:

  • Business goals
  • A description of how the content strategy will achieve the business goals
  • High-level plan: resources, timelines, and budget
  • ROI

2. Technology is the easiest part.

As with most projects, early tool selection is appealing. It’s a concrete task, there are lots of choices, and choosing a content management system or an XML authoring tool feels like progress. Unfortunately, choosing tools too early can lead to problems downstream, when you discover that your selected toolset can’t actually meet your requirements.

Before tool selection, you should have the following:

  • A general idea of how all the moving pieces and parts will be connected (systems architecture overview)
  • Estimate of business benefits, such as $100K in yearly cost savings or faster time to global markets (four months instead of eight months)
  • A list of constraints (required/rejected operating systems, SaaS or not?, language support requirements)

3. Separation of content and formatting

You’ve probably heard this one. Storing content in XML makes it possible to deliver multiple output formats, such as HTML and PDF, from a single set of source files. This statement is true, but it glosses over a lot of hard work. Many designers are not prepared to let go of their preferred tools for building web sites or printed documents. When you separate content and formatting, you remove the designer’s ability to “tweak” their layouts. The transition from a hand-crafted page (web or print) to automatically generated pages is challenging. For some document types, the final polish you get from manual layout may not be optional. In this case, you have to think hard about what value you get from XML. You can also consider a middle ground, in which you publish into an intermediate format, do some final cleaning up, and then render the final version.

Separation of content and formatting provides for complete automation and huge cost savings, but it is not the right choice for all document types.

4. What is your organization’s capacity for change?

The best solution is the one that your organization can master. Make sure that you assess the following before making any permanent decisions:

  • Corporate culture: Is the organization typically risk-averse? Is it an early or late adopter?
  • Change management: How do employees handle change? How is change communicated? Is change resistance a common concern?
  • Leadership: Does your organization have leaders who can manage change?
  • Technical expertise: Is the solution a good fit for the technical expertise of the staff? If not, what is the plan to address this issue?
  • Executive leadership: Will executive management support this change?
  • Risk mitigation: What are the risks? What is the risk mitigation plan?

 

Beneath the page: learning to see structure

January 6, 2015 by

We hear a lot about the learning curve for structured authoring, but what does that really mean?


Experienced knitters learn to read the work—they can look at a knitted object and map the knitted version to a written or charted pattern. This skill is extremely helpful in locating pattern mistakes. Beginning knitters usually can’t step outside their immediate concerns of needles, yarn, and unfamiliar motions.

Spotting a dropped stitch is easier for experienced knitters.

Reading the work // flickr: kibbles_bits

Similarly, listening to kids talk about video games is enlightening. They dissect the game, discuss the way a particular challenge is constructed, and argue about whether the various enemies are too easy or too hard. They also have an eye for game mechanics and game flow. More casual gamers (me) struggle just to figure out how to make the sword work.

Bloom’s (revised) taxonomy provides a general framework for cognitive learning:

  • Remember
  • Understand
  • Apply
  • Analyze
  • Evaluate
  • Create

You have to master the basics (remember, understand, and apply) before you can move up to the more sophisticated levels. For knitters, the analysis level is the ability to read the work. (Designing patterns is the “create” level.)

For structured content, we have a similar set of learning requirements:

  • Remember—learn basic ideas, such as elements, attributes, and hierarchy.
  • Understand—comprehend structured authoring concepts.
  • Apply—use elements and attributes as needed.
  • Analyze—look at a page (print or web) and understand how that page is constructed with elements and metadata.
  • Evaluate—assess whether a page is structured properly or develop best practices for using an existing tag set with unstructured content.
  • Create—develop your own set of elements and attributes to describe content (information architecture).

And here is the crux of the structured authoring challenge:

Structured documents require authors to gain a deeper understanding of their documents than unstructured documents. This is true even if the editing software hides elements and attributes from the author.

Just as moving from a typewriter to a word processor required additional skills, moving from a word processor to a structured document requires new skills. The software will get better and easier over time, but the cognitive leap required is permanent.

Celebrating the good stuff (Blog Secret Santa)

December 24, 2014 by

Or: A stranger takes over the Scriptorium blog and gets all enthusiastic about tone of voice
Merry Christmas, Scriptorium readers. And, Sarah O’Keefe, an especially Merry Christmas to you. I’m your writer, Santa, and this is your Blog Secret Santa gift. (Everyone else: yep, hi. I’m a random stranger writing for Sarah’s blog. Because Christmas is fun.)

And here’s your present: Four websites that perform the rare magic trick of taking things that are normally really boring and making them entertaining.

How do they do this? With quality content, of course (whatever that means). Behind that, though, these four sites are all absolute masters of ‘tone of voice’. They bubble with the enthusiasm of the person behind the keyboard.

Perhaps, Sarah, your gift might actually be many hours of enjoyable reading about things like science, philosophy and cooking. Especially if you don’t mind rude words. While assembling this list I’ve discovered a personal bias towards writers who swear like sailors. Who knew?

Anyway, on we go with Santa’s Celebration Of Wonderful Tone Of Voice (Potty-mouthed Internet Edition). In alphabetical order, we salute:

1. Myths Retold

Some guy called Ovid is behind this one. He takes myths from cultures all over the world and, as promised in the blog name, retells them. His style is a mix of epic poetry and long-winded stand-up comedy. Somehow, it works.

Every now and then the ‘mythology’ ends up being an old book, too. Like the fantastic Doctor Jekyll and Mister Hyde is Really About Meth:

And for a while, shit goes back to normal

Jekyll invites everyone over for dinner parties and it’s great

but then all of a sudden he stops having parties of any kind

and in London at this time that is a SERIOUS PROBLEM

so Utterson keeps trying to go hang out

but Jekyll just keeps being like NOPE STAY AWAY

until finally Utterson gives up and is like “Welp

I guess that’s why my momma always told me never to make friends with crazy people.”

Without this site, I would never have made it to the end of Jekyll and Hyde. I don’t know if you’ve noticed this or not, but a lot of the classics are seriously boring.

2. Philosophy Bro

The most impressive thing about Philosophy Bro—possibly the finest of the internet’s many, many bros—is that he really, really knows his stuff. If you took out the foul language and streetish slang, you’d have genuine philosophical essays, and accurate summaries of many of the world’s most important philosophical works. But then again, if you took out the foul language and streetish slang, no-one would want to read it. Here’s a cut from John Locke’s ‘Second Treatise on Government’: A summary:

That’s the foundation of property – bros worked their goddamn asses off to make shit, so they had the right to that shit. An apple on a tree that no one owns is f&%$#*g useless – some bro had to pick it to eat it. Who are you to tell him he can’t eat an apple that he worked for? Yeah, I have no problem with them telling you to keep the f&@k out. Sorry I’m not sorry.

I like to think that this is actually John Locke’s first draft, and that he had a very patient editor.

3. Thug Kitchen

Ok, so with this thug‘s vocabulary he’s going to wear out his M and F keys pretty soon, but sometimes it takes a lot to get noticed. And I’m not going to get offended by the only person in the world who can make vegan cooking both hilarious and attractive. That’s right: I just said “vegan” and “hilarious” in the same sentence. You don’t get that every Christmas.

Here’s a quick, slightly-cleaned-up taster that shows you how to make people read about soy-based nonsense in between slices of bread:

WHAT THE F#@% DID YOU EAT FOR LUNCH? If it wasn’t a summer tempah sammie, take the afternoon off and re-evaluate some shit.

I discovered Thug Kitchen when the love of my life did too much yoga and got weird about food. As that spun out into a literal unhealthy obsession, I started getting pretty mad at websites that recommended cutting all sorts of stuff out of your diet for no reason. But I could never get angry at Thug Kitchen.

4. What if? (xkcd)

If you don’t already read xkcd cartoons, you’re missing out. Or you’re not a nerd. Or both. Anyway, Randall Munroe, the ex-NASA scientist behind xkcd, takes reader questions and answers them on What If? The trick is that he’s smart enough to make his answers to crazy questions sound both sciency and plausible. Like when he was asked how long humanity would survive a robot apocalypse.

What people don’t appreciate, when they picture Terminator-style automatons striding triumphantly across a mountain of human skulls, is how hard it is to keep your footing on something as unstable as a mountain of human skulls. Most humans probably couldn’t manage it, and they’ve had a lifetime of practice at walking without falling over.

I should award extra tone of voice kudos here, because unlike the first 3 sites, What If works its magic without a bunch of swearing. And that’s probably good.

So there you go. Science can be interesting. Mythology can be fun. Philosophy can be readable, and vegan cooking doesn’t have to be an over-earnest snore-fest. All it takes is something to make the content sparkle, like a perfectly worked tone of voice. If you’re struggling for traffic, you might have just found your 2015 New Year’s resolution: Sound like someone who loves what you’re writing about. Sound like yourself.

Merry Christmas!

Content strategy and relocation: the trauma is the same

December 1, 2014 by

We moved into a new office at the end of October. The new space is bigger and nicer than the old space, but nonetheless, the moving process was painful. As a child, I moved several times and changed schools every two or three years. I then landed in North Carolina for college and stayed put. It occurs to me that a new content strategy introduces much of the same pain as relocation.

Motive matters

Pickford's moving van

Content strategy and relocation: Not very much fun // flickr: markhillary

When you relocate or change your approach to content, the reason matters. Did you choose to move for an amazing job opportunity or spiffy new features? Were you forced to abandon your old content creation system by factors beyond your control? Did you seize the opportunity to change things? Were you involved in the decision, or was it imposed by others? Did you carefully select your new residence, or did you have to move to an undesirable location because of factors beyond your control? Did you plan your move carefully, or did you have to move on short notice? Do you consider yourself a starry-eyed immigrant to a new system or a refugee who would like someday to return to your true home?

Your opinion will be affected by your motive.

Learning a new culture

Moving, especially across national boundaries, causes culture shock. You expect big changes, such as different languages, customs, and food. But culture shock is usually caused by small things–the complete unavailability of a specific favorite food, the slight differences in how traffic lights work, the presence of near-ubiquitous connectivity (points to US), or the presence of useful public transit (all the points to Europe).

On the content side, we find similar culture shock. Typically, it falls in these categories:

  • Easy things that are hard or impossible in the new world.
  • New features that go unused because they were hard or impossible in the old world (so avoiding them is ingrained behavior).
  • Difficulty understanding the basic premise of how things work. For example, spending lots of time tracking content status in a spreadsheet instead of letting the shiny new content management system do the reporting for you.
  • Content development problems; for example, a shift from writing exclusively for print to writing for print and online media. This is a tough transition.
Learning a new culture is hard work, and it takes time. Training and education help, but exploring something in a controlled setting is quite different from living it. People need time to live into their new content systems.

Learning what’s really important

To make a successful transition, you need to understand what’s really important. Delivering great content is more important than getting to use Your Favorite Familiar Tool. Great writing skills will transcend the environment.

Before the office move, we had certain expectations for how the space would be used. In particular, we have both a conference room and an open meeting area. We expected to conduct most meetings in the conference room. But instead, the open meeting area is getting all the usage. As a result, we are rethinking our furniture in that space. Is it bad that we have a huge conference room that’s barely getting used?

When you change content processes, people will surprise you with creative solutions that are not part of the plan. It’s quite likely that some of their ideas will be better than what you had in mind, so figure out what matters (productive meetings) and what doesn’t matter (the location).

 

When we moved, we allowed ourselves at least six months to feel comfortable in the new location. For content strategy changes, expect a similar transition period.

Content strategy: first steps (premium)

November 24, 2014 by

Content: You’re doing it wrong. That’s easy for me to say—we rarely hear from people who are happy with their content. But are you ready for a major transformation effort? Our approach is to assess the overall content lifecycle, meet with all the stakeholders, identify needs, develop a strategy, and then execute the strategy. If you want a more incremental approach, consider these inexpensive first steps.

Delivery formats

Newborn fawn

Baby steps // flickr: slopjop

Are you delivering content in the format that your readers want and need? Are there delivery mechanisms that would better meet their needs? Can you implement new formats in your existing toolchain?

Many of our clients are delivering content in PDF only. A move toward HTML and especially mobile-friendly HTML can be a good first step in improving the situation for readers.

Streamlining print publishing processes

Most print-heavy environments can benefit from improvement in the print production processes. Look for opportunities in the following main areas:

  • Templates.
    Are you using templates efficiently? Your print production tool should, at a bare minimum, provide page templates and paragraph templates. Many tools go further with inline styles, table styles, object styles, and more. Building out a template that supplies correct formatting and teaching everyone to use the template can save hours and hours of production time.
  • Appearance versus reusability.
    Be careful about print-specific tweaks that damage the usability of your content in other formats. The canonical example of this is hyphenation. When reading a book on my e-reader, I often encounter words that have hyphens in the middle of a line, like this:

    Why is there a hy-phen here??

    The hyphen was almost certainly inserted into the original document to improve the line breaks in the printed document. A better solution is to use a discretionary hyphen (better print publishing programs support them). Discretionary hyphens are displayed only when a word needs to be hyphenated (occurs near the end of a line). Random hyphens scattered through the ebook are artifacts of a print-centric process.

    The content creation process needs to address appearance requirements and reusability across different formats.

Appropriate content

Are you providing the content that your readers need? You can explore this question by reviewing web analytics (if you have web content) and by examining the technical support situation. Does the tech support organization have a list of frequent problem topics? Is tech support creating additional content to address deficiencies in the technical content?

Accommodating translation requirements

If your content is translated, you can greatly improve the translation/localization process with some simple fixes to the source content. (Bill Swallow has a great article on five localization problems.) Start thinking about the following:

  • Consistent wording
  • Template-based formatting
  • Use of culturally neutral graphics
  • Technical quality of files (how are files assembled? Are language layers separate from images?)

All of these steps will improve your content without a requirement for a major strategic initiative.

Here are some things you probably cannot do without a big project (and maybe help from Scriptorium):

  • Implement intelligent content
  • Build out sophisticated reuse with metadata and a formal taxonomy
  • Reassess your tools/technologies and overall workflow
  • Get buy-in across the organization for a major content initiative

Adapting content for the U.S. market (presentation summary)

November 17, 2014 by

In this presentation delivered at tcworld 2014 in Stuttgart, Alan Pringle and Sarah O’Keefe discuss several factors that are required to adapt content for the US market. This presentation is especially relevant for European companies that want to enter the US market.

Language

The primary language of the United States is English. For business-to-business sales, use of British English might be good enough, but consumer products typically need U.S. English. The more personal the product, the more important it is to get the nuances of culture and language exactly right. Cell phones, for example, are very personal whereas accounting software used in an office is less personal.

In addition to English, it’s important to take into account the other languages spoken in the U.S. Approximately 60 million people in the U.S. speak Spanish at home, and half of them don’t speak much English. (Source: slate.com article with lots of fascinating language maps)

Culture references

Be very careful with culture references. The people and concepts that are immediately familiar in one culture are often unknown in a different culture. Even within a single country, there can be vast cultural differences–New York City residents have very little in common with Flagstaff, Arizona residents.

Regulatory requirements and legal issues

The U.S. regulates content for a few industries, such as aerospace, nuclear power, and medical devices. The regulatory framework in the European Union is much stronger. In the U.S., product defects and product liability are mainly handled through the legal system. Providing content with extensive warnings and cautions is often a defensive legal strategy rather than an attempt to deliver useful information.

The content standards that are commonly used in Germany are unknown in the U.S.

Audience

In an industrial setting in Germany, content providers can assume a certain level of training and/or certification. Germany has a strong apprenticeship program and vocational training. In the U.S., it is very common to have only minimal training in an industrial setting. It may be necessary to provide basic information in the U.S. content that is omitted for the better-trained German audience.

The audience for a U.S. product is likely to be more diverse than a European audience. Expect much wider variance in experience levels, language skills, literacy, education, and training.

Customer experience

A renewed focus on customer experience in the U.S. has led to the following assumptions:

  • Technical content is not just post-sales content. Around 80% of U.S. customers research products before buying them, and their research often includes technical information. Therefore, technical content can drive (or hinder) sales.
  • Repeat business is contingent on customer satisfaction. If the technical content delivered with the product is not of high quality, customers may think twice before buying again.
  • The line between marketing content and technical content is blurring.

    Customer support

    Technical content is often used in customer support. Consider the needs of the support organization in building out the technical content.