Contented Management laughing buddha logo

Contented Management

Contented Management

Early thoughts on Drupal Gardens

Geese in Stourhead gardens

Last week, Acquia launched Drupal Gardens in beta. Speculation might have been more feverish had this not been on the same day as some company in Cupertino launched a new gadget. Nevertheless, Acquia’s offering is worth a second look.

Gardens is effectively Drupal 7 as a service: WCM hosted on the Amazon content delivery network. It includes a number of modules and is aimed very squarely at microsites and perishable campaign sites. It promises rapid deployment without needing a Drupal superhero to set up your site. You don’t need SQL, you don’t need PHP. You pick your URL, your templates, tools and styles, enter your content and you’re live.

And that represents what many people really understand by WCM.

You can create repeatable information architecture and consistent design elements from a library of themes and templates. You can use the Theme Builder to create custome content types. And it’s way friendlier than WordPress.com. Slicker too. People with very limited web knowledge can create websites even more easily than they used to in the days of Frontpage or Dreamweaver and go live with them, since Acquia take care of the hosting.

But this is very much WCM for websites that have content only. There’s nothing transactional and no sign yet of secure hosting that establishes private networking to your other online applications. It’s a great template editing tool to give to your design team or for small businesses to play around with, but not necessarily the tool that allows you to devolve complex editorial tasks to distributed authors. While the cloud-based aspect should allow you to scale your website delivery, it’s not clear whether it scales on the authoring side for people wanting to contribute content from around the world (which probably isn’t a central use case). It’s also worth noting what’s on the road map, because these are things that Gardens can’t yet do; such as multi-site search, multi-site configuration, and analytics.

Where Garens is a great fit is for clients who want a rapid time to deploy with minimal fuss. Why should clients concern themselves with APIs and hosting SLAs? Why should they have to engage with geeks just to change a template? Gardens resolves those issues by giving you a website builder and at a great price: it’s free throughout 2010 and only $20 to $40 per month per site after that, with flexibility over multi-site licences. But if you’re hoping that your website should be more than just vanity-ware, that it will increase revenues or reduce pressure on other streams by bringing transactions online, you’ll have to look at a content-driven application that has better integration points with other systems, or wait for this to be developed by Acquia.

I think Acquia’s move has implications for the wider WCM industry. Firstly, that the SaaS model has a valid use case which will permeate higher-end WCM; for example, Alterian CME is sort of available as a service through Verizon. Secondly, because many clients still understand (and want) WCM to be a tool for managing look and feel as well as content. Drupal Gardens achieves both those things. Can other vendors say the same?

Philippe Parker on , , | 2 February 2010

Contented Management

When WCM isn’t enough

Orange and blue liquid forms in a glass

How many websites these days are purely content-driven?

It’s hard to justify brochureware sites. How many people do business with you just because your website looks pretty? Organisations want websites that either generate an income or reduce pressure on more costly channels, like call centres. That means transactional web applications, not just web content management.

Yet content management is still required. Whether you’re updating marketing material to support your service offering or changing form labelling and layouts to ensure fewer drop-outs on transactions, the web team still needs to be able to make content changes without having to go through a lengthy development release process.

The simplest way to achieve this is to run two web applications separately, one driven by the content management system and the other by the transactional software, like eCommerce. You get your developers to style the two applications to look the same, run from similar URLs and hope that the web app gives you enough control to alter content that it’s responsible for, such as labels on form fields. This way you can keep system integration to a minimum. There are a couple of significant disadvantages, however. Firstly, if your site needs to change globally — a change to brand or navigation, for example — you have to update both systems. Secondly, you need to design your site in such a way that you keep content and transactions separate, which is very unlikely to lead to a successful user experience.

So what are your other options? You could take content managed through the CMS and embed it in the transactional application. This means that when you have a form field to complete which needs some guidance, that guidance can come from the CMS without the user having to abandon their transaction. But this creates problems of its own. You lose some of the key benefits of the CMS: relationships are harder to maintain between pieces of content and preview becomes nearly impossible.

