Playing with the future - Part 5 - Any tool can create content

Today, we all are Information Architects. The average number of documents, presentations, emails, blogposts, and the myriad information sources we have to cope with daily continues to grow exponentially, with no end on sight.

So we all come up with nice little tricks to organize our content. Some go for the "all in one folder approach" (works with good search), others go for the super-structured approach for content management (folders upon folders of content hierarchies), and others (if your company's smart enough about knowledge management) go for the Enterprise Search approach. "Dump it in any of our document repositories, and go to this url to find it back".

Coveo nod: I really like their tagline of "Stop searching and start finding".

So, as part of our daily job as information architects (for our own information, not for your organization's), we work with a lot of tools, and very often the tool you use is determined not by your preferences but by the intended audience of the content you're creating:

• Microsoft Word for the audit report
• Microsoft PowerPoint for the roadmap or visionary statement
• Blogger/wordpress for your personal blogpost
• Email for the quick communication
• Twitter for the even quicker communication
• Tridion / CQ / SiteCore / Sharepoint for your company's official blog
• Visual Studio or Eclipse for the really cool stuff
• OneNote (or EverNote or Google Keep) to take notes during meetings
• Prezi for the "I'm cool" effect (nope, doesn't work that way anymore, you're 3 years late)
• Confluence for requirement gathering and roadmap grooming
• Jira for backlog management
• Facebook for the family/friend hugs
• [list goes on]

Many years ago I remember thinking that, perhaps, the browser would be the tool of the future. Nope, that didn't really work either - yes, you do use your browser to do a lot of your work today, but you're not really using a browser - you're using the application behind the browser.

And another thing that is happening is that we're losing the W in WCM. Content that is not web accessible is not really content anymore, is it?

Hence my prediction... tools that can handle content transformation easily and can abstract the delivery mechanism are the tools we're going to use for everything. CM will eventually become a standard set of APIs (yeah, yeah, CMIS is an effort in that direction... but not really there yet, and too enterprise-y) and the tool you use to create content won't matter anymore. Because there will be enough intelligence behind the tool to "understand" what you're talking about (see part 1 and part 4 of this series) there will also be enough intelligence to understand how to transform that content to your required delivery format. And the tool(s) of the future will be born to address this requirement - hide all information architecture complexity from me, let me create content as content, and then help me deliver the content to my audience. And don't make me think.

Playing with the future - Part 2 - Content Ownership

As a follow up to my previous blogpost, here's the second concept we came up with on the topic of "How will content authors create content in 2020".

This idea might be a bit more radical than the first one... "Content ownership will be diluted".

There are many types of content creators out there, from the marketing-snazzy cloud-sourcing heavy world of "modern social media buzzword compliant marketing" to the corporate workflow-heavy legal review world of most of the customers I work with.

In some industries, it is perfectly acceptable to have someone from outside the organization to create content for you - be it via "endorsed blogging", or "fan content on Facebook", or even comments on specific pages that get promoted to full page articles given its quality. This is something we already see happening today on a regular basis.

But the brand fan of the future is different. The brand defender of the future is possibly 16 years old, and is compelled to share due to sharing being in their DNA - hyper-connectivity does that to you. So companies - including workflow-heavy legal compliance companies - will go out of their way and find methods to assess how much of a fan are you really, and possibly give you special rights to create content on their websites. 

If you believe in my company and brand even more than I do myself, why would I stop you from contributing positively?

Here's how I think this will impact the world of content:

1. Gamification principles and social media tracking will be used to accurately measure a person's brand-awareness level - you want to find those brand defenders out there, and you want to empower them
2. Brand defenders will - from outside your firewall - have special privileges on your content platform - be it by being allowed to review content, or by being able to create content themselves. This process already happens today, but in a rather unstructured way. (I certainly get emails from brand defenders about content published to Tridion World, I can only imagine that Bart Koopman gets even more)
3. Brand defenders will be given access to marketing strategies, campaign ideas, and any other branding material. They will carry the flag for you in exchange for early access to data, exclusive T-Shirts and bragging rights. Why wouldn't you reward them in their own coin (data)?

In other words, brand defenders will become your "trusted content contributors".

I can certainly see a future where even the most legalese of texts gets reviewed by people that are -- at first glance -- completely unrelated to your company, but that know your brand value better than the people being paid to create a brand value. Where content is created for your website by your most loyal fans, and where content management tools are built with this in mind from the ground up. Where content review is done by people outside your corporate legal department (but likely not excluding legal completely), and where you provide your brand defenders with all the tools and data they need to be heard.

Tune in soon for my next non-binding futuristic play: Context Engines.

What is the future of content?

I guess I have said it enough times - I am in a rather privileged position within the WCM space, as I get to see a lot of what really is implemented by our customer base (mostly in the highly regulated financial industry), I get to play with magic crystal balls, and I get to hear about what experts and analysts think content people should be doing now, and in the future.

And I admit, I am extremely confused, because the pieces don't fit together.

Let me try to explain what I mean with this.

On the one hand, we have simplicity. The people who select WCM systems (please note that I am not saying "Content Editors") want a "Facebook-like experience" creating content. They want the simplicity of WordPress or perhaps Blogger (which I use) when creating content.

On the other hand we have compliance and content governance. People want to control content life cycles, trace back the origins of content from its inception to its inclusion on a given page, to its transformation into a Call To Action on the home page, to its decommissioning a year later into the "outdated content" bin.

And finally, on the last hand (yes, I know those are three hands, get someone to lend you one), we want content re-purposing and targeting. We want content that can be used across all channels - Web, Email, Digital Signage, Facebook, Twitter, IOS/Android Apps, Google Glasses and what not.

And this is where I get confused.

Simplicity means one thing - less flexibility. Sure, you can make very reusable content with WordPress, but then you're putting the onus onto your editors to use the correct html mark-up for your content. I agree that a lot can be achieved with some smart plug-ins, but how do you prepare for the next channel that you don't know about yet? And especially, how do you create truly "re-formattable" content when you want simplicity, which by its own definition mixes content and layout?

And governance. Governance is impossible without metadata. Usually, it requires metadata about your metadata (ever tried defining a release policy linked to content models?). Again, sure, we can try having your editors enter that metadata in their simple-to-create-content web tool. Doesn't look so simple anymore, does it?

Creating content that can be re-purposed for various channels, including those that don't exist yet, and allows for personalization is where the whole thing falls apart in my view.
How can you have content that was simple to create - web based, WordPress like interface, loads of drag-and-drop widgets and SEO optimizers and navigation managers and whatnots - and have that content still comply to a strict schema, like those specified in schema.org? Sure, you can look at semantic engines - like Apache Stanbol - to help your editorial team get their content right, but how is that going to help you determine which headline to show on your iPhone app?


Don't take me wrong, I'm not trying to say that creating content should be hard - on the contrary, it must be easy. But creating content that can live beyond the constraints of a web page requires thinking beyond drag-and-drop and easy-to-use (actually, having to use your mouse when creating content is a terrible thing and completely breaks the flow of work) - you have to think about content modularity and new delivery models.

My view on the future of content is that layout and look-and-feel will disappear, and consumers of your content will care about nothing else than the content itself, the layout will be based on their preferences and their own metadata, with smart apps - in whatever is the device-du-jour - taking on the task of formatting that content for display. Don't think RSS, think Open Data+schema.org.

So, unless I'm terribly wrong (which is always possible and known to have happened many times), the emphasis on Customer Experience Management requires more content structure, not less. And more content structure, today, means that editors must have an abstract view of content, focus less on how it looks and more on how it's structured, so that the context in which the content is displayed can adapt to the customer's expectation. And to do that, we have to think beyond pages and re-think content as individual entities that can be manipulated and formatted for display in whatever device or app the customer may chose to consume it in. And that my friends, is against the view that content editing should be a simple, word-editing-like experience. Just like word editors were built for a world in which your main goal was to print that document once it was finished, many WCM tools out there are built to publish web pages, and web pages will be just a tiny fraction of how content is consumed in the future... (just like the number of people that actually print documents once they're finished with their editing).

SDL Tridion and Rich Text Fields

In the past year we've been asked a few times how to add support for non-XHTML tags to Tridion Rich Text Fields (if you want to know how, check here, here or here) and this usually gets followed by a discussion with questions along the lines of:

• Why do you want to do that?
• Why is it not there out-of-the-box?
• Is it supported?

So, here's my take on why you're doing it for the wrong reasons. Yes, you can modify the rich text settings to allow entering any possible tag, but everytime you do this you are breaking the experience of your content editors for the sake of making your html markup work on your site.

When editors must create content that includes non-standard XHTML tags they will have to edit the html source of their content and add the tags themselves - guess how much of that will work when using Experience Manager? When implementing Tridion (or any other WCM) you may be tempted to take shortcuts to implement faster, and also to avoid having to review the HTML/Web app that you intend to use. But if your content editors are expected to edit their source html to insert "data-rule" attributes in links, you just made their life harder.

What should you do instead?

In my view, non-XHTML attributes required on content should be dealt with in the most user-friendly way. If you need to use <article> or <section> tags in your RTF, why not convert <div class="article"> to <article> at publish time? If you need to insert data attributes to links, then do consider a similar approach replacing other, normal attributes (or, at the very least, consider writing an extension that allows to add those tags without editing the html source).
Every time you ask an editor to edit the source of their html to add attributes you are asking them to dislike the system. Consider this when designing applications, making it hard to edit content has never been one of the goals for a WCM implementation project...