Showing posts with label Content Management. Show all posts
Showing posts with label Content Management. Show all posts

Sunday, June 21, 2009

Trends in Web Content Management

After a couple of weeks of attending various web content management conferences (GilbaneSF and Web Content in Chicago) and talking to a lot of people more clever than I, I figured that a summarizing blog post might be in order. These are some of the trends I spotted.

 

Social

Facebook, Twitter, Flickr have paved the way – now everybody wants user generated content. It seems as if most companies has figured out that visitors that contribute with content are dedicated visitors – and who wouldn’t want those?! Most CMS vendors has forums / blog functionality built-in – and a handful have gone all the way with full-sized communities containing clubs, my-page, videos, friends, social graphs, you name it (including EPiServer). A lot of the stuff isn’t new – forums and public profiles were common even during those delightful years of BBS’in in the eighties and early nineties. And during the Web 2.0 era a few years ago it boomed. It’s first now, however, that people are really considering when to use which features – and when not to use it. Perhaps it is really time to start use this technology not just “because we can” but “because it makes sense”. This might just be when Web 2.0 turns profitable.

 

Personalization

Personalization has been hot for a couple of years now. Pioneered by companies such as Amazon, Netflix, etc. companies are now starting to see real business value in personalizing their content. The term is used to cover a lot of different technologies and usages however. Everything from changing the language of the website to automatically suggesting products that the current user is interested in – is some kind of personalization. Even silly things such as letting the user customize the style or background color of the website is getting popular.

Again Facebook has turned out to be somewhat of a thought leader – adds shown there are totally personalized to your characteristics increasing the possibility of a click/purchase.

Most CMS vendors have some sort of way to enable simple personalization – like the ability to save key/value fields about each visitor and that way allow the implementation to build up a profile. But after what I’ve been able to find out nobody has gone beyond that – which means that most of the personalization work done is done in the actual implementations of websites and not as a standardized feature in the content management systems. In a few cases the search engines used on the websites actually comes with more build-in personalization features than the CMS.

 

Mobile

Mostly due to the iPhone and increased 3G/HDSPA/edge coverage the web is no longer something that’s just meant for regular desktop/laptop computers. In fact in Asia, most internet usage is coming from mobile devices. So every CMS vendor is coming up with strategies on how they can deliver content across platforms. To be able to manage mobile content is a MUST these days – and the approaches vary from automatically transforming the html to supporting multiple rendering methods. A series of niche-players purely focusing on extending the mobile abilities of mainstream CMSs have already emerged.

 

Translation & multiple languages

As the world gets smaller and economies collapse in the english speaking world a lot of focus has turned to new, emerging markets in the east. This brings with it an increased focus on translation services and the CMSs ability to handle multiple languages. While European vendors have been used to the multi-language-challenges for years, it’s still a somewhat new challenge to US websites and systems. And once the system is in place, the actual translation begins. And in spite of what you might think it’s not just about changing the texts on a page. Multi language often means multi culture. Pictures, expressions, analogies and site structure often needs to be adapted. Some languages require right-to-left alignment. Illustrative pictures that are innocent in one culture can be highly offensive in another. A huge market for translation services and culture consultancy has emerged – and it seemed that no matter where you’d turn a Gilbane a friendly guy from a translation company would be there :-)

 

Connecting

I remember a day, not too long ago when I learned that a major danish company had an entire department of secretaries hired to take printouts from their ordering system and type them into their hour-management system, their CRM system and their invoicing system manually. None of the systems could interact in spite of them being based on the same platform – heck, even on the same servers.

Hopefully we’ll soon see the end of those days. There is a lot of focus on interoperability and connecting different systems – especially in the content management industry. Vendors are opening up their API’s, supplying web services and even building connectors to various systems. Most popular are connectors to enterprise search, sharepoint and crm systems like Salesforce and Microsoft CRM. Many implementations feature integrations to backend commerce-systems, product databases and invoicing systems – and we are starting to see a tendency to more standardized connectors as the systems mature.

EPiServer went down that road long ago, with Virtual path providers, Content Channels, open API, Microsoft CRM connector, Salesforce connector, EPiMore partner program and in version 5.2 we came out with PageProviders to connect live to any other datasource.

It’s easy to understand the popularity of this – ROI’s are easily measured in the number of work hours saved from being wasted on manually synchronizing data.

As a result of these efforts we are also seeing new protocols and standards emerge. Since it was proposed in august there has been a lot of buzz around CMIS (Content Management Interoperability Services) and many vendors are starting prototyping projects to be CMIS compliant when/if it officially becomes a standard. I talked to quite a few people about it and of course people are afraid that it will suffer from YASS (Yet Another Standard Syndrome) and die down – but still like the idea of a common way to integrate with other ECMs – or let other systems integrate with theirs. Together with a handful of others I’ve started the NCMIS project recently to see if we can scrape together a cross-vendor team interested in making a shared, open source .NET library/toolbox to help everybody adapt their systems to CMIS.

 

Collaboration on Content Creation 

Ok – I admit – to call this a trend just yet might be taking a step too far. But I predict that this is a trend we’ll see soon. When Google Wave launches for real I could imagine people getting used to constantly collaborate on construct contents. Today most CMS systems lack features that allows concurrent editors to actively work together on creating a piece of content – at most there’ll be a check-in / check-out functionality to avoid overriding each others changes. But wait and see!

 