This is why the transactional application is often embedded in the CMS. FatWire, for example, has just launched its Web Experience Management Framework, which should make this process easier, while Terminal Four also touts its integration with external systems. Yet irrespective of the CMS you use, you’re going to face some integration problems. There’s bound to be an element of custom code, issues with assuring decent performance from both the CMS and the transactional application, and above all design difficulties ensuring that the security of the user’s transaction is maintained by the delivery layer.

Another option is portal technology. In theory, portals enable you to deliver all your web applications in an integrated fashion and what’s more, do so incrementally, adding applications without having to change the core configuration. They’re also usually pretty good at managing sessions and user credentials. Portals bring their own problems however, not least cost of delivery, increased time to develop and un-friendly URLs.

So all four approaches have positives and negatives. There’s a niche in that market somewhere for a vendor. Until someone proves they’ve filled that niche however, you’re unlikely to be able to deliver a great business-driven website using just a web content management system.

Philippe Parker on , | 14 January 2010

Contented Management

The future of the web is JavaScript

O'Reilly JavaScript textbook

The future of the web is mobile. And by mobile I don’t mean mobile phones. I mean browsing through devices that people carry around with them. All these devices, irrespective of form factor, have a common problem: they are prone to lose connectivity to the internet.

If you’re on the move and keep losing your 3G signal, or just happen to live in an area with a poor reception, or in a house with brick walls which slow wifi, or suffer from terrible contention rates in your Starbucks or conference venue, you’ll know that cable-less connectivity is fallible. So you’re in the middle of a transaction, just trying to get to the next step when… enter tunnel / lose packet / connection error and you have to start over.

There is a solution to this problem however. As Michael Kowalski tells us, the future of the web is JavaScript. Or perhaps not JavaScript in its current form, but client-side scripting nonetheless. Why? Consider the options.

If you want interaction that will run reliably on a device with poor connectivity, you can’t keep expecting the browser to go back to a server. So you might make your functionality available as a downloadable app. But it had better be a killer app the user wants to rely on, because otherwise they won’t want it taking up real estate on their phone. And it’ll have to run across operating systems if you want to reach a broad market, not just Steve Jobs’ latest toy.

You could use a rich internet application such as Flash or Silverlight. But the client platform has to support these and the user has to install them, although they’re more likely to do so for a generic RIA than for a specific tool. The big issue with these applications however is that the content is embedded in the interface, which makes them both heavy to download and difficult to make accessible to other applications, such as screen readers and content aggregators. So you’d probably have to create two versions of the content: one embedded in the RIA, the other standalone. That’s not great.

JavaScript has the advantage that it can be used to enrich content, but not contain the content itself; for example, to provide better interactivity on maps. There are also libraries of JavaScript functions that can be re-used and downloaded to the client device with the user barely noticing. Take jquery: Google hosts a copy, so if you use these functions on your site, you don’t even need to host the file. Reference Google’s copy and you’ll save bandwidth and, if enough websites follow the same path, there’ll probably be a cached copy on the user’s machine even before they get to your site, which will significantly improve response times.

Google is of course moving beyond jquery to complex client-side scripting which its own browser / operating system will be capable of handling, but some other browsers may struggle with. Chrome is a replacement for off-line scripting using Gears. It should not only enable mini applications such as Wave to run faster in a browser, but will enable online transactions to continue to function better when connections are poor. Opera has been developing similar functionality for its browser too.

So if you want to provide audiences with a better experience irrespective of platform and location, a lightweight client-side tool that separates content and function and runs in a browser seems like a future-proof idea. And for the moment at least, that means JavaScript.

Philippe Parker on , | 11 December 2009

Contented Management

Devolving complexity

Combined harvester

What sort of editorial model do you follow for your web content management? Do you try to get as many as possible hands-on, or do you run everything through a centralised editorial team?

