Part 2: Applied Content Strategy: How DJing a House Party Taught Me How My Brain Works [NF0]

Lessons and big-a** failures

In my last post I walked through the challenge of curating content (digital music) on a tight schedule. I responded by developing a content strategy with a taxonomy and system of ‘likes’, to build up useful metrics and deliver accordingly.

My content strategy worked a treat, until cops shut us down.

Here are are the rough-patches along the way, and the wider CS lessons learned.

People Don’t Like What They Ask For

Curation is a skill. Think about WIKIs. Without a strong curator/strategist keeping things going you often get content soup, and even the people who created it don’t like it.

Deliver according to the metrics! Many organisations I’ve seen have released this or that content on a hunch, or because this or that manager used their weight to push it through.  The result is never as good as when a combination metrics and good content professionals are used.

In my applied content science experiment, I used my DJing taxonomy and generally stuck with my model of how the content should be structured. However, later in the evening, I started opening up user-generated content, aka, straight-up “requests”. It was ok at first, but soon the users started taking over and crowding out the curated content. Result – they hated it.

Individuals may have liked this or that song, but when the structure and coherency of the taxonomy was gone, the genres started mixing and content that wasn’t high quality started surfacing to the whole user group. So, I learned giving people exactly what they wanted can create a mess.

Structure and control feedback channels

Organisations sometimes take on more channels than they’re actually ready for, without a strong underlying strategy and plan. The result is a lot of messy conversations where the content and its provider end up looking worse for their half-assed presence.

When I stopped using my taxonomy board and let the users submit directly, feedback become overwhelming and, worse, contradictory.

Planning for reuse is fun and effective

When planning content, whether content marketing or technical manuals, structuring for modules and reusable assets as early as possible can get you more bang for your buck.  We often forget the simple idea that a bit more up-front work in your writing and structuring will smooth later leveraging of assets later.

When I came up with my approach for the party, blogging the outcome was always in the back of my mind. In the true spirit of designing reusable assets, I crowd-sourced not only the evening's content list and structure, but got them to actually be the assets so I could hopefully teach a fun lesson later on my blog. 

After the party, I realised I didn’t have a DJ Facebook page, and of course the assets I’d created for the blog could be reused in a new, previously unconsidered context. This is living the dream of content reuse.

This was all happening with the Content Strategy Google Groups discussion “To Tech Or Not To Tech” going on in the background (related discussions in LinkedIn and Google+) where we were discussing how much CSs can or should relate with the deeper, more ‘technical’ aspects of what we do.  My believe is we can and should, we have to discuss such things in a way people can relate to.  And serve cocktails.

Proven again: the best tech is humanist

In all my workshops and classes I try to get people to approach new fangled techniques and technologies with from a “humanist” perspective. Thinking of ourselves first as people, then as users and technologists.

In my opinion, most of what a content professional needs to know about content technology is a simple 1-2 punch:

1. Make semantic meaning explicit: Make content structured and meaningful through explicit semantics and metadata (if you don’t know what this means, ask, as it was 3 chapters in the book).  This structure and meaning makes it so that computers can understand content in a way that’s more similar to the way people do.
2. Design experiences leveraging semantics: When computers can understand it more, they can create meaningful and engaging experiences with the content downstream. 

When I teach semantics, structure, XML, adaptive content, and DITA, I try to explain them not as new things, but as the common interchange languages between humans and systems. Life is structured and semantic, and our brains operate naturally in taxonomies, building relationships and narrative on top of them. They exist in the digital realm because they mimic our natural understanding of the world.

When I explain content technology from the human-centric perspective, I get a lot further than a decade ago when I started off lessons with “XML and HTML are based on their predecessor language: SGML…”. Snore!!

…For example, taxonomic metadata is innately human

We don’t remember every song we hear and tuck it away for instant recall (if only!).  We group by genre, speed, rhythm, culture of origin, etc.. We explore them in our minds by traversing the indices. It’s not a skill.  We don’t have to think consciously “I’ll store this in my brain under ‘Easy Listening’,” that’s just how we work. (Remind me to curate some links to TED talks about this!)

Think of when you when you can’t quite remember a song.  What do you remember? Some of the content, like melody or snippets of lyrics.  But aren’t you always able to rattle off something like this?

“It’s a medium-fast song, dance-y, with a sort jazz feeling, and there’s a guitar part that’s quite rock-y and then the guy goes ‘Riiings! Pearls!’.  It’s a rock classic, man!”

So we have just referenced the categories in your internal taxonomy:

• Mid-tempo songs
• Dance
• Jazz
• Guitar music
• Rock
• Classic rock
• Male singers

And ta-dah!  Led Zeppelin's “How Many More Times”.  Implement this in computer code and ta-dah: Last.FM, Pandora.com, Spotify! These are systems that use taxonomy to tell you music you like before you knew you liked it!

Note – it’s often easier to remember things by their taxonomical categorisation than something in the content, like, say the lyrics, or the f***ing title itself!

Amazon.com: always leading the taxonomy pack

On the same point, just last week I was considering a recent purchase. I thought, “I bought an Xbox Kinect on Amazon and it’s going to arrive soon. What games can I get now?” I had opened up the “Kinect" part of a product taxonomy – a category of games that previously I’d closed my mind to – and was starting to explore it. Amazon, in their taxonomy-driven brilliance, emailed me just this morning with the subject line, “Amazon.co.uk recommends "Kinect Sports: Ultimate Collection”.  Awesome.

More?

I’m hungry for more examples of this "real-life" content strategy applied, so please do submit yours in the comments!

PS – For Those Whole Like Sound Tech …

This bit is just for those who care what hardware and software I was using.

I was spinning Mp3s in open-source Mixxx. It’s good, but not great, and I think 20k songs was too much for it as after a few sessions my database file died and I needed to re-index everything.

I was running the whole lot through a Yamaha home hifi amp (RX-V795RDS) 5 x 125 watts RMS to 2 channels 8ohms, running both A and B outs to 4 speakers (didn’t use the surround outs).

I supplemented that with a 200w, 10-inch Klipsch subwoofer and was running out to Tannoy Reveal monitors (crappy as studio monitors, decent as speakers).

The interesting bit I think was that I was running 3 sound cards. One was the one built into my (kinda crappy) Asus laptop and two USB soundcards (both by Creative) to run separate outs to my cue mix and mains. Worked great!

Part 1: Applied Content Strategy: How I DJed a House Party [NF0]

