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 4 - Data is the future of content

A few months ago I had a question from a prospect that had me stumped.

Your product is great with content, but how does it deal with data?

It took me a while to understand - more context was needed - and still today it is somewhat haunting me. To me, content is data, so what in the name of <insert random deity> did they really mean?

Well, what they meant is not exactly what this post is about, but it is somewhat linked. In their specific scenario Data meant semi-structured data feeds they get from their other applications that may or may not be displayed on the website.

How to deal with it is linked to the topic of this post.

You've seen the semantic web at play. For us WCM geeks, some of the first examples of the semantic web were those "helpful links" under a google search result (and now they show with even more detail, like a link to a related blog) and lately with efforts like good relations and schema.org the semantic web keeps on creeping up on us with great results for everyone (and search engines!).

With me so far? Semantic Web is good, content is good, data is also content, but might come from a different source.

Now, why do I say that data is the future of content?

If you've developed websites before (not just snazzy html, I mean really design websites, web experiences, content creation flows, contextual experience definitions, etc) you've probably been frustrated like I have about the lack of metadata on content. Editors seem to just want to use "an html WYSIWIG" editors to create content, but then expect you to do miracles about how the content displays, magically determine which pieces of data are used for your tab names, which images to use for the home page, etc. I had a particularly harrowing experience with a given editor that insisted all content should be classified under "Personal Finance", yet expected the site to be able to sort the difference between auto loans and mortgages (deep sigh).

Summary #2:

1. Content Editors want an easier to use, easier to create content in, simpler UX/UI paradigm that allows them to create semantically meaningful content without having to deal with complex operations or data structures.
2. Semantic content needs proper annotations, schema compliance, and contextual information (used to determine, for instance, when is appropriate to show this content vs when it's not)
3. Both points above are at odds. To create semantically meaningful content editors need to spend more time curating their content.

And this means that the solution is to enrich content with semantically meaningful metadata automatically (with the possibility to be modified/enriched by the editors).

In other words - editors will get what they want: simpler ways to create content; and developers will get what they want: more meaning attached to their content in the form of "data" - metadata, ambient data, structured streams, whatever you want to call it. And that will allow us to start creating smarter UIs that can help you determine layout, presentation and context with less effort. All you need is more data, and we will get more data from intelligent systems that can do most of the digging for us.

Playing with the future - Part 3 - Context Engines

As a starting point of our 3rd post in this series of "non-binding futuristic plays", I'll start by telling you a secret that everyone except Marketing seems to have realized. Actionable analytics already exist, and they've been around for quite a while.

Yes, it's true. I keep hearing some babble babble from Marketing people on how they need actionable analytics, and we (IT guys with a clue) keep on asking them "how do you want to use them?".

You see, we have the data. We have had the data for many years now. The challenge is not there. The real question you (Marketing guys with a clue) should be asking is "how do I use the data we have without having to call you every time I need to change something?" So, basically, what you need is not actionable analytics. What you need is a way for you to act on the data, and a way to know which data you have, that doesn't involve calling me or some other IT fellow unfortunate enough to be on your quick-dial list.

OK, guess that's enough to set the stage for what I want to talk about today: Context Engines. Back in August we released (rather silently, I admit, and for good reason) version 1.0 of the SDL Context Engine, and we're now finalizing version 1.1 (to be part of SDL Tridion 2013 SP1 and available for 2011 SP1 as an add-on, if that's what you were going to ask) and I am really impressed with what we were able to cook so quickly.

What does a context engine do?

I believe that modern sites should be able to answer, within milliseconds, a very simple question: why did I come here? Understanding the reasons that drive someone to open up a given URL gives us the insight required to serve that visitor's request quickly and without wasting their time (i.e., providing a good web experience). And there's no other way to understand why you're here than by understanding the context that made you come here.

So, what is context?

That's a very open ended question, so I'll answer it in 2 ways:

1. Context is everything
2. Context is a collection of data points that can be used programatically to determine why you visited a web page, and let you act upon this based on configurable rules.

 A Context Engine does the following two things:

1. Determines the properties of the current context
2. Evaluates the context and executes a certain contextual path or rule

Example:

In the current context we determine that you are using an iPad 2, it's 10 in the morning, it's the second time you came to our site today, and the last product you looked at was coffee.
Based on this information we can:

• Make sure you see the tablet optimized UI for our site (server-side, with optimized images, not only RWD)
• Give you a coupon for the nearest starbucks

The beauty of this is not that it can be done. I (and most other Web people out there) could have written code for this back in 1999 (well, not really the tablet-optimized UI part). The beauty of it is that this rule was created by a content editor, using perhaps something as simple to use as SDL Customer Analytics (or who knows, Tridion Target Groups) and the Context Engine simply chose the most appropriate path based on your rules.

Now if you extend the data awareness of a context engine to include data from your purchasing history (or interaction-with-my-brand) you suddenly open the door to way more ways to provide a contextual experience to any visitor, and you start being really good at understanding why I came to your site, and, who knows, maybe you'll even be able to sell me that great vacation I clearly need.

This is - again - not new. SDL Fredhopper, for instance, is an amazing Context Engine. What I think will be new by 2020 is that most sites will be using a Context Engine or similar technology to determine the context and decide what your experience should be. I also expect to start seeing cloud-based Context Engines (someone called them Context Brokers in the past) with all the serious privacy implications this includes...

One last note. As part of the development of the mobile aspect of Context, I've come to realize that most people ignore the fact that the device you are using is only a part of the context, not all of it. The WCM industry seems to be focused so much on how to show nice buttons on an iPhone that we seem to forget the bigger picture: why are you using an iPhone to come to this site? Are you on the move? Are you having a smoke outside? Are you right outside my shop? Are you in my competitor's shop doing price comparison?

If experience was determined by UI alone, then nobody would ever use craigslist. No, well-designed Context Engines put editors in control of selecting the right content for the right context.

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.

Playing with the future - Part 1

Some time ago I had an interesting conversation by email with my colleague and fellow Product Manager, Alexandra Popova. The subject was "How will content authors create content in 2020".

This spawned a whole series of ideas and concepts about content creation and - especially - content delivery, ensuring that the content that is shown is what you are searching for at this point in time. From there I ended up creating a Slide Deck I use sometimes with the title of "The future of content - a non-binding futuristic play". I think it's time to put those ideas out to the world and see if there's any strong disagreements.

There are 5 main "ideas" that we think will be prevalent in 2020:

• Schemas will disappear (as in, you won't see the content structure anymore)
• Content ownership will be diluted
• Context Engines will be mainstream
• Data is the future of content
• Any tool can be used to create content for a delivery platform

I left some out for the simple reason that by 2020 they will already be a strong reality: web content will stop being page centric (some argue that this is already the case, and I agree), content will be self descriptive and "atomic".

Anyway, let's dive into the 5 ideas that I think will be a reality in 2020.

Idea #1 - Schemas will disappear (from the editor's screen)

There will still be some niche markets (product catalogs and support documentation) where this type of interface makes sense, but as systems improve and become more reliable, you'll be more & more using "smart" content editors that derive the semantic meaning of your content for you. There will still be a schema that your content must comply to, it just won't be "in your face". And no, HTML5 is not a content schema - at most it's a page schema and a vocabulary for content. You can present structured content using HTML5, but that's a result of its flexible design.

So, what are some examples of this out there? Well, our own SDL Xopus editor, for starters. It binds to an XSD just like most XML editors, but presents it in a completely familiar way to editors used to working with "less structured" content tools like MS Word or EverNote. (go play with the demos if you don't believe me)

Furthermore, the advances being done in what was once an exclusive domain of "enterprise search" software - entity discovery and concept mapping (see the excellent Apache Stanbol as an example) - means that this type of technology is not anymore in the domain of very expensive and rare software. No, it's starting to be available to anyone with a workable Internet connection. And if I, as a content editor, can let the software discover what my content is about and tag it appropriately then I'm free to create my content and let the metadata tag itself (I obviously need to review and approve).

An interesting side effect of this is that you will not get less metadata. Au contraire, we're going to (finally?) get a lot more metadata can be used to segment our content in ways that will allow our devices to display it properly.

Systems (and people) will struggle for a while, but as leading systems pick this up and start improving on it with usage, we'll all get better for it. And devices like HUDs on cars will easily display your content, in a way that won't distract the driver from what he needs to focus on.

Next week I'll post about how I feel the concept of content ownership will slowly dilute, and distributed ownership (including from outside your firewall) will be the norm.