It’s ironic that WCMS which enable you to perform more advanced content management provide tools that you probably won’t want to devolve to part-time editorial teams. Conversely, simpler WCMS are often chosen by by smaller, centralised teams who often feel constrained by the software they use.

Vignette, for example, enables you to assign content to various taxonomies through folders, projects and channels, so that content can be cross-referenced extensively across your site. Put these taxonomies in the hands of people who don’t understand them and you’ll create convoluted user journeys: the exact opposite of your content management objectives.

Alterian’s corporate offering meanwhile — once known as Immediacy — provides pretty basic content management. Most users should be able to get their head around its tools pretty easily. But if you want to create more complex content relationships or have content fragments re-used across your sites, you’re better off with Alterian’s enterprise product, known as Morello. Devolving editorial responsibilities to part-timers who don’t fully understand the consequences of updating content that’s used in lots of places in your websites is decidedly risky, however.

In larger organisations, lots of people will produce content for the web sporadically. These people will change, have variable knowledge of the software and writing style guides, and limited understanding of your website. The last thing they need is a piece of software that allows them to break stuff because they just don’t get it.

So, do you:

  1. select a simple WCM for devolved teams to create pages in predefined templates; or
  2. select a complex WCM that enables you to perform more advanced content management tasks, but centralise the editorial process.

The more you want to cross-reference and re-use content across your sites, the greater your need for an advanced tool and an expert team to manage it. But if you want to devolve authorship, you’ll need to keep content management tasks and software as simple as possible. Don’t try to industrialise content production by providing everyone with more machinery. For broader participation you need to provide hand tools. Leave the combined harvester in the hands of experts.

Philippe Parker on , , , | 8 December 2009

Contented Management

Something rotten in WCM

J. Boye’s 2009 Arhus conference was a learned and often humorous affair. The biggest lesson I brought back from Denmark was just how far away all of us who work in the industry — website managers, technologists, vendors, consultants — are from having good web content management.
Chimpanzee performing Hamlet by King Chimp

Alas, poor clients

How many people could say that they were happy with their implementation? Even those case studies I saw were tinged with regret at missing features or how long the process took. The conference was littered with people who’d wasted budget and wanted to share their hindsight. And these were the enlightened ones.

The industry protests too much, methinks

But while those of us in the industry can easily put errors down to naïvety, I think it’s time we took a long hard look at ourselves. How can we tell users that CMS is like complex machinery which should involve substantial training and even change management? That’s an appalling attitude to user requirements.

Don’t try to make people change… do something that can’t already be done. (Euan Semple)

When every survey shows usability as the top area of dissatisfaction with CMS, what’s preventing vendors from making a friendlier system? As Seth Gottlieb points out, they’re all as bad as each other.

Slings (and boxes) and arrows

Creating and maintaining content should be simple enough for devolved editorial teams to perform with little training. The tricky thing is creating high quality content to suit an audience’s needs. Yet few CMS will ease editors through this process or evaluate their content against style guides. We’re beginning to see a few technologies in this area, but these are just sold as add-ons to an already bloated feature set.

The play’s the thing

It seems the industry has been blind to the truth. Features are specified but never used. Vendors add functionality so that they can score highly in analyst reports and avoid being excluded from shortlists, but all they’re doing is making it more difficult for users to create a compelling web presence.
To be or not to be
WCM was once a breakthrough in enabling less technical users to publish web content relatively quickly. But has it really progressed in the last few years? I don’t think so. We just have more modules piled onto re-skinned interfaces. Can’t we have friendlier tools for delivering a content strategy? Otherwise WCM will see some other application usurp its role and seduces its client base, which would be a tragedy for the industry.

More on #fixwcm

More on #jboye09

Philippe Parker on , | 10 November 2009

Contented Management

‘Bove the contentious waves he kept

Google Wave is a browser-based collaboration tool that combines messaging, document writing and discussions in real time. I participated by proxy in an experiment with the tool last week that involved fellow content management professionals. These are my observations.