This one is a bit of thought-provoking fun; an applied content science experiment. The question: can you apply primarily digital content concepts in day-to-day physical life?  I tried to get an uninitiated crowd to help me curate some content in near real-time, by setting up a taxonomy and system of "physical likes".  To put it another way, I crowd-sourced my way through DJing a house party.

It turns out you can use content concepts directly in real life, but people might call the cops.

I present you a case study in traditional form:

Part 1:

• The business context
• The content strategy
• Implementation
• Conclusion, results and take-aways

Part 2: How DJing A House Party Taught Me How My Brain Works

• Lessons and Big-a** failures

The business context

I have a sort of fetish for my work. I love it. My network will have noticed that I get caught up in the whole international whirlwind of it. But, Noz loves to party too. In one of my various previous lives I used to DJ house parties, private functions, and the occasional club that could be tricked into having me. I haven't done so in years, and never in Spain, so when I landed a sweet gig last week at a penthouse pad DJing for a mixed-age (mainly 20s-40s) crowd, I had a bit of a problem. 

It was a highly international crowd of about 100 strong, from at least some 15 countries - NATO and UN staff, international students and au pairs, and locals of Valencia, Spain (where I live). They had come for a BBQ, one in a series of about 5 so far this year, but I was supposed to get the dance-floor really moving for the first time.  What content should I deliver? I'd only worked in Toronto, Canada, as a kid, DJing for other kids my age, over a decade ago!

The business goal: be ready in 24 hours and keep ‘em rocking for the whole BBQ.

The content strategy

I decided to apply my professional methodology to this problem. After all, a DJ is really just a (digital) content curation and delivery system.  What would I tell a client to do if they were in a pinch like this? Start with the basics:

Inventory and audit

What do you have and what good is it?  This was the easy bit.

All my assets were 100% reusable and high quality (Mp3s), and I had LOADS.  Too many in fact as 20,000 songs is a lot to choose from…

How do you filter all that and deliver the right “stories” to a mixed, largely unknown audience?  Well, if you’ve got no metrics (and no time) you’ve got to:

1. Crowd-source some meaningful metrics, and fast!
2. Set up a manageable, user-driven curation and delivery system according to what the metrics tell you.
3. Keep iterating, monitoring success closely. 

Taxonomy

I needed a framework to work against to build these stories, so I built a genre taxonomy the day before. After much thought, I eventually settled on this:

• Pop
  • Old
  • New
• Funk
• RnB
• Hip Hop
• Soul
• Rock
  • General Rock
  • Classic Rock
  • Heavy Metal
• Dubstep/Drum & Bass
• House
  • Pop House
  • Funky House
  • Electro House
  • Hard House
• "Don't Care"

I took my taxonomy and put it on a large-format card in a sort of structured “tag-cloud”.

Light and happy genres on the left; dark and aggressive music on the right.  More electronic music across the bottom. “Don’t care” was in the middle (In Spanish: “Me da igual”):

^{Please no freaking out at me about this taxonomy. I’m sure yours would be different!} 

A DJ (or at least a good one, in my opinion) thinks this way. You have taxonomy in your head, and you build up content sequences – little stories – from your assets, and you see how they go down. Feedback is as fast (faster, even) than it is online, so you can dynamically adapt, but you’ve got to have a framework to work against. Be too fast and ready to react outside of your framework, and things fall apart (which we’ll see later in Part two: “Big-a** failures” when things weren’t going so well…).

User interface for gathering metrics

I needed a system of “likes” – something that would allow people to give me metrics against the taxonomy, rather than pelting random requests at me (which is death, as we’ll see in Part 2).

Enter: stickers!

I grabbed a few sheets of little kid’s stickers from a corner store; the kind that kindergarten teachers would put on good finger-paintings. I thought these would make great analogue “like” buttons, and people could like the genres they wanted to hear.

^{Analogue “Like” buttons.}

User assistance content

I then needed some minimalist, multi-lingual help content that would allow zero ramp-up time and prevent calls to the support desk (me).

I wrote a sentence once in English: “Take a sticker and put it near your genre” and then crowd-sourced translations from the early BBQ arrivals into the 3 next most popular languages of the target audience (Spanish, German, & French):

^{The shortest user manual I’ve ever worked on. Yes, would have been better to say “…put it near your preferred genre”, but I was working to keep it short. The other languages translate long and I had limited page real-estate, crowd-sourced content and limited resource (paper) for re-writes.}

Technology

Here I am with the final set-up (user manual got cropped out on the right unfortunately).

(I’ll actually talk software and hardware as a post-script for the music tech fans.)

Implementation

Taxonomy becomes folksonomy

After only a few minutes people started voting for their genres.  The table attracted attention and the sign worked. 

I had left out my pen on the table, and without meaning to be, my taxonomy suddenly became an Amazon.com-like taxonomy/folksonomy.  People actually added the genres “reggae”, “electro latino”, “indie rock” and “world music”, before I took the pen away to avoid overload.

^{Data collection begins}

What blew my mind was not that they voted, but how enthusiastically they engaged with the process. They LOVED it.  Several were actually taking pictures of the system and themselves using it (presumably for Facebook purposes).

The users, sorry, the guests engaged so completely with the like system that it took on a life of its own – it went viral!  People started to “like” themselves and each other – on the head:

 

 

Metrics

So within an hour I had metrics from which I could make strategic decisions about how to present my content assets.  This data would also guide future spending on new content acquisition. 

Conclusion, Results and Take-Aways

So, most important, did taxonomy-driven crowd-sourcing rock the house?  This video condenses my view down to 80 seconds:

My point of view throughout the event condensed to 80 seconds.

In short: business goal achieved.  The police visit was acceptable tactical losses….

I even had two solicitations for new projects – an opening of a lounge bar downtown and a wedding.

The Moral of the Story

The real point of this post is to demonstrate that content concepts work best when they are natural to us. People today have internalised the ideas of social voting and ranking ("likes") and crowd sourcing. Still, this probably would have worked 20 years ago, because these concepts are intuitively democratic and social.

In part two I look at how taxonomy is natural reflections of our basic models of thought and memory, but for now I’ll just say: 

Good content concepts seamlessly integrate with user instincts and behaviours, they don't jar them.

Many technologies have achieved success by removing barriers to entry - they make technology more like working without technology. Wii, Xbox Kinect; Bluetooth earpieces; swipe, pinch and shake on your mobile phone; are all trying to make interfaces disappear and just work with your body and natural instincts.

Augmented reality; wearable tech and more will follow this trend in years to come to make sure that technology gets more and more seamlessly integrated into our lives to the point where we don't know it's there.  For me this party was the content equivalent.

