Experiencing the Author Experience

It’s been an excellent year for books here at UX Booth. We’ve discovered new practices and old truths newly explained, ranging from IA messes, to “intertwingling” to client relations. This week we are excited to be speaking with Rick Yagodich, our final author of 2014, on his new book that speaks to something we are intimately familiar with at UX Booth: the authoring experience.

Author Experience takes us through the CMS journey as not just an end-user, but a middle-user, responsible for creating content. We’re pleased to have this opportunity to hear directly from Rick about his own author experience. What’s more, we’re also offering a chance to get a free copy—check it out at the bottom of our interview.

Your book is in many ways a solution to the CMS problem – the CMmess, as you call it. How do you think we got into this mess to begin with?

The problem, as I see it, is that ever since 1995, when the internet made its first real appearance in the public conscience, we’ve focused on the wrong thing. We celebrated how cool it was. We praised the technology that allows us instant connection and broad reach. A cult of personality grew up around this Internet thing. So everyone thought about technology first. What can the technology do? What cool new things can we invent?

Right from the beginning, the new/cool factor dominated. And the things we can now do with technology – whether we’re talking about devices with micro-sensors (your phone can tell the difference in air pressure between head- and foot altitudes) or about the logic embedded in big-data processing systems – are cool. We are living in a science fiction future. Many people have trouble imagining living without today’s technology, even though so much of it reached maturity in the last five years. We can’t help but be impressed by the advances in our lifetimes.

Because everyone was so enraptured by the technology itself, they forgot what it was for. They didn’t bother with what they were trying to achieve: meaningful communication. The technology wow factor was doing the work for them. The audience embraced whatever was put out there, because the carrier technology was so impressive.

With technology taking top billing, and communication processes relegated to the scrap-bin, the platforms were inevitably going to be developed to focus on the rising star.

You have a great definition of a CMS: “The purpose of a content management system is to facilitate the human process of managing the communication content lifecycle from creation, through use, to archiving.” What did people use to facilitate that process before there were CMSs?

The answer to that question depends on the time period we look at.

Before computers became ubiquitous… people used themselves. They developed their own systems – their own processes – to manage and maintain any communications they needed to. Some trained their memories. Others hired legions of secretaries to be their memories. They kept paper records, and used basic library sciences to index the accumulated subject material.

Since computers came onto the scene, the facilitation has reduced. The tools, for the most part, have hindered. Few are designed to support human processes. People haven’t noticed because of basic mathematics: if the technology makes things four times as fast, but reduces personal efficiency by 50%, the overall result is still a doubling in productivity. And who’s going to turn their back on doubled productivity?

That’s an excellent point. On a related note, do you think we have CMSs that are successful today?

Measured against my benchmark, yes, there are a few. I mention one in the book: New York Times’ Scoop. I was recently told about another news organisation’s custom Drupal implementation. I’m sure there are others, though it’s a safe bet that they are all functionally proprietary, or designed for one specific context.

On the less complex end of the market, “facilitating the process” depends on what people are trying to communicate, and to what audiences. In a world where all people think about is the last three seconds’ chatter in a constantly updating stream, Facebook can qualify as a successful CMS. (I was going to say Twitter, but as it doesn’t support editing…)

To what extent do organizations’ perceptions of what a CMS is and what it’s capable of doing – whether based on current or past experiences – impact efforts to improve the author experience?

It is precisely the perception of what a CMS is and what it’s capable of that destroys the author experience. There’s too great a focus on channel, then tool (CMS), then communication. It is that underlying mind-set that is hurting the AX.

So, are organizations and people starting to change their perceptions of the CMS?

Yes. And the change isn’t so much in changing perceptions of what CMSes can or should do, but in the order of focus. It is shifting towards what it should be: first communication, then channels, then the processes to pull it together, and finally the platform (CMS) to enable it.

That changed order rewrites the rules. The CMS is there to do a job. Its functional scope is defined in terms of supporting process; its success measured against how it facilitates.

Not everyone is on board with the better approach, but the shift is gathering momentum.

You discuss responsive web design a bit in the book, and your concern that RWD “reduces the diversification of platforms to a single responsive mapping and assumes content can be optimized for that default channel.” How do you start talking about content with someone who is convinced that RWD is the panacea for all of their problems?

This requires something of a two-pronged strategy.

On the one hand, we need to step back and think about what we are doing holistically: we are not creating web sites, we are communicating.

On the other hand, we must remind those people of the changes we’ve seen in channels over the last couple of years, and have them project those changes a couple of years into the future. What will the next channels look like? Are they going to use HTML as their delivery mechanism? Will they support page parity with the current RWD channels?

So it all comes back to the flow and functionality of our CMSs. Do you think it’s possible to build a flexible enough CMS that it would fit all authors?

Theoretically: absolutely. (And as I mentioned in one of the asides, I designed the underlying principles for that a long time ago.)

The challenge is that implementing such a platform is not about developing a CMS. It’s effectively about creating a CMSMS (content management system management system): a platform that provides configuration of (as opposed to plug-in functionality to extend the scope of) the content management interfaces. Such a platform would allow content strategist specialised in content modelling to define – maybe with a drag-and-drop interface – the elements that a content type comprises, then allow configuration of its various authoring interfaces, and then the output definition without any programming.

There are two main reasons such a system won’t be available soon.

The first is financial: it would be a massive project. And it cannot be released until it is effectively complete. It is a case of baking an apple pie from scratch, the Carl Sagan way – first, create the universe.

The second is that too many people have been taught to solve problems directly. Those who are creating platforms see a problem, and look for a way to implement it. But to build a CMSMS, one needs to look at the problem, and then abstract it to a more generalised case. And then abstract it again, and again. Effectively, instead of slicing an apple with a knife, understand the molecular bonding properties of the steel blade and the organic compounds of apple fibre cells… and then express those principles in a way that determines the slice/be-sliced behaviours of any pair of items, in any relative motion context. (If I lost you there, it was partially intentional. The level of generalised abstraction required is complex.)

Such a platform would be an order of magnitude more capable than any individual organisation would need – and it would still need to be configured for each. While I believe the configuration effort would be less than current customisation efforts, the difference would be small, at least for early implementations. And someone still needs to create the universe.

Thank you Rick. One last question: if you could give authors one piece of advice as they work with or build out their own content management systems, what would it be?

Keep in mind the underlying reasons for what you are doing: it’s all about communication. Everything else is about supporting the communication. From all angles.

Thanks so much for speaking with us Rick.

For readers interested in getting a free copy of Author Experience by Rick Yagodich, leave a comment below with your biggest hope for CMSs (or CMmesses) and your Twitter username. We’ll be in touch on Twitter to let you know if you’re one of our three lucky readers!