Saying is easier than listening.

In many ways the collaboration was too real time. In a spoken conversation, talking across each other isn’t really possible. In the Wave, it’s the norm. Even with half a dozen participants, it seemed everyone was piling in trying to get their thoughts down rather than considering what people were writing elsewhere. There were multiple threads to the document that you couldn’t follow at once It was like being in the middle seat at a party: it seemed like a good place to be but you couldn’t figure out which conversation to jump into. This might say more about the participants than the platform, but it is a serious issue for collaborative working where listening to a conversation, being able to respond to the speaker and draw out more information is crucial to constructive dialogue.

More is easier than less.

Anyone can add to the document, but there are no commenting features and a social reluctance to delete what someone else has written. The effect is that assertions are qualified rather than challenged or deleted, meaning that you end up saying in thirty words what you could have said in ten. The compound effect of this writing style is that you layer meaning on top of meaning to the point that — as Julia Kristeva might have pointed out — as a group you’ve said something different to the individual’s original point. That’s not collaboration.

You get more than you need.

I couldn’t quite figure out what we got from the Wave that we couldn’t get from just a Google document combined with chat or a similar tool. It was less the case of the glass being half full or half empty than the glass being twice as big as we needed. There were too many features. Nearly everyone experienced serious browser issues — except Ian, whose virtual shoulder I was peering over— whose Chrome held out where Firefox faltered. Wave might run in a thin client, but it’s a fat piece of technology.

So was Wave a total washout? No, but I think it will take a lot of adapting to. If only there were some browser-based tool out there that wasn’t reliant on Ajax, that was near real-time but forced you to refresh so that you listened before you spoke and which encouraged you to be as brief as possible when you did speak up.

Where could we find a tool that met those requirements? I’ll have to ask the good people of Twitter.

Read more

Philippe Parker on | 26 October 2009

Contented Management

How to read Gartner

Gartner’s Magic Quadrant is stirring up emotions again. This time ZL Technologies have launched a law suit against the analyst firm, essentially claiming that its methods are biased and obscure. We’re not industry analysts, or partners of any of the vendors, so we’re not too bothered about who’s in Gartner’s good books. It makes a big difference to the vendors, however, since Gartner is such a dominant influence in the industry and so many clients assume that if a product’s in the Magic Quadrant, it must be the best.

And yet, this precisely contradicts Gartner’s own advice:

Gartner advises organizations against simply selecting vendors that appear in the Leaders quadrant. All selections should be buyer-specific, and vendors from the Challengers, Niche Players or Visionaries quadrants could be better matches for your business goals and solution requirements.

But what clients and many consultants see is the graph, and this is what they decide on. We’ve worked with many of the WCM products assessed by Gartner and conducted many technology selections for clients. They want the best product, not a niche player.

But what do you want to do with your CMS? Don’t you want to achieve things that other people aren’t doing, within business structures that will be difficult to change, aimed at specific audiences? Isn’t that a niche? Then why wouldn’t you consider a niche product?

Just because a vendor has a more complete vision, doesn’t mean it offers all the features that niche products do. In fact, the completeness of vision is based on many other criteria, including market understanding and strategy, sales strategy, business model and geographic strategy. These are all important, but do they really have a bearing on your business requirements?

We’d rather come and ask you what you’re trying to achieve, point out the things that any CMS will do and some of your issues that only certain products are likely to solve well. We’ll suggest you look at those but warn you about some of their weak points. If you’re then concerned that the vendor’s marketing strategy isn’t up to scratch, go and take a look at their financial viability. But every vendor Gartner assessed had WCM revenues in excess of $8 million in 2008,  so they aren’t small fry.

Nevertheless, you have to question the neutrality of a firm that takes a significant proportion of its revenue from advising the vendors on product development, but doesn’t disclose what that revenue is. As a buyer, you should question whether the criteria are relevant and whether the assessments are fair.

So what benefit can you get from the report?