In Part 2 we’ll look at some wider conclusions and Content Strategy implications of this little story that lead us to the nature of our brains, Spotify, Pandora, and the Almighty Taxonomists: Amazon.com.

Part 2: How DJing A House Party Taught Me How My Brain Works

• Lessons and Big-a** failures
  • People don’t like what they ask for
  • Structure and control feedback channels
  • Planning for reuse is fun and effective
  • Proven again: the best tech is humanist
  • Taxonomic metadata is innately human
  • Amazon.com: always leading the taxonomy pack
  • PS – For Those Whole Like Sound Tech …

Check it out.

Have You Done Real-World CS?

Has anyone else applied their work concepts to daily life? I’d love to hear other stories.

2013-06-06 Update: PS – Music-Linked Taxonomy

Just for fun, here’s my taxonomy again with linked song examples of each!

• Pop
  • Old
  • New
• Funk
• RnB
• Hip Hop
• Soul
• Rock
  • General Rock
  • Classic Rock
  • Heavy Metal
• Dubstep/Drum & Bass
• House
  • Pop House
  • Funky House
  • Electro House
  • Hard House
• "Don't Care"

To Tech or Not to Tech, That is the Question [NF1]

Should a content strategist know code? How much geek cred is good for your career? When is it too much?  People have a love-hate relationship with technology even in our industry. Here’s my thoughts on how technical a Content Strategist should be. Some of you may be surprised. 

This post was born of a Google Forums Content Strategy discussion (and similar on LinkedIn and Google+) addressing these concepts and sort of got away from me.  Now it’s blog-length and I think an interesting topic.  I struggle with the borderlands between technical and strategic regularly.  I’m especially aware of it in the run up to Content Agility for example as it’s somewhere where Content Strategists, Technical Communicators and Structured CCMS people all get together.  Some think it’s a tech fest because there’s any mention of XML and DITA; others see a separate Content Strategy track and think it’s not for them if they are technical authors. It’s all content, and these worlds are blurring more every day as content delivery becomes more complex and users demand a more seamless experience. 

You don’t need to really know much tech at all to follow this post.

Disclaimer

I used to code in my early 20s.  I haven't written anything in many years and have no real intention of doing so.  This post says why. BUT if you were looking for work and having 'php' on your resume got you the job, I have nothing but respect for that.  I'm talking big picture, long-term career-growth here, trying to look from a perspective external to our community.  In a perfect world, more knowledge would always be better. 

Not all content tech is equal

I think there's an important distinction between types of "technologies" that are relevant to CS work. 

I feel the two big groups are:

• Programming languages – used to make computer programs
• Mark-up languages – used to mark up content so that computer programs can make better use of it.

The distinction I always make is: Mark-up enables; Programs do.  (Jump to the Post-Script if you want/need further explanation).

Mark-up is a CS core skill

I think that a CS person needs to understand how their content can be better and more powerfully manipulated by programming languages, if they properly enable the process  with mark-up. I don't think a CS needs to be able to create the programmatic code themselves. You can get a programmer and explain to them what you want and why, and they will build it.  Explain the 'why' properly and they'll complain far less when realising the 'how'.  For example, if you can understand enough about XSLT to explain why it's better than Java, that will make your life much easier even if you're never going to write a line of either. 

Programming can be dangerous to your career

I think it's debatably important not to get into development because of the socio-political backlash in a typical project environment.  Programming is 'dirty knowledge'.  As I made the transition early in my career from techie to content strategist, I was vividly aware of this idea.  If managers and strategic folk got the sense I was too hands on in my knowledge of 'techie stuff', then my cred as a strategic person influencing organisational direction went down.  I was taught that understanding it is ok, doing is not. 

In this harsh light, regardless of what we say inside our community, those that employ us (if not directly then a level above or so) will often consider programming to be commoditized geek-stuff with a glass ceiling above those who partake.  This lack of interest/respect means that to keep your emphasis on the strategic side, it's my belief that it behooves you to keep programming at arm's length.  We can do it opportunistically, or as a sort of bonus when it adds expected value:  "Hey, I saved everyone a load of trouble with ____ and just threw together a macro/stylesheet."  Doing it as part of core deliverables makes you a developer of sorts, and could even get you with critical-path programming deliverables on a project plan if you’re not careful.  This is hard to balance against the main CS work as you’ll be one coder among others, but probably one of few, if not the only CS person.

In conclusion, understanding mark-up is vital to understanding what can be done with your content if properly tagged and architected. Making programming part of our brand I think confuses the strategic part of content strategy for others.  Many of whom don't understand the minutiae of what we do and our value-add in the first place. 

My possibly jaded - and not-intended to offend anyone who (quite rightly) takes well-deserved pride in their hard-earned techie skills - two cents. 

Post Script – Tech disambiguation

For your interest, here is my explanation of the difference between mark-up and programming languages.  We of course treated these in far greater depth in our book.