Measurability

The last trend I’ll mention is probably one of the most important trends. Today it’s not longer enough for a feature on a website to be cool in a geeky sort of way. Today you need to proof that it’s cool. Most vendors today integrate with some sort of web statistics tool to show basic stats for the website – but we’ll see even more very soon. Many vendors are looking towards marketing engines, A/B testing, landing page optimization as built-in features that will allow website owners to test how well a given change to a website works on the visitors. Sometimes even simple changes in the text of a link can make the difference between success and failure for a website – and you’ll need to be able to measure it. Perhaps it’s the maturing market and technologies – perhaps it’s the collapse of economy, but measuring & tracking – often realtime – what’s going on on your website is definitely part of the current and future.

Saturday, October 18, 2008

Wiki vs CMS - the difference is psychological

When I started in EPiServer AB one of my first tasks was to "make a wiki plugin for EPiServer". Naturally, being new in my job, I enthusiastically started working. However, it pretty soon dawned on my that I didn't know what a Wiki really was. Sure, I use wikipedia daily and understand how it works, I know that "Wiki" means "fast" in Hawaiian, but it wasn't really that obvious to see what the difference is between a CMS like EPiServer CMS and a Wiki. I ended up writing an internal RFC on the subject, and awaited comments while I moved on to tons of other tasks, piling up on my brand new desk.
Around half a year later, I'm in a small but luxurious hotel in the Stockholm archipelago together with the rest of the EPiServer Research team, brainstorming on which new prototypes we should make for our big partner event in june. Again, the Wiki came in to play, and I spend a week or so making a working prototype of it, which I later demo'ed at the Partner Summit and hopefully soon will find time to finalize and ship as open source...but I digress. After reading Deane Barkers excellent blog post on the subject I figured I might share my views as well. So here goes:

 

"A wiki is a medium which can be edited by anyone with access to it, and provides an easy method for linking from one page to another." (Wikipedia)

"Contrary to their reputation, Wikis are content management systems that can be managed. They simply take a different approach to content management by choosing to emphasize speed and flexibility rather than strict controls." (CMSWatch)

So, what I really see initially is that a Wiki is a Content Management system focused on collaboration and knowledge sharing. A typical CMS has a some editors and many readers, where a Wiki has many editors and many readers. Not all that much of a feature. Just as Deane I've also looked at some of the key wiki features:

  1. The name of an article is embedded in the hyperlink.
  2. Articles can be created or edited at anytime by anyone (with certain limitations for protected articles).
  3. Articles are editable through the web browser.
  4. Each article provides one-click access to the history/versioning page, which also supports version differencing ("diff") and retrieving prior versions.
  5. The most recent additions/modifications of articles can be monitored actively or passively.
  6. Easy revert of changes is possible.
    On top of those features I would also include:
  7. Easy linking
  8. Easy creation of new pages

(Wikipedia's list of Wiki features)

All features that's either out-of-the-box or just a matter of configuration in any state-of-the-art CMS, like EPiServer CMS.
So, is a CMS = Wiki ? I didn't really see the difference until after I made a prototype and allowed my coworkers to start to use it.

The prototype I made was based on EPiServer CMS, and consisted of the following:

  • A UI that looks like wikipedia
  • View-mode editing of pages
  • Support for WikiSyntax ( like [[links]], etc.)
  • Ability to create a new page on-the-fly if there's a link to a page that doesn't exist.
  • Each page consists of X elements that can be edited independently
  • View-mode version control
  • Discussion Forum for each article
  • Handling of multiple concurrent edits
  • etc.

The moment I had a prototype up and running it didn't take me long to see the strength of these relatively small changes. It's addictive.
So, I realized that the difference between a CMS and a Wiki is really psychological. A Wiki's strength is fast and quick knowledge sharing - with everybody contributing to gather all their knowledge together. Why? A CMS is typically used for websites and/or intranets. Text-writers and editors use it to publish and structure their perfectly written articles. And here is the core of it all....A wiki doesn't need to contain perfect, complete articles. In the nature of a wiki anyone can add their knowledge instantly - either to existing articles or by beginning new ones - but without the obligation to finish them. And hence people are much more likely to start sharing their information. Still not with me? Here's an example: My knowledge of about the country of Norway is limited. If I were to write an article (or a blog post) on Norway I would have to do a lot of researching and then spend a lot of time writing and compiling all this knowledge. End result: I'd never get it done (mostly because I'm lazy, but also because I'm busy and not all that interested in the subject (sorry, Steve)). However, on a Wiki I wouldn't mind at all adding the few things I know about Norway to an existing (or non-existing) article. It would be something like this:

"Norway is a good place to go skiing. They have a lot of oil-money. Beers are rather expensive there. The capital is Oslo." 

But the point is, that I would share the little I know. And maybe someone else with access to the same wiki knows something else about Norway and will add it. Because they are not obliged to writing a complete, perfect article. That's why Wikis work efficiently for knowledge sharing - and that's the difference to typical websites built with a CMS (in my humble opinion).

But of course Wikis can be based on a CMS like EPiServer. Just wait for it :-)