Firstly, you get a list of products. That’s not a trite observation. In a market with several hundred vendors — and seemingly more each day popping out of the Scandinavian CMS womb — it’s useful to be able to limit the products you’re considering to those that have a considerable industry presence. Gartner will shortly be adding open source WCM to the proprietary software it currently evaluates.

Secondly, you get some ammunition with which to question vendors. If EPiServer is heavily focussed on expanding into the US market, you should be asking how much of their core team is still in Europe and able to deal with your concerns. (This is true of many of the European vendors.) Similarly, if you read between the lines on cautions about Vignette, you’ll need to ask how many of their clients are actually using the latest version of their product which they’re so keen to sell you.

So how should you read Gartner? With interest, and with caution.

Some further reading:

Philippe Parker on , , | 22 October 2009

Contented Management

Does rationlalisation reduce cost?

It’s a fair assumption to make that some organisations haven’t procured their content management systems as effectively as they might have done. Poor procurement is particularly frustrating when it’s done with our money, i.e. by government. But government in the UK is steeling itself for a major cost-cutting exercise. The Transformational Government agenda is already well underway, seeking to reduce the number of government websites and streamline online services. Meanwhile the political parties have competing missions to rethink procurement, particularly of technology. You can’t argue with the idea, and as Ian Truscott points out, there are good reasons for reducing the number of websites from a user experience perspective as well as just costs. However, you can certainly question the approach.

Let’s say you try to consolidate to a single content management system. The smaller the user base for that CMS, the more likely you are to meet its requirements. As soon as you extend the CMS to multiple teams with different ways of working, different audiences and different kinds of content, you have a change management programme on your hands. The focus has shifted from where it should be, online engagement, to training existing users in new ways of working.

Over-rationalisation tends to lead to over-generalisation, and that in turn leads to a poor fit to requirements. If you generalise too much, you’ll necessarily have to introduce customisation to your system, which was precisely what you were trying to avoid in the first place.

This isn’t the only area where too much rationalisation fails to reduce costs. While preferred supplier lists brings down the cost of procurement, they’re unlikely to reduce the cost of implementation. Qualification to be a preferred supplier is strenuous, but once you’re on the list there’s very little incentive to control your prices. Preferred supplier lists can make procurement inflexible and frustrating for the business users too. New entrants to the market are seldom present, so it’s nearly impossible for government departments to be early adopters. This makes government look like it’s off-message, when in reality many civil servants are swimming against the tide to provide a good service.

What government and many other large procuring organisations end up with is a possibly cheaper but probably riskier solution: over-ambitious projects that take too long to implement and that can’t meet emerging requirements. The larger the project, the more changes to requirements will emerge and the less rational it will become. These kind of strategic rationalisations are doomed to failure. To paraphrase John Maynard Keynes, your project’s business case can stay irrational longer than your project can stay solvent.

Rationalising your web presence is a great aspiration to have, but your have to rein in your ambitions. Rationalise a feature, not the whole system, then you’re more likely to see some cost savings.

Philippe Parker on | 19 October 2009

Contented Management

When should technology lead requirements?

How do you develop your content management requirements?

Typically, organisations will identify a business strategy, develop requirements based on that strategy to improve revenue or reduce costs, and then develop a software architecture based on those requirements. But when should the technology drive business change?

The simplest answer is “never”: don’t let the technology tail wag the business dog. But the simplest answer is rarely right. New technologies can lead to competitive advantage as well as stimulate innovation culture, so there should be room for a technology-led approach. You do need to establish some criteria for initiating these kinds of projects, however.

Emergent benefits but a defined problem
You may not know precisely what benefits the new technology will bring — this is particularly true of very new technologies that have little case history of ROI — but that shouldn’t in itself preclude assigning the project a budget. What should prevent you starting the project is not having a problem. This might be an operational issue such as ineffective project communications, or the opportunity to target a new market segment. But the problem needs to be there even if it’s not clear how the new technology will resolve it.