• Mark-up languages (HTML, XML, DITA, SGML, SVG, RDF....) are descriptive and semantic metadata that are bound intimately to content.  Mark-up languages exist to mark-up content. I think that the CS'er must understand mark-up languages.  Not just HTML, but the fundamentals that underpin HTML which come from it's SGML/XML roots.  That is structure and semantics.  They need to understand what the implications are of using mark-up to separate content and presentation (to this day it flabbergasts me how low the penetration of that concept is).  You aren't really 'coding' in my definition, even though you're adding 'codes' like <p class="bodyText"> to your content.
• Programming languages (C#, javascript, java, xslt, SQL...) are for manipulating data - might be content, but not always.   These are real coding languages and you need vastly different tools and, I think, different skills to master them.  Real manipulation, coding, debugging and app development and general magic happens here.

A marked-up file (HTML, DITA, XML) does nothing.  It just sits there in its DB or file system until an app picks it up and process it in some way.

Note: I left out CSS as a pure presentation language.  I think it's a very useful, nice-to-have but not a core skill. 

PPS: Come to Content Agility 2013!

Content Strategy Book Launched [NF0]

I am delighted to finally announce the publishing of my book – with my co-author Rahel Anne Bailie: Content Strategy: Connecting the dots between business, brand and benefits.

It has been two intense years of working a more than full time job and authoring in every moment I could scrape together.  Some may have noticed we renamed it from the pre-launch name to simply “Content Strategy”.

We’re much happier with the new title as it addresses content strategy in its full breadth and so is really the most appropriate.

Reviews and Excerpts

*UPDATES – Feb 2013*

We sold out of books at the Intelligent Content 2013 conference! Should have brought more stock!

In other news, two great new reviews for the book by prominent figures in our industry:

• “Book Review: Content Strategy by Bailie and Urbina” – James Mathewson, Editor in Chief, ibm.com & Global Search Strategy Lead, IBM
• “Bailie and Urbina ‘knock it out of the park’ with their new book” –  Kevin Nichols, Content Strategy Practice Owner, Sapient

Past Reviews and Excerpts

• Making the business case for content strategy – Excerpt on the Firehead Blog
• Review: Content Strategy – Larry Kunz, Project Manager and Information Architect, SDI
• Book Review – Bas Evers, (before the re-naming of the book)

Thanks to all who supported me and were involved on the journey. I hope my blog readers choose to pick up a copy and tell me your thoughts!

Have I missed a review?  Let me know in the comments!

As you can see on the site, copies are available from:

• Amazon Canada
• Amazon UK
• Amazon US
• Barnes & Noble
• XML Press

DITA and The Return of the Editorial Process [NF2]

Guest Post by Keith Schengili-Roberts

A note from Noz:

Hi-di-ho, Readerinos!
With the holiday season and some intense projects I’ve not posted in quite a while. In a way I’m still not, in that today’s post comes from my new colleague and peer in the DITA community Keith Schengili-Roberts. I did an interview post prior to the Congility conference on Keith’s well received ditawriter.com blog, and I asked Keith to reciprocate. The resulting post below was actually inspired by one of our discussions while working together on some recent client work.

Enjoy!

PS – Here’s a reminder of what “NF2” means, if you needed one.

-----------------------------

It used to be that editors were much more common in the technical writing business. I have been around long enough to remember people who had “Technical Editor” as their formal job title. Over the years economic and production pressures have forced firms to hire more writers instead of editors. This often results with little or no oversight of existing content, furthering the pressures to silo writers and their content. Content was created, reviewed, and delivered, and rarely looked at again unless a customer raised an issue against a specific piece of content.

When asked, one of the aspects of DITA that most technical writers will agree is important to them is the ability to reuse content. Not just their own, but content that was developed by other writers. Whenever a piece of content is reused, it saves the writer that found it from having to re-write that piece of content. At the same time, the organisation benefits by saving cost, and the user benefits, because reused content makes for more consistent deliverables. I have noticed over the years that one of the other inadvertent bonuses of this approach is that topics that are looked at most – when being evaluated for reuse – become “edited topics” and are improved in the process of reuse. In DITA environments, I am seeing the return of the editorial process as technical writers review and inevitably revise content written by their peers.

Legacy Conversion Can Equal a First Edit Pass to Old Content

While working as an Information Architect I remember running across a classic case of this sort, where a writer had been doing the same manual for years, and took the approach of adding new material he received from the software developer SMEs piece-meal to the existing content. What must have at one time have been a decent manual had become a hodge-podge of barely-comprehensible content, with varying punctuation styles, and different terms (and spellings!) for the same items; inconsistency was the norm rather than the exception. Any editor glancing at this material would have immediately taken out their red pen and set to work (and in fact a section from this original work became a standard editing test for technical writer candidates looking for a job with the organisation).

Since things were so siloed nobody on the writing team had the opportunity to review this work, the hapless end-users had to decipher this deliverable as best they could. In moving this content to DITA the material finally had the chance to be thoroughly edited. Terms were made consistent and the content was cleaned up. Simply converting this legacy content to proper, topic-oriented and info-typed DITA ensured that it would be edited and made consistent, and its content ready to be effectively reused in other end-user content.

^{Image licensing - http://bit.ly/QL7K0Y}

Reused Content Becomes Improved Content

I have seen evidence of content being edited and refined over time, so it becomes more clear and consistent as more eyes are brought to bear on the original versions. I remember another occasion where I was reviewing some end-user content, and I twigged that what I was reading seemed awfully familiar. The CCMS we were using allowed me to locate the topic and discover where else it was being used. It turned out that it was a concept topic that I had originally written for a highly-technical electrical engineering document. I could tell that it had been changed, but ultimately for the better, so that it could work effectively in two very different deliverables intended for two distinct audiences.

As a consultant I am now seeing similar situations at other organisations. It seems to be a natural outcome of the topic writing process when handled within a CCMS with decent search capabilities. This type of behaviour should definitely be encouraged, not only because it is good for the content (and its readers) but because it is good for the writers in several ways.

I find that the better writers on a team are natural editors as well, and allowing them to sink their teeth into someone else’s content means that they get to learn more about that content (and other products/projects) and it also opens up the lines of communication within the team, as would-be-editors ask the original writers about their content, helping to de-silo both the writer and the editor.

^{Get it? Reuse means looking at content with a fine-toothed comb…}

Possible Pitfalls to Be Avoided

When managers see this type of behaviour it needs to be encouraged, but definitely guided. One of the obvious pitfalls when writers-cum-editors run rampant is that they revise material so that it fits their deliverable’s needs but not that of the original deliverable. As long as all of the writers are reminded of DITA best practices – that they need to check content dependencies and to talk to the original writer of the topic when changes go beyond mere grammar corrections/typos – this ought to solve this potential issue before it starts.

The other potential issue that can arise is that a writer may think they are being singled out by a peer and cause friction. There are few writers – myself included – who do not react with some shock when the red pen cuts deeply into their work. In this situation it is good to be able to point to an existing style guide (both for DITA mark-up and for writing generally) so that writer and editor know where they stand.

While many organisations will find it hard to create (or in some cases, reinstate) the technical editor role, having the editorial function emerge in the writing team is a natural outcome when you have good technical writers who are creating topics using a CMS. The best deliverables are those that have had several sets of critical eyes looking at them, and good editing makes for better writers overall.

It’s a win-win-win situation for the writers themselves, the readers of the content, and ultimately for the organisation.

-----------------------------

A note from Noz:

To formalise and drive forward the effect that Keith is discussing here, I have even gone so far as formally recommending to clients that they hire dedicated authors to coach and monitor writers. Which is the best way forward depends on the organisation and context, but the impact of reuse on editorial process is a positive trend in all cases.

To learn more about Keith, do check out his blog on ditawriter.com.

Why Can’t Content Professionals Communicate? [NF0]

It is ironic, as we’re all professional communicators of types, that we suffer so at the hands of our own labelling and terminology.

We are all responsible for creating, curating and disseminating content to support an overall strategy, yet we hold onto vertical, department, or (heaven forbid) technology and tool-specific communities as if our lives depended on it.

This isn’t a message just for web marketing folk or technical communicators, it’s for all content professionals.

Content Strategy is something that crosses departments and verticals and channels, because the business strategy isn’t divided up by department. You don’t have the product team saying “We’re going to develop for the home user” and the marketing team saying “We’re going to market into the B2B space!”.

Tech Comms is sometimes under product, sometimes under marketing.  Either way, they can’t be off on their own writing help or manuals thinking “So… we’ve defined our users as all being nurses who speak English as a second language”. 

We have to align content across agreed audience profiles and speak to them in a cohesive, brand-enhancing way. 

You would never want a web marketing team to say “We’re going to approach the under-25s with a hip and conversational messaging architecture” and the print team to say “We’re going after the over 40s with a professional and academic tone”.  Or, if you do, that’s bad business strategy.

To do content strategically, we have to talk to each other across the currently-held boundaries.

Images of Content Strategy

I’ve heard Content Strategy described in a breath-taking variety of ways (it’s almost as bad as ‘structured content’ or ‘XML’).

When Ann Rockley began using it in the first editions of “A Unified Content Strategy” (Second Edition features a case study by me by the way, so check me out with my bad self…) it was a holistic term, crossing silos and formats.   The term  didn’t really take hold of the popular imagination for a decade or so (real innovation takes time to bed in), and it first took hold in the web marketing world, so it looked like this:

 

Since then, we’ve been hearing more of an a collaborative message between the core externally-facing communications team, which I think looks like this (which is not too bad frankly!):

Finally, and most inspiring to me, truly ‘holistic’ content strategy doesn’t limit itself to departments or points in the content and customer lifecycle.  For example it doesn’t just look at external marketing messaging architecture and copy, but market-requirements documents and product strategy documentation which is internal.  Similarly, it isn’t about ‘technical communications’ in the sense of external docs, but any technical content on intranets, engineering specifications and so on inside the development process of product content:

I know few organisations will ever be this sophisticated, but it’s a nice idea… isn’t it?

Even if we get it, the customers don’t…

The message I get from most professionals is that this is a harsh business reality.  Their customers are only ready for the most basic and superficial interpretations of content strategy.  I think that that’s partly true and as professionals we have to try to educate the market while not going out of business talking about “beyond mobile” publishing with clients that resolutely can’t get their heads out of printed pages.

So although it feels like it took us years and years to get this far in the practioners communities, it’s going to be years more that we’re explaining it to the rest of industry to have the concept of content strategy – looking at a content as an asset that can help achieve strategic goals - sink in.

Please, someone disagree with me…!

PS - If you are a technical communicator, please check out David Farbey’s latest post on exactly this.  It’s no small thanks to David’s post that I was inspired to write this.

PPS – I know I often allude to my crushing project schedule, but right now is really bad. I shouldn’t even be blogging right now frankly but I couldn’t resist… so sorry if this was at all a garbled mess.  I think I need a content strategy and process for my blog… :)

Mobile is Just the Beginning – Part 3 [NF2]

Recap up to Part 3: Mobile is not “the new format for which we must be designing content strategies and content”.  Mobile is actually various formats* that need tackling.  Taking a short list of key ones we have:

• HTML
• Kindle
• eBook
• multimedia eBook
• PDF
• ePub

We should approach mobile delivery solutions such that they are stepping-stones to scalable, maintainable, multi-platform content strategies. 

The thesis of this three-part article is that we need to stop eating up articles debating “App or Mobile website: which is best for your customers?” and invest in getting ready for the real scary answer: you need to be ready for both, and many more formats, contexts and applications too.

*Thanks to Rahel Anne Bailie for pointing out that eye-opening link!

What you can do

Here is a list of high level content steps required (not in any order, and clearly only a starting guide) to tackle mobile “properly” (as I’ve defined it so far):

• Modularise: Design content that's clearly info-typed in a modular way. A module is  allows flexible recombination. High level types like ‘Article’, ‘User Guide’ ‘Report’, ‘Review’ and ‘Announcement’ are not granular enough to be split up and re-assembled. To tell new stories from existing assets, you need your assets to be sufficiently small components.  We call this ‘monolithic’
  
  I really like the way the Wall Street Journal page that Rachel Lovinger pointed me to that links small components about other movies into the main story flow (down right hand column “Films Mentioned In This Article”). The main story isn’t designed to be broken up in this case, but the side components are great examples of content that would slot into various other stories sites, or even print articles nicely.
  
  Also, think about the difference in reusability between a single, discrete FAQ or How-To vs procedural information that’s mixed up with some concepts and reference data in the flow of a larger deliverable.  You can’t extract it cleanly, so how can you reuse it?
  
• Enrich: Metadata is not optional anymore. To be able to sort, filter, and rebuild things with the help of automation, we need to look at making taxonomies, folksonomies, and structural metadata all work together.
  
  This is several blogs on its own, so for now, just know you need to know about it.
  
• Stop building into one format and converting: There are some print folks today who are still looking for a piece of software who allows them to take content that was created, laid out and conceived completely for print, press a button, and get a good mobile experience out of it.  It can’t happen.  It’s asking the question, "How can I hammer the square peg of my paradigm into the round hole of the market requirements? Must need a bigger hammer..."
  
  We need to design format-agnostic content as early as possible in the content lifecycle (I and many others recommend XML formats for this). Content is not deliverables. Deliverables encapsulate content for one context, time and format.
  
• Build a standard process for re-casting content into new “stories” (See part 2 for “stories”): Some XML helps you describe modules and maybe break content apart, but doesn't help you stitch stuff together with new relationships, new metadata/keywords, or new hierarchies for the diverse new scenarios. It's this standardising of both in a format-agnostic way that really makes it usable.
  
  Whatever way you mark up your content, you will need a standardised, agreed way that you can define the stories, not just add metadata to individual modules.  Why?  Because even if you’ve made content format-independent, if you only structure the modules and not whole navigation models and flows between modules – whole stories - then you’ve just locked yourself deeply into your current management tool.
  
  These stories are the way your content relates and interconnects is critical to it. Otherwise it’s just a ‘pile’ not a website or a publication.  That metadata is the intelligence that makes the content consumable.  If a big chunk of your content’s intelligence and structure is only described in the software that manages it (the CMS), not inside the content itself, changing software would mean extensive rebuilding of your content to just make it work like it did before and make any sense to anyone.

So, although some feel we can just refer to 'XML' or 'structure' because there's lots of options - HTML5, Dublin-core, or myriad others. I disagree. I think that not all format-neutral / metadata standards are created equal.  Without standardising on the story-telling, we’ve only got a portion of what’s really needed to deliver content.


• Realise that change is change: XML and structure aren't magic. There are complications and issues and ways to screw it up like anything else. Again, Rahel Anne Bailie talks about this a lot, and she and I are on the same wave-length: if users are still avoiding learning how to use Word styles or not thinking about content in a strategic, structured and process-oriented way, then XML will be harder to wrap their heads around.
  
  To thrive in an environment with this must change happening, we need to not fight to maintain the status quo but meet the challenge head-on.  We must find out how we can learn, partner, beg, borrow or steal the necessary capabilities to deliver solutions.
  
  

The Marketing Content Conundrum

A lot in the web content marketing world (a lot of content strategists) are concerned that single sourcing and structure are hard or even don’t work for marketing content.  I’ll wrap this up with a bit specifically for them as my techcomms readers will no doubt have been hearing about structure, reuse and XML for a good while by now.

I do agree that marketing overall is the hardest nut to crack. Everything else, including sales proposals or enterprise content, deals with more hard facts.

Marketing is the most "nuanced" of the content areas, but it's not impossible. The low-hanging fruit is the things that are small, structured, and/or repeatable - catalogues, brochures, small hand-outs and data-driven ads, emailers. I'd need some more specific examples to talk about the relative difficulty of each scenario, but the idea is that because some aspects of marcomm are still very difficult doesn't mean that marketing generally should ignore the trends.

The 'facts' areas of marketing are the easier ones to tackle. Feature lists, product overviews, offer conditions and details, disclaimers and media are the things that can get most easily reused into myriad deliverables. However, that's already lots!

Single sourcing is realistic, but a strategy for reuse needs to be tailored to the business context. It's just one more facet of your overall content strategy.

I’ve mentioned Ann Rockley a lot, probably because I’m in the middle of reading the Second Edition of the MEC, but also because she has had one of the most diverse backgrounds in structural publishing in the market including marketing solutions. She listed problems in this area as:

- Marketing sees marketing content as creative, but structure as restrictive. Structure appears to be a technical scary thing. Structure doesn’t have to be restrictive. I love what one of my clients said “Structure sets you free!” (Noz note: I’ve been saying that exact quote for years too. So true! You’re free with structure to focus on the content, with the machinery around it taken care of for you)

- Everyone is blinded by format. Everyone is so focused on how the content will “look” on the Web or on the page and there is a strong belief that content written for one format does not work well for another format. Not so, well written content designed to be modular works well in any format.

- Many see conversion as the answer to their problems. Conversion doesn’t work because the paradigm for print is different from web which is different from mobile. It should be content first, channel/device second.

Single sourcing, structure and reuse are applicable in all industries and as mobile kicks more of us into action, the skills and tools required will only become cheaper and easier to source.  Content professionals and contents strategist today need to get plugged in and linked up.

Learn More – Go To Events

For more on this, networking and conferences are great. For example:

• Lisa Moore from Writebyte is already organising a CS Meet-up in the UK at Adobe’s offices:

Our topic on the night will pick up on one of the main themes to emerge from [the] CS Applied conference: namely, how do we, as content strategists, help organisations plan for useful, usable content in a multichannel world?

We're going to talk about separating content from presentation, get a crash course in authoring and publishing standards (don't worry, until quite recently, I thought DITA was Marilyn Manson's ex-wife ;), and discuss the finer points of content structure.

Check out the EU CS Google Group for more.

• We’re also regularly doing webinars and live events over at Congility.com trying to bridge the technical communication and web content strategy worlds. 

Please do let me know in the comments where and how you’re seeing the format explosion impact your content strategies!

Mobile is Just the Beginning – Part 2 [NF1]

Continuing on from my previous post about the state of multiplatform content strategy, here are some reasons building “for mobile” can actually hurt your content’s long-term usefulness and some notes on how you can tell if you’re headed for trouble, and ideas on how we need to think differently in a multi-platform age.

Part 3 will look at more concrete actions to take and areas to consider when jumping to mobile content. 

But before taking any action, my meta-message for the series is for us to start seeing mobile not as a new format to move your content to, but to consider mobile as the motivator – the  opportunity in fact – to move your content out of the format churn and into format-neutral territory. 

Why Building Content “For Mobile” is Dangerous

As discussed in Part 1, mobile is a series of new presentation formats.  ePub, HTML5, the Kindle .mobi format, and the other mobile formats are all designed to describe to devices and applications how to display content.  The standards are built specifically for presentation, and specific platforms issues, not around designing the content for user’s actual needs and desires across formats and platforms.

If you build content strategies for format-based processes, you’ll always be playing catch-up as new formats come out.  This concept applies equally to web publishing, technical communications, traditional publishing. All have content that can get “locked-in”. The trap has many tell-tale signs, of which I’ve selected a tiny set of examples:

• You’ve got your print deliverable but it’s awful online or on small mobile format screens
• You’ve got your iPhone app but don’t have all your content ready to go in it
• You keep having to pay for expensive ‘Content migration’ initiatives and spend ages prioritising what gets converted and what doesn’t.
• You changed management platforms and now the content has all been flattened and disconnected – not even worth trying to move it…
• And so on… 
   

Telling New Stories

When content is locked in a single format or inflexible structure, it is very hard to break it apart and leverage it to tell new ‘stories’ for multiple contexts on multiple formats.  New formats are everywhere.  New stories could be a condensed how-to manual, a brochure, a microsite, a campaign, a ‘expert’s guide’ (that cuts out lots of fat that newbies need) and so on. New ‘contexts’ might be:

• I’m learning about a product… while on the bus to work (User
• We’re announcing a product in multiple geographies simultaneously (Brand)
• We’re / I’m evaluating a product for purchase (Could be User’s private consumer research in B2C, could be Corporate due diligence for B2B)
• I’m using a product right now (User or staff that works for the Brand)
• I’m answering questions about a product (Brand Staff, 3rd Party Partners/Trainers/Retailers, maybe even certain Users who are community experts/evangelists)

Each might require different arrangements or subsets of core content, or different relationships or ‘paths’ through the content.  How do you prepare your content to be ready to accurately appear in all these different ways, optimised for the device and context?

Slide from CSA Presentation: We can write for one flow, but if properly structured, different arrangements, navigation and deliverables should be able to be created easily, if not 100% automatically. 

If your content isn’t modular, you can only tag whole content objects (articles, posts, manuals, service bulletins), say for example relating them to a ‘high tech’ or an ‘iPad 3’ category, that’s great for making links between objects in category, but not very useful for helping you build a new deliverables from reusable bits inside those objects.

Sometimes a whole object is too big to be reused effectively. Sometimes you just want the company slogan, or a product overview, or a feature list, or one procedure among several on a “page”, and so on to tell a new story with it somewhere else, for someone else, on some other device.

CaaS: Content As a Service

To be able to move fluidly across formats we need to design content not with a deliverables mentality, but a service mentality.  Like Cloud Computing is computing services shared across a network or grid, like a utility grid, Content as a Service (CaaS) is a paradigm shift where reusable content assets are available to different applications that in turn deliver the actual consumables from wherever they are to wherever they need to be. 

Confused yet?

In blog form this is hard to get across, but it is not that it is that complicated, it’s that it’s simply different than the way we work today.  The technologies and methods have been in place for years, but we needed a certain series of events to bring us to today:

1. The printing press (seriously) to make mass publishing possible
2. The (social) web to make mass publishing available to the masses
3. Mobile to hit the masses on the web and drive them to go multi-platform

Once all three happened, we now have a critical mass of content, managed by a critical mass of people to make the situation, well… critical. 

The reassuring bit is that none of us have all the answers.  I can’t code a mobile app to save my life, or layout a page in InDesign.  We must work together. This is a message that me, Kristina Halvorson, Rahel Anne Bailie, Ann Rockley, Karen McGrane and more have all be quoting specifically.  Don’t be concerned if you can’t create, much less implement, an entire multi-platform content strategy by yourself.  Start pairing up with those who can, and let’s learn from each other.

We’ve still been covering conceptual material. In Part 3 we'll look at specific recommended tactics for approaching mobile-ready, multi-platform content strategy.

PS - Slides from CSA here: http://slidesha.re/resuable

Mobile is Just the Beginning – Part 1 [NF0]

I recently led three conference sessions in one week.  They were for two communities trying to move off two different types of “pages”. 

I did two sessions at Publishing Expo (generally very print-page oriented crowd) organised by Mekon, and then on the Friday at Content Strategy Applied (a very web-page oriented crowd) in the track headed up by Rahel Anne Bailie and hosted by the great folk at eBay and RLYL. 

It was a fascinating opportunity to compare and contrast the mentalities regarding publishing, and mobile of course was high on the topic list.

The ‘guts’ of this 3 part post are in Part 2 and Part 3, which detail the issue and how to approach resolving it, but I think Part 1 is important scene-setting.

Web enters Print’s Victim Support Group

By the Content Strategy Applied session at the end of the week, I was very comfortable dropping into my session the comment: Web's lull is over.

The process of communication enjoyed a 550+ year lull where we enjoyed unchallenged, single-format paradigm: the printed page.  Technology moves faster now, and the desktop-web-focused paradigm is now shifting with the introduction of mobile after only 10-ish years of real dominance. 

But we online publishers must now adapt exactly as print publishers before us did and, as they did, accept that a paradigm-shift, not format-change, is happening.  Interestingly, many print-oriented folk are still adapting to web, which shows just how long paradigm shifts can take.

Lily-pad Hopping: What’s the New Master Format?

My belief is that we have to be careful to not seek the new 'dominant' format.  I have heard some folks talking about mobile being the new thing (as if an iPad, Kindle, and blackberry were somehow just one thing).  Something along the lines of "We must now design our content for mobile and adapt back to desktop (and it goes without saying that print can take a hike)," but there's not a lot of detail supplied after that.

Mobile as we know it today is just the tip of the iceberg.  On the CS Google Group, Ann Rockley chimed in on this topic, fresh off her new release of the seminal Managing Enterprise Content: A Unified Content Strategy, she said:

The scary thing right now is that we are having a lot of device wars. Everyone is jockeying for ultimate supremacy. In some ways this is good because we get a lot of innovation, but in a lot of ways it is bad because we can’t just do one thing and expect it to work everywhere.

In my sessions I talked about all the various technology companies out there tripping over themselves trying to provide new, better, cheaper ways to interact with content.  Smart phones and tablets that seemed like science fiction in 2000 don’t even raise an eyebrow today.  It’s the responsibility of the contents strategist to think strategically for the brand.  That is, not for the course of a project lifecycle, but the life of the content and the brand.  We need to think long-term and act short term to prepare.

My favourite examples of the potential to come are the http://eink.com/rugged.html video where we see the same screen technology that is used in the Kindle get folded, hit, submerged, burnt, and more, and still keep on ticking (take that Timex), and Corning’s Day Made of Glass:

In short – content is REALLY going to become king.

When access becomes this ubiquitous, we’ll be designing content for a vast number of scenarios and contexts we’re not even thinking of today.

If we keep trying to find the new format or tool that is going to magic away our issues, we’re jumping to a lily-pad, waiting until it sinks under us and then desperately trying to time our jump to the next one.  Jump too early and you splash down in the water, jump too late and you sink and drown by simple inaction.

Side-Step the Format War

We must design for maximum agility (intelligence, nimble-ness, reusability, adaptability, etc) in the content itself so we can tackle X number of formats. 

This was the warning that the XML/structure folks were giving 20 years ago. XML folks said. "We'll be ready for whatever may come if we bite this bullet today."  It's those folks who transitioned their content AND their people a decade or more ago who are most ready to take on new formats now. 

They analysed their content models, built mark-up based, platform-agnostic ways of structuring and storing it, and proved their content was future-proofed, as promised. 

Now web needs to bite that same bullet.  Our customers don't want PDFs or websites or mobile apps, they want them all.

It’s not so bad

You may be suitably concerned by now, but it’s not all fire and brimstone.  Content folks should know that mark-up is the easiest bit. You learn some tags. Boom. Done. Most of us have a reasonable grip on HTML and many get CSS, even if we can't code CSS ourselves. It’s the other parts that are difficult and need collaborative, multi-disciplinary approaches

Writing reusable, info-typed modules and thinking format-free is harder than the mark-up. New editorial processes and managing things against a taxonomy is harder. Information modelling to decide how and when to use what tags is harder.

All content folks of various specialisms need to adapt to new format-neutral processes. There's challenges but by no means impossibilities. The world move from pen to typewriters to computers. In the 70s, executives couldn't type, and there was such a thing as a 'typing pool'. Now typing is not a specialist skill. People learned. They'll learn this too. The worms, however, will go to the early birds.

So What Do We Do?

The following parts of this post will discuss some more specific techniques and things to think about when going mobile-ready:

• Part 2: Why and more importantly how we must change our mindset for future-proof, mobile-ready content strategy.
• Part 3: Recommended tactics for approaching mobile-ready content strategy

Tech Comm 2.0 - Article Thoughts [NF0]

I just read (devoured) the new article by two ragingly clever and engaging personalities in the Content World: Jack Molisani and Scott Abel.  The article was entitled: Tech Comm 2.0: Reinventing our Relevance in the 2000s.

The central thesis is that Technical Communicators have to rethink and re-market themselves in the wake of overwhelming market changes if they want to thrive and survive.

 

The advice for is Tech Communicators / Tech Writers to stop envisioning themselves in these terms (you’re not valuable because you write words good n’ stuff) and expand their footprint into “professionals who solve business problems”.

 

Or as they put it:

 

To be successful, technical communication professionals must present themselves in a way that clearly describes the value they bring to organizations.

I think the article was good.  In fact, it reminds me very much of my own personal term war, not against the word “Writer”, but the word “document”.  I find “documentation” to be a passive and retrospective act.  It seems by definition to not be part of product development, but something that simply reflects – documents – the facts of the product in a text-based form.  That’s all sorts a’ awful. 

 

Scott and Jack even singled out my favourite pet hate, documents that say things like “Enter your name in the name field”.

 

Communication Spectrum

 

So although I’m sympathetic to the cause, my only criticism is that finishing it I felt the TC community was given instruction and impetus to act, and a helpful and reassuring catalogue of the tools with which to take action, but what they’re supposed to do wasn’t quite clear. 

 

In the "TC as a profession" section there was a list of jobs that are typical in product companies. Everything from Product Manager, Business Analyst and Product Architects to Marketers, Sales Reps and Tech Support.  All of which used skills that were listed as being similar to core technical communicator skills. 

 

In the "Lather, rinse, repeat" section, it almost seemed to me TCs should pick from the list of the jobs whichever they feel like and go be one of those instead of being TCs/TWs.  I know Scott and Jack and, as said, they’re both very clever.  I don’t think they’re saying TCs should go be Sales Reps or Dev engineers per se (but if you have those skills why not), so some differentiation and clarification at the end would have been good. 

 

The reason I’m blogging this particular article is put in my support, but also to highlight the difference between “most” (always dangerous to generalise") Tech Writers and the people who staff these other jobs. The difference is that most tech writers are strongest in written communication.  Tech Writers who can deliver strong live presentations, engaging training or a compelling sales pitch are more rare.

 

There’s a sort of skills spectrum between live, real-time and persuasive communications and supporting, asynchronous communication – some of us are really good live but can’t write, some are great on paper, but PowerPoint and a microphone are our worst enemies.  I think this distinction got left out of the article.

 

My own two cents here are that if you are a writer branching out, it’s good to try to establish where you are on that communication spectrum, and match yourself to the specialism that works best.  If you’re good with words, but need to rehearse and be well prepared to deliver them orally, you can probably do great video voice-overs or tutorial scripts or even write training material, but delivering training material or handling angry customers on tech support lines is probably not for you. 

 

I’m only adding some detail to the main message: know thyself.  That’s not limit thyself, but put your efforts into something that’s leveraging your core strengths. The idea that technical communicators need to specialise and market themselves differently is, for me, a no brainer.

 

If you haven’t already, read the article right now.

Footnote: Doc-to-Help

 

The first page of the article is a full-page ad for Doc-to-Help’s “multiplatform” solution.  I find the ad placement incredibly ironic. I'm assuming that was the publisher's decision (as opposed to the author’s or ComponentOne’s).

 

Scott and Jack are breaking it down as to why TCs need to think outside the box, get ready for really new scenarios and ways of operating, and Doc-to-Help are essentially saying, "Screw it! Just do the same ol' junk in Word and we'll automagic it into future-proof multi-channel content for you! TADA! Put your heads firmly back in the sand reassured by the wonders of software tools!"

 

It’s a whole other blog as to all the reasons that that approach and way of thinking are wrong, wrong and also very very wrong.  It is the Tech Comms equivalent of traditional publishers who think that saving a magazine as PDF is effectively preparing their content for mobile delivery.

 

The article mentions XML in the first few lines and gives the example case-study of iFixit.com, another XML-based platform.  What is core to XML and multi-platform deliver is modularity.  ComponentOne (the irony just won’t stop) are encouraging you to keep going with linear, ‘book—style’ documentation, and just pressing a button and making them into mobile deliverables. 

 

Your documents are never “one component”, they’re a rich combination of different entities that are of interest to different users in different contexts at different times… I don’t want to go into it here, but read some of the books on the reading list, especially those by Ann Rockley, and you’ll learn why this approach has no future.

 

The future is not in multi-platform tools, it’s in multi-platform thinking.  More on that in my recent presentation at Content Strategy Applied in London.

Speaking at Publishing Expo 2012 [NF0]

For those considering the Publishing Expo Conference Feb 28-29 – I’ll be there with some favourite Congility speakers. We’re still accepting last-minute submissions for remaining speaking slots too.

Presentations should be educational, conceptual or "thought-leading" oriented presentations, i.e., not a commercial sales pitch.

They can sent by email to georgina.johnson@mekon.com.

Here’s a bit of background on the event:

Publishing Expo 2012 – Content Agility Theatre

The Content Agility Theatre is back at Publishing Expo 2012. It will focus on core challenges facing the modern publisher in today’s user-led publishing landscape, and educate and inform visitors on the processes, strategies and technologies required to overcome them.

Content Agility means making information agile, portable and reusable – abilities made ever more critical by eBooks, ePub 3.0, mobile web.

These tools are faster and more powerful than anything we’ve had before, but how do you leverage them without increasing complexity and risk?

The Theatre will feature key presentations from internationally recognised consultants, thought-leaders, and content strategists. They work with organisations the world over, helping them make relevant, excellent content available in the context and format of the consumer’s choosing.

Publishing Expo 2012 – CA Theatre Featured speakers:

• Rahel Anne Bailie, Senior Consultant and Content Strategist, Intentional Design, will discuss making e-Pubs relevant to the audience as well as the business.
• Noz Urbina, Senior Consultant and Content Strategist, Mekon Ltd., will discuss updating your content strategy for a community-driven world.
• Brett Freeman, Content Publishing Specialist, Aptara, will address publishing content to digital platforms.
• Anne Caborn, Co-founder and Content Development Specialist, CDA, will take you through governing digital content to achieve agility while avoiding risk.

http://publishing-expo.co.uk/content-agility-theatre