For example, online retailers have long had an issue with customer trust. People don’t buy products just because the website says it’s worth buying. But if you add the facility to comment on or rate a product, this gives some reassurance to the buyer. It improves sales markedly for some items, but risks reducing them for products that receive poor reviews. While it’s not 100% clear what effect customer ratings will have on your revenue stream, they do address the perceived trustworthiness of the product description.

If you want an example where this hasn’t worked, consider Second Life. Eighteen months ago, virtual worlds were the bandwagon to be on. It wasn’t clear what the benefits would be but it was technologically cool. The problem was that there was no problem. Second Life didn’t offer any real communication improvements while tapping a relatively small market that could be reached through other channels anyway. There may well be scope for virtual worlds in future, but they need to address a real business issue before they’ll take off.

Ability to deploy quickly
Since the rate of obsolescence outpaces the rate at which companies change [slideshare], you’d better be quick about your work. If it takes you a year to roll out a new technology, this should be business-driven, not led by a technology which will be old hat by the time it’s deployed. Software as a service gives companies a real advantage to deploy quickly, as do flexible server environments. You should certainly be looking at these kind of tools if yours is an organisation that likes to be at the leading edge.

Acceptable cost
How much money are you willing to risk if the technology doesn’t bring any benefit? This is a difficult assessment to make as you’re less likely to have a watertight figures than if you went down the more traditional business case route. Normally your assessment would be: my problem costs me £X, so if I spend £Y then I’ll get a return within Z months, so £Y can be my project budget. When you’re technology-led, you’re unlikely to know how long it will take to get a return. So you need to treat your budget as a sunk cost that you’re comfortable writing off.

This doesn’t necessarily mean that your budget must be small: the car industry spends a fortune on innovation because the risks of losing competitive advantage are so huge. Of course, you can limit your risk of failure by running a pilot, which will help you to satisfy the need to deploy quickly as well as constrain costs. Your project budget should be based on the scale of the problem you’re trying to solve, rather than on the scale of anticipated benefits.

Exit strategy
If the technology isn’t as successful as you’d hoped, or it’s viable but creates other problems you hadn’t forseen, you need a cost effective way to abandon it. This is particularly relevant for information management projects. If you put business critical information into a new wiki that has poor adoption, you absolutely need a way of getting that information back in a format that can be migrated to another system. Your project needs to include a decommissioning approach.

Ride the wave
Technology should inform your business strategy, but being at the crest of the hype cycle isn’t enough. If you apply these criteria to technology-driven projects however, you should go some way to avoiding the trough of disillusionment, both emotionally and financially.

Philippe Parker on 29 September 2009

Contented Management

The importance of good metadata

There’s been some debate on the role of metadata in content management: is metadata the future of content management, an integral part of the content, or are we making an artificial distinction?

Let’s start by setting aside the technological issues, because these are largely irrelevant. Metadata may be stored in a database separate from a file, or in a distinct table, or marked up differently, but this isn’t the determining thing that makes it different from other data or content held in a system. It can even be an inherent part of a document. What makes metadata different is how it’s used.

Metadata is used for classification. It’s used to relate one piece of content to another and to help people and systems find relevant information. If it’s not serving that purpose then it’s not metadata.

This may lead you to the conclusion that I’m saying everything is metadata. But it’s not. Some content that is marked up as metadata isn’t really metadata at all, or is at best poor metadata. Take a look at the UK’s National DNA Database, for example. This database records ethnicity and skin colour as a way to search for people, but one person’s view of their ethnicity may not be shared by another’s. This disparity has effectively rendered this metadata set useless. The records on ethnicity and skin colour are potentially useful as content, but unreliable as metadata.

So if you’re looking to define metadata types and corresponding taxonomies for your content, you have to consider how those doing the classification will apply the metadata and how other people are going to use that classification. If it’s not useful, it’s not metadata. If it is useful, you’ll be on your way to managing your content.

Philippe Parker on | 18 September 2009
Older Posts »