Articles by Category: Content management

How to improve intranet content? (a mindmap)

There are many ways of improving the quality and value of intranet content. To progress discussions on this topic, we've produced a mindmap that brings together almost a hundred ideas. Download the PDF (72kb), and print it on a big piece of paper.

This can be used in a number of ways:

• Highlight on the mindmap all the activities and ideas you are already doing, and identify where the gaps lie.
• Conduct further research into potential ideas and approaches, using the mindmap as a starting point.
• Clarify team and individual responsibilities relating to intranet content.
• Help the team to break out of old habits, giving an opportunity to consider new ideas.
• Gather together the intranet team and decentralised authors, and use the mindmap to discuss the current situation, and possible improvements.
• Demonstrate to management the work that the intranet team does to help deliver good intranet content.
• Compare notes between intranet teams, using the mindmap to identify differences and similarities.
• Use as a framework to structure discussions and activities at intranet conferences and other gatherings.

This is version 1.0, released in the spirit of helping all intranet teams. It's also helped us to get all our ideas on a single piece of paper. Please do send us a message if you have any comments, suggestions or ideas. We'll then incorporate these, and released updated versions when appropriate.

Posted by jamesr at 01:24 PM | Permalink
Categories: Content management, Intranets

Enhancing dashboard value and user experience

Joe Lamantia has published the fifth article in his series on dashboards and portals. To quote:

Portals gather and present content from a wide variety of sources, making the assembled items and streams more valuable for users by reducing the costs of content discovery and acquisition. By placing diverse content into close proximity, specialized forms of portals, such as the dashboard, support knowledge workers in creative and interpretive activities including synthesis, strategy formulation, decision making, collaboration, knowledge production, and multi-dimensional analysis.

Posted by jamesr at 10:40 AM | Permalink
Categories: Content management, Information architecture, Information management

Don't try to boil the content ocean

The phrase 'trying to boil the ocean' refers to tasks that are clearly and heroically impossible. This is exactly what most teams take on when they try to get every intranet page up to the same high standard.

In the earlier article titled Intranet authoring: a hobby?, the role of intranet authors was explored, highlighting that many are required to maintain their content 'on the side', with little training or support.

Most intranets struggle to deliver consistent, accurate, readable and valuable content. Despite this, the goal of many intranet teams remains to deliver universally 'good' content.

This briefing will discuss common approaches to improving content, focusing on those that have failed. Suggestions will then be made on ways to target efforts for best effect.

Failed: content cleanups

Many teams attempt a content cleanup on a regular basis, perhaps every year or two. These involve reviewing most sections of the site, and the content contained within.

These reviews are looking for ROT (redundant, outdated or trivial), generating 'hit lists' of content that can be removed.

While these very easily remove hundreds or thousands of pages, the long term impact is negligible. As fast as content is reviewed by the central team, more is published by decentralised authors.

The process drains the energy of the intranet team, and often frustrates content owners. Even after a major cleanup, the intranet rapidly accumulates more content problems, and reverts to its previous state.

[CM Briefing 2008-06, read the full article]

Posted by jamesr at 08:45 AM | Permalink
Categories: Content management, Intranets, James' articles

Wikis in the Enterprise

Wikis are spreading like wildfire within organisations, driven by their quick setup and comparatively easy use. As yet, however, little has been written on how to make wikis work well.

That is why the new report from J. Boye, titled Wiki in the Enterprise is so valuable. Many have written about the potential value of wikis, but this work talks about what has worked in real-life (and what hasn't).

Drawing upon research done in a number of organisations, this report discusses the reasons for deploying wikis, the cavets, and how wikis meet reality.

Most importantly, this reports a range of practical and pragmatic recommendations on how to setup and use wikis. These will give teams a valuable leg-up when approaching this new publishing technology.

A recommended addition to the dialogue on wikis, and I'm looking forward to future reports from J. Boye.

Posted by jamesr at 02:40 PM | Permalink
Categories: Content management, Intranets, Knowledge management

More reasons that a content management company will go out of business

George Dearing has listed more reasons that a CMS vendor will go out of business. To quote:

The next five reasons on my list come from an ECM executive who asked to remain anonymous because he said it would be too obvious which company he's talking about, and he's already been accused of having a bad attitude. Because that was such an interesting comment, I've decided to add it in as reason 5-1/2 that a content management company will go out of business:

Posted by jamesr at 09:33 AM | Permalink
Categories: Content management

Benefits of plain english URLs

Gadgetopia has written about the benefits of plain english URLs in a CMS. To quote:

The plain-english URLs are more memorable to the customer, and they impart some meaning. When picking URLs, we envison someone at the client’s firm reading the URL to someone over the phone. How easy is it going to be?

Posted by jamesr at 09:49 AM | Permalink
Categories: Content management

Top 5 reasons a content management company will go out of business

George Dearing has written a list of 5 reasons a CMS vendor will go bust. To quote:

Several months ago a content management vendor told me that the oncoming recession was causing it problems with revenue generation. I said perhaps, but it's also possible its problems were related to the fact that its customers were really angry and really vocal. It's too easy to blame market conditions without taking a hard look in the mirror sometimes.

Posted by jamesr at 04:50 AM | Permalink
Categories: Content management

Menuing in content management: implicit vs. explicit

Gadgetopia has written an article on implicit vs explicit menuing, when using a CMS. To quote:

Navigation is often a pain when it comes to content management. Now, don’t confuse “navigation” with information architecture — that grand plan of what goes where in relation to what.

By “navigation,” I mean “menuing.” It’s less theory, and more practical application of how do you get a specific group of links in a specific spot on a page, and make sure the right group of links shows up with the right content?

Posted by jamesr at 06:07 AM | Permalink
Categories: Content management

In-context vs back-end authoring

Most modern content management systems provide two different ways of editing site content: in-context editing and back-end editing.

While in-context editing is often seen as 'sexier', each method has its strengths and weaknesses. This briefing will explore these two editing options, providing advice on when to use them in practice.

In-context editing

In-context editing allows authors to browse the published website, using site navigation in the normal way to find the desired page.

By clicking a small or hidden button (or some other equivalent action), they can switch into editing mode, updating the content of the page in place.

During editing, the author can see how the published page appears, including the formatting of the text. By updating the content 'in context', the author can immediately see the finished product, even as changes are being made. Depending on the vendor, this functionality may be called different things, including 'live site editing', 'in place editing' or 'surf-to-edit'.

The big advantage of this method is its simplicity. Authors are familiar with the structure of the published site, and comfortable with navigating through it.

By hiding most of the underlying complexity of the CMS, this alllows authors to concentrate on updating the content.

For these reasons, in-context editing is often seen as the more usable authoring option. It is also commonly seen as a more 'modern' option for updating the site.

In-context editing is not without weaknesses. The very simplicity of the interfaces makes some tasks harder, or at least, less obvious.

[CM Briefing 2008-04, read the full article]

Posted by jamesr at 12:12 AM | Permalink
Categories: Content management, James' articles

Clean up your LDAP or Active Directory

A lot of intranet and portal projects aim to deliver functionality related to personalisation or customisation.

This may involve tailoring information based on staff role, delivering news relevant for specific offices, or limiting access to information based on seniority.

Any of these capabilities requires the system to know who staff are, the business unit they belong to, and where they sit in the real world.

Unfortunately, too many of these projects run aground before they start because a key piece of IT infrastructure has not been correctly put in place.

LDAP and Active Directory

Sitting invisibly behind the scenes in organisations is the 'authentication' platform run by IT. In simple terms, this contains the usernames and passwords staff use when they log on to their PCs each morning.

Over time, these details have been migrated into one of two standards: LDAP (an open industry standard) or Active Directory (the Microsoft variant of the same thing).

These expanded 'directory services' have the ability to store much more than just names and passwords. If configured to do so, they can contain all the information that is in the internal phone directory or staff directory, including job titles, business unit names, locations and more.

The most obvious benefit to come from putting in place these new standards is the progressive move towards 'single sign-on', allowing one username and password to be used across a wide range of corporate systems.

Crucially for intranet and portal projects, LDAP or Active Directory is also the source of the information needed to drive personalisation and customisation.

[CM Briefing 2008-03, read the full article]

Posted by jamesr at 12:08 AM | Permalink
Categories: Content management, Information management, Intranets, James' articles

A case for Movable Type as your Intranet

Gadgetopia have written an article on using Movable Type as your intranet. To quote:

Here’s a fact: intranets don’t have to be crazy-complicated. Intranets are fundamentally about sharing simple information, which is not as hard as some people make it out to be. As simple as this is, most organizations either have no intranet, or a smattering of HTML pages someone threw together with Front Page that no one looks at.

I’m all for keeping intranet technology simple, but I think this article misses the point.

I’ve previously identified four fundamental purposes for an intranet:

• content
• communication
• collaboration
• activity

I would see a lightweight publishing solution such as Movable Type as being a pretty good fit for the communication component, but perhaps not the rest.

The content aspect needs to be supported by decentralised authoring, and MT just doesn’t support this in a scalable way.

The collaboration aspect pretty much always needs to be supported by additional software, whether it’s wikis or SharePoint.

The activity aspect is the big gap, as it is for most intranets. If the intranet is just a “place for reading stuff”, it won’t succeed. Instead, it also needs to be a “place for doing stuff”, and this obviously isn’t MT.

In summary, we need to take a broader view of intranets, if they are to be valuable and used. This doesn’t necessarily mean more complex (or more expensive!) software, but it does mean we need to be careful about not getting trapped in one particular box.

PS. you can read an earlier article describing was then the “three purposes of an intranet”. In the way of these things, collaboration was (sensibly) added shortly after this article was released, giving a much more complete picture.

Posted by jamesr at 11:45 AM | Permalink
Categories: Content management, Intranets

Think like a user

Ann Rockley has written an article on thinking like a user when designing documentation. To quote:

When assembling a document (or creating the required information the first time), it’s important to ask not ‘what do I need to see here?’, but ‘what does the user need to see here?’. The differences may be small, but they are often important.

Posted by jamesr at 09:09 AM | Permalink
Categories: Content management, Usability & user-centered design

Composite pages and embeddable content

Gadgetopia have posted an article on composite pages and embeddable content. To quote:

A composite page is a single page, made out of pieces. Your users can add a “Page” to the system, then add “Sections” to the page. They can pick from different types of sections, like “text with header,” “text with image,” “centered image,” etc.

The idea is that you stack these sections on top of each other, order them, and when the page is rendered, its sections are rendered in sequence from top to bottom.

Posted by jamesr at 08:00 AM | Permalink
Categories: Content management

Measure twice, cut once with web CMS

The CMS Myth have published a piece on measure twice, cut once when it comes to CMS projects. To quote:

Carpenters, of all people, have a great saying, one that everyone responsible for a CMS project should tattoo on their forearm, or at least write on their office wall in big red letters: “Measure twice, cut once.” It’s just four simple words, but oh-so-rich in wisdom and rife with pragmatism.

Posted by jamesr at 09:57 AM | Permalink
Categories: Content management

The Content Wrangler Community

A new social network for content management folk has been recently launched: The Content Wrangler Community. It's early days yet, but anything that helps to connect those working in this challenging field must surely be helpful. Connect up and start chatting...

Posted by jamesr at 07:40 AM | Permalink
Categories: Content management

Enhancing dashboard value and user experience

Joe Lamantia has written an article on enhancing dashboard value and user experience, the fifth in a series of articles on designing portals. To quote:

Portals gather and present content from a wide variety of sources, making the assembled items and streams more valuable for users by reducing the costs of content discovery and acquisition. By placing diverse content into close proximity, specialized forms of portals, such as the dashboard, support knowledge workers in creative and interpretive activities including synthesis, strategy formulation, decision making, collaboration, knowledge production, and multi-dimensional analysis.

Posted by jamesr at 03:00 PM | Permalink
Categories: Content management, Information architecture

A moderated approach to user-generated content

Marisa Peacock has written an article on moderation and user-generated content. To quote:

Adding it all up, user-generated content isn’t the menacing monster that legal feared it to be, after all. In fact, with more people moderating than generating, it seems that user-generated content is apt to be more self-censoring than most editorials.

Posted by jamesr at 06:56 AM | Permalink
Categories: Content management, Enterprise 2.0

Open challenge to CMS vendors

CMS products have come along way in the last five years in terms of functionality and usability. They now (mostly) deploy quickly, are reasonably easy to use, and are a lot cheaper. This is all good.

As I've discussed many times, the usability of CMS products is crucial, and there is a lot more to be done on this front. In particular, CMS products should match the "mental model" of authors and site managers, something that they often don't do. The confusion of different terms, concepts and philosophies doesn't help.

This is still not enough. I want to present an open challenge to all CMS vendors:

Content management systems need to much closer match the reality of how content is created, managed and published. They must also do more to help resolve the fundamental challenges that led organisations to purchase CMS products in the first place.

Despite the profusion of content management systems, each with its own ideas and models, there is surprising similarity in how they operate at a basic level. The concept of "workflow" is more-or-less universal across products, as is metadata, review and expiry dates, and the like. Underpinning this is the idea of a "publishing process" in a traditional sense, replicated from print to the online world.

The problem is that this doesn't actually match reality. As I've said in the past, workflow doesn't work, organisations still struggle to manage their content even with a CMS, and few manage to capture the metadata they require.

Indeed, it is questionable whether installing a content management system really resolves the problems it promised to. One of the reasons is that vendors haven't really put in the effort to really design their products to best help authors and site managers. Rather, they are happy to simply follow the "way things are done", even if these ways demonstrably don't work.

My challenge to vendors is therefore to conduct user research to deeply understand how their clients are working with web content, and to revise their products to better match this reality. This will dramatically improve the success rates of CMS projects, which in turn helps the vendors.

Let me give some examples to put some shape around my rantings:

• Content reviews

  One of the fundamental challenges is to keep web content up-to-date, particularly in a decentralised authoring environment. The standard way CMS products endeavour to meet this need is via a "review date" for each page. This may be fixed to yearly (bad idea!), a chosen date, or a selection of possible periods (three months, six months, a year, never).

  When the review date is reached, an email is sent to to the author of the page, who may or may not be the actual content owner. The hope is that the author will then review and update the page (if required). Site managers may get a report listing pages overdue for review.

  The problem is that none of this really works in practice. Authors often ignore the reminders, and site managers need much better tools to track and manage the review process. How can we do this better?

• Metadata

  It's notoriously difficult to get decentralised authors to enter metadata. It's even harder to get them to enter good metadata. In practice, metadata quality is mixed, with basic problems such as a mix of singular and plural terms (for example).

  Site managers are generally given no tools to monitor, manage or improve metadata at a site level. There is no single list of metadata terms that allows global changes and cleanups to be made. Authors are given little help in entering useful metadata terms.

  Professional indexers and taxonomists have been asking more functionality for years. Why haven't they got it?

• Workflow

  I've said a lot about this already. So all I'll say: why haven't we implemented a publishing model that actually matches how content is created and released?

(These are just a few simple examples, and other similar situations can be found across every aspect of content management systems.)

Note that I'm talking about improving the core design of content management systems. Yes, web 2.0 and enterprise 2.0 provide valuable new ways of looking at all of this, but the basics still need to be right.

I ask again of vendors: please do the work needed to make your products work better in the real world, even if it means challenging some of the ways "things are done".

So, thoughts and comments? (As usual, in the continued absence of commenting, please email me and I'll post the highlights.)

Posted by jamesr at 07:27 AM | Permalink
Categories: Content management

Clarify. Simplify. Implement.

Nathan Wallace has written about his clarify - simplify - implement approach to information management. To quote:

Relentlessly question, review and challenge the processes and solution being developed. Drive for consistency. Search for well-known models or applications you can copy. Don't be afraid to change basic assumptions, where simplicity can be enhanced. Always challenge the value of edge cases and try to eradicate them. Work hard to remove every single process, click, page view, icon, etc until you have something so simple that it feels right to everyone involved. (This is the primary value adding activity for IT.)

Read this post several times, as it contains important insight. Nathan is a CIO with a deep technical background and a thoughtful approach to everything that he does. In these three words, he outlines a radically different approach to designing and deploying enterprise solutions. Great stuff!

Posted by jamesr at 07:01 AM | Permalink
Categories: Content management, Enterprise 2.0, Information management

Designing your information architecture for content reuse: five best practices

Amber Swope has written an article on content reuse. To quote:

The increasing popularity of Darwin Information Typing Architecture (DITA) means that more users within an organization are looking to repurpose and reuse content across the enterprise. To realize the promise of reuse with DITA, you must optimize the mechanisms it supports and understand how to implement it. When considering the implementation of a reuse strategy, consider the following five best practices.

(Note: this article is pretty technical, and assumes fair bit of background knowledge of DITA. Not for the web content management folks.)

Posted by jamesr at 09:55 AM | Permalink
Categories: Content management

Wiki markup: the followup

It seems that despite my inflammatory post arguing that wiki markup must die, I haven't yet been tied to a stake and set fire to. In fact, I've received quite a few emails strongly agreeing with my position, and in lieu of working commenting, I'll share a few in this post.

Wiki developers take note: there's limited patience for wiki markup, and a very real marketplace demand for something better!

And the comments:

I absolutely agree with this. I would only dream of using a non-WYSIWYG wiki with geeks. It should be like using Word - but, y'know, collaborative. And simpler. Matt Moore

Love it and totally agree - something I have been grumbling about for ages - even tho it flies in the face of what geeks demand.

The only statement that seemed odd was: "Wikis are about making creating and editing content trivial". I'd be more inclined to say "easy"... Or something, rather than trivial. But I am probably splitting hairs. :)

Russ Weakley

You are my hero. Thank God someone with an audience finally said this.

Couldn't agree more!

Kevin Crossman

I agree wholeheartedly!

If the history of computing, word processing and web has taught engineers and programmers anything it should be that most people don't want to become programmers - and shouldn't be forced to.

I'm a big fan of the WYSIWYG approach.

Craig Thomler

I suspect you're only partly right. WikiMarkup is pretty pointless if you're just writing prose, but thats not all that some Wiki's do.

TWiki for example has an application language that allows the user to define data schema's, and applications directly in TWiki topics.

The other odd thing about your post, is that as far as I know _most_ Opensource Wiki's have wysiwyg editors available - TWiki has several options, starting with TinyMCE as the most robust (and newest addition), Kupu as the previous attempt, and then Wikiwyg and others.

We are also looking towards adding a Wysiwyg editing tool for the application development.

Sven Dowideit

I just want to say thank you for your article on wiki markup. It provides a good summary of why wiki can be a content management issue. Your list of editing requirements is also very useful.

I've discovered myself that wiki content is a deadend. We've been running Mediawiki here at the Council, and unfortunately someone put a great deal of content into it that should really be in HTML pages.

Now I found it is very difficult to automate the process of getting the content out. Even copying and pasting from the browser doesn't work, because it collects the navigation with it. There appears to be many tools and pieces of software available to convert content into a wiki format, but I have not found anything useful to go back the other way. Perhaps people just don't do this?

We're now manually moving the wiki content back into our WCMS, which, being Interwoven Teamsite, will mean it is in XML format at least, and reasonably easy to move into other systems in the future.

Greg Comfort

Posted by jamesr at 08:22 AM | Permalink
Categories: Content management

The RFP is dead! Long live the RFP!

Seth Gottlieb has written an entry on effective RFP processes. To quote:

There has been an interesting thread on the CM Professionals mailing list discussing the efficacy of an RFP. Many participants cited frustration with an RFP process that wastes people's time with unnecessary formality and the pretension of an even contest. I think everyone who has been in business has witnessed the act of an RFP being distributed after the contract has been awarded. The RFP process, as it is commonly practiced, suffers from four major flaws.

(This is a followup to my original post on the topic.)

Posted by jamesr at 08:21 AM | Permalink
Categories: Content management

Wiki markup has no future

Ok, I'm going to confront the elephant in the room: wiki markup has no future. I know I'm going to burnt at the stake by all the wiki fanatics, but let me give a few reasons...

Back to the future

Back in the bad old days, you needed to know all those strange HTML tags in order to publish a web page. Recognising that this wasn't desirable, we've worked very hard to develop publishing tools (FrontPage, Dreamweaver, content management systems) that eliminate the need for this knowledge.

While these tools are still imperfect, they have done much to open up the web to non-technical authors and publishers. Certainly in any serious situation, WYSIWYG is expected, and often demanded.

So along comes wikis, and voila, a new set of markup to learn! Suddenly we're back to putting stars for bullets, three equals signs for a horizontal rule, etc, etc. How is this a forward step?

It's about the users

Wiki markup is not easy, and it takes some learning. I'm a former developer, but even I have to have a reference sheet handy when I start to use a new wiki tool.

The lack of WYSIWYG editing is a big barrier to adoption within organisations, and on the wider web. There are only a limited number of users that have the time, skills and inclination to learn wiki markup. It's a fundamental usability problem, and the spread of wikis will always be niche as long as wiki markup remains.

They're all different

It doesn't help that all the wikis have invented their own set of special markup. Similar, but different enough that each wiki needs to be learnt separately.

Yes, I know there are moves towards coming up with "standard" wiki markup, but that misses the point. There's no future in wiki markup, so who cares if it's standardised!

It's not about the markup

It was never about the markup anyway. Wikis are about making creating and editing content trivial, about creating structure as you go, about tracking changes and activity (plus more). The "wiki way" never demanded the use of strangle little text commands.

It could even be argued that the wiki way is all about usability, so wiki markup is actually opposed to the core principles being pursued. What could be easier than just typing straight into the wiki, with buttons for formatting?

WYSIWYG

What I want to see in the wiki editing environment:

• Full WYSIWYG editing
• Simple, locked-down formatting (bold, italic, paragraph styles)
• Point and click image insertion
• Simple table creation and editing
• Easy mechanism for creating links
• Seamless cut-and-pasting from Word (stripping out the rubbish)
• Spell-checking
• Multiple levels of undo

In other words, all the basics that you would expect in any editing environment, online or desktop. Note that this isn't changing any other aspects of wikis, that's the good stuff, it's just fixing the editing environment.

Into the future

I'm not surprised that open-source wikis don't have WYSIWYG editing, but that's no excuse for commercial offerings. This needs to be resolved immediately, and taken seriously by wiki developers. More than just an average WYSIWYG editing tool, this needs to work extremely well.

I would go one step further: don't deploy a wiki for a broad audience (or within the enterprise) if it doesn't have WYSIWYG editing. That will start to put some pressure on the developers, and should help to speed the permanent death of wiki markup. RIP and long live wikis.

(As ever, apologies for the lack of blog commenting. The site redesign and upgrade now has light at the end of the tunnel, so hopefully soon! Feel free to email me in the meantime.)

[Followup: I've posted some of the comments I've received on this topic, seems like I've struck a chord with some.]

Posted by jamesr at 03:04 PM | Permalink
Categories: Content management, Enterprise 2.0

Death to the RFP?

When I posted my recent article on Time needed to select a CMS to the CM Pros mailing list, it generated a lot of discussion. This included a number of people who questioned whether organisations should be going through a RFP/tender process at all. I thought I would post my thoughts here, as well as replying on the list...

The dislike of RFPs not surprising. For my own part, I have seen more pointless, wasteful, poorly constructed, and poorly thought-out RFPs to fill an entire life!

The gut reaction is therefore unsurprisingly to reject them entirely. I'm going to argue against this.

There are a lot of products in the marketplace, 140+ in Australia alone with an estimate 1,000 globally. I've often said that these are only 30% similar and 70% entirely different in how they operate. (Even if all the marketing brochures read the same.)

It's a complex marketplace, and it is far from easy for organisations to be confident they are selecting the right product. Where there is a lack of experience or clarity around the needs, this is even worse.

I like a lightweight RFP/tender process for helping resolve these issues, even where it isn't formally required.

It does several things:

• it ensures that requirements are thought through and documented
• the scope of the project is clarified and communicated
• vendors are asked to "put themselves on the line" in their response
• it helps organisations to make informed decisions in cutting down the list to a final few
• it ensures that organisations spend some time thinking and learning about products (and their own requirements!)
• it gives internal stakeholders an opportunity to be involved
• it builds confidence in the final outcome

We do a lot of work helping organisations select a CMS, in both the public and private sectors. We help organisations write good requirements, and provide an initial list of potential solutions (5-7 in our case). Written responses then quickly drop this to 3, for the vendor demonstrations.

In my personal experience, the greatest amount of time is lost when an informal or poorly-defined selection process is followed, leading to lots of wandering around and head-scratching.

I also don't believe it is ethical for me as the "expert" to say "here, pick this!". Life is simply too complex for that, and it ignores the many compromises that will need to be made. (We would also not be truly vendor neutral!)

Frankly, if we go through anything less than this, picking a product becomes no better than "rolling the dice and hoping your number comes up".

So, death to the awful RFPs, and long live sensible, structured selection processes!

Further reading:

• Top 10 mistakes when selecting a CMS
• Using scenarios to select a CMS
• What is the purpose of a CMS tender?
• Requirements-focused CMS selection

Posted by jamesr at 07:09 AM | Permalink
Categories: Content management

How many people does it take to screw in a content management system?

The CMS Myth have posted an item on the roles needed in a CMS project. To quote:

I'm the first to agree with limiting the number of cooks in the kitchen, yet it's hard to ignore the fact that building websites today does require more specialized skills (and processes that can effectively integrate them). In fact, when it comes to CMS implementations, I've found that many projects go off track when the wrong people do the wrong tasks (i.e. Developer doing information architecture).

This prompted the question of 'how many people does it take to screw in a content management system?' A cynical myth buster may say 'you don't screw them in, they screw you' – but we're staying positive here.

Posted by jamesr at 06:40 AM | Permalink
Categories: Content management

Component content management: what is it and why does It matter?

Paul Trotter has written an article on component content management. To quote:

In this article, I will try to explain what content management is and how it can help your organization more efficiently write higher quality and more effective documentation, re-use and share content across documents, have strict control over standards and branding, publishing that content to print, help, and web formats, and significantly reduce the cost of localizing your content.

Posted by jamesr at 06:15 AM | Permalink
Categories: Content management

Time needed to select a CMS

It will always take longer than hoped to select a new content management system. While an 'accelerated' approach can be taken, the reality is that somewhere between 6 and 12 months will probably be needed, from beginning to end.

To help clarify this statement, this briefing provides a breakdown of the individual steps and the amount of time needed for each. Use this to set appropriate stakeholder expectations, and to develop a realistic project plan.

Selecting a CMS: step-by-step

[CM Briefing 2008-01, read the full article]

Posted by jamesr at 09:04 AM | Permalink
Categories: Content management, James' articles

Content managers: extract the full benefits of structured authoring

Eric Kuhnen has written an article on structured authoring, focusing on DITA in particular. To quote:

DITA's design for content reusability is akin to an interchangeable part in manufacturing. In industrial manufacturing, a part is considered interchangeable if each and every copy is identical to the original. In content manufacturing, an interchangeable part is a reusable, self-contained topic. When the topic is needed in a new publication, the writer inserts a pointer to the archived original; no cut-n-paste; no editing to fit context. DITA gives technical publication managers one of the key technologies to establishing a true content assembly line: the interchangeable part.

Posted by jamesr at 01:18 PM | Permalink
Categories: Content management

The top ten mistakes of web CMS projects – and how to avoid them

Michael Silverman has written an article on the top ten mistakes of web CMS projects. To quote:

Maybe you are beginning to think about developing a content management systems for your organization's website. Or maybe you are just about to start a CMS project. In either case, you are probably wondering how to improve the chances of a successful outcome, considering the large investment at stake.

This is a good article, and it sits well alongside my Top 10 mistakes when selecting a CMS article, published last year.

Posted by jamesr at 07:07 AM | Permalink
Categories: Content management

Pain in the SaaS? When your traditional software vendor hosts your application

Tony Byrne has written an article on software-as-a-service models for CMS products. To quote:

As a buyer you should understand that contracting with a supplier simply to host and customize traditional software is not the same thing as working with a well thought-through, "native" Software-as-a-Service (SaaS) solution that was built from the ground up by a company dedicated to providing such a service. There is a case to be made for outsourcing application hosting and support, as well as a case for true SaaS. Just make sure you know the difference -- and know what you're getting in either case.

Posted by jamesr at 06:00 AM | Permalink
Categories: Content management

Changing nature of intranet content

Richard Dennison writes about the changing nature of intranet content at BT. To quote:

ALL content is collaborative - what varies is the degree of collaboration involved in the four steps outlined above. So, even content that we had previously defined as 'static' (e.g. an HR policy document) will have involved collaboration in its generation and should have an element of collaboration during its consumption phase (i.e. users should be able to comment on it and/or rate its value in terms of meeting users' needs). What's interesting, is that the pre-publication collaboration used to be done off-line (in meetings or via e-mail) which is why it appeared 'static', but is now likely to be done on-line, for example, in shared workspaces in wikis, which now makes it appear to be 'collaborative' content.

Posted by jamesr at 08:07 AM | Permalink
Categories: Content management, Intranets

Bottom-up approach to taxonomy development

Simon Goh has written about a bottom-up approach to taxonomy development. To quote:

In my previous post, I brought up a topic on the implementation challenges of taxonomy and suggested a few points on overcoming pitfalls for multi-faceted taxonomy implementation. This time round, my reflection is based on ground 0, where there is no corporate taxonomy design to start with. This idea requires incremental and continuous investment and its not a short project period affair. Like the Chinese saying goes, "Cast a long line to catch a bigger fish".

Posted by jamesr at 07:00 AM | Permalink
Categories: Content management, Document & records management, Information architecture

Are you making the right CMS promises?

The CMS Myth has written a piece asking: are you making the right CMS promises? To quote:

We talk a lot about the expectation gap between vendors that beat the drum of 'out of the box,' and 'easy' compared to the reality on the ground of a complex implementation. But it's time to take a closer look at what promises we're making internally inside the organizations before deploying a CMS.

Posted by jamesr at 06:50 AM | Permalink
Categories: Content management

To structure or not to structure

Gadgetopia have written a superb post on the pros and cons of structuring content in a CMS. To quote:

We were meeting with a client the other day about applying some content management to their Web site. We came upon a page of “business partners.” It had a repeated HTML structure consisting of a logo for the partner, their name, their URL, and a few paragraphs about them. There were maybe a dozen or so partners listed.

I agree with everything written in this post, and I've had this discussion many times as part of the CMS selection work I do with clients. I would add, however, another downside to the template approach ("Structured as a single content object"). All too often, I've seen the number of templates multiple like rabbits, to cover each small variation on a theme. Before you know it, you have 150 templates that the authors have to choose between before publishing a page. Hardly an ideal solution.

Posted by jamesr at 07:19 AM | Permalink
Categories: Content management, Information architecture

Pick the right content management approach

Tony Byrne writes about picking the right content management approach. To quote:

The lines between all content technology families are notoriously blurry. This is especially true of portals, Enterprise Content Management (ECM) systems and Web Content Management (WCM) system, where there's lots of overlap in vendors, product functionality, and marketing messages. For example, if you're looking to implement Intranet-based document management, you could conceivably use any of these three types of products. Yet some consultancies will try to sell you all three types of solutions, with an obligatory (and expensive) integration project.

Posted by jamesr at 09:24 AM | Permalink
Categories: Content management

Twelve Predictions for 2008

CMS Watch has published their twelve predictions for 2008. To quote:

It's that time of year again. The CMS Watch analyst team ponders what to expect next year, and offers 12 predictions that we think will shape content technologies in 2008.

Posted by jamesr at 12:32 PM | Permalink
Categories: Content management

A holiday CMS wishlist

Tony Byrne has published his holiday wishlist for CMS products. To quote:

• A broad set of plain old java objects for core content technology services (to run in any of our favored JVMs), which we can deploy independently of each other on an a' la carte basis to create our own custom content applications
• XHTML-compliant and WCAG-friendly application UIs

Posted by jamesr at 05:25 PM | Permalink
Categories: Content management

All universities are equal...

Adriaan Bloem has written a post about university websites. To quote:

Usually, where universities come from is the same: academia was among the early adopters of the nascent technology and many ventured out on the web in the early nineties. With the archipelago of departments, institutes, faculties, over a decade many managed to produce hundreds of thousands or sometimes millions of published web pages. Often using different styles, editors, webservers, then CMS tools -- it's not uncommon to find hundreds of (sub)domains within a single institution.

We've been doing a lot of work with universities over the last year or so, and have observed all of the same issues and challenges. After a while, we worked out that universities are uniquely challenging environments because they are the only place that doesn't have a shared sense of corporate identity. You don't work for the university, you work for the School of Dentistry.

We're now seeing university web strategy projects as a piece of organisational change, not as "create a document" projects. I think there's some valuable progress to be made via this approach, but we're still in the early stages of exploring what it means in practice...

Posted by jamesr at 05:55 AM | Permalink
Categories: Content management, Information architecture, Web development

Content approval workflow for the intranet

Simon Goh asks: do we need workflow for intranets? To quote:

In my opinion, organisations need to adopt an open culture towards the sharing of information. A culture that permits mistakes and then improvements as a collective organisation. And in an Intranet environment, this means no content approval workflow.

I agree completely with this, and I think a well-used intranet where mistakes are quickly corrected is more effective than a rigid pre-publishing approval process.

Posted by jamesr at 07:19 AM | Permalink
Categories: Content management, Intranets

CMS business case

Seth Gottlieb has written a post on creating a CMS business case. To quote:

In my opinion, the business case discussion should be around the content itself - not the technology used to manage it. This is a difficult conversation to have for a number of reasons. First of all, the human effort required to manage content (no matter what tools you have), while very costly, does not have a big spending event that triggers an ROI conversation. The expenditures from managing content (or the cost of not managing it) happens in drips and drops but it can really bleed a company. Secondly, there is a misperception that all content is good and worth managing.

Posted by jamesr at 10:52 AM | Permalink
Categories: Content management, Metrics & ROI

The four disciplines of content management

Gadgetopia have published their definition of the four disciplines of content management. To quote:

A lot of stuff gets lumped under the heading “content management.” In my experience, however, all the technical activities under the banner of content management can general be broken out into four disciplines.

Posted by jamesr at 11:18 AM
Categories: Content management

Planning & sustaining wiki-based collaboration projects

Maish Nichani has written an article on planning wiki-based collaboration. To quote:

Many organizations are experimenting with wiki-based collaboration projects. But only a small percentage of these projects make it past the initial excitement or pilot phase. One of the reasons for the drop-off is that there's not enough thought given to them other than deciding which wiki product to install. This article presents a framework that can help groups wanting to use wikis for internal projects better plan and sustain their collaboration efforts.

Posted by jamesr at 04:10 AM | Permalink
Categories: Content management, Intranets, Knowledge management

Connectors for dashboards and portals

Joe Lamantia continues his series on connectors for dashboards and portals. To quote:

The building block system includes several types of Connectors that make it possible for designers and architects to link the different areas of a Dashboard together via a consistent, easily understandable navigation model. The system also ensures the resulting information architecture can grow in response to changing needs and content. There's no special stacking hierarchy for the Connectors. However, they do have an official stacking size (most are size 3) in order to keep Dashboards constructed with the building blocks internally consistent.

Posted by jamesr at 07:02 PM | Permalink
Categories: Content management

Content management skills

Ann Rockley has written an article listing required content management skills. To quote:

I'm often asked what type of skills someone would need to succeed in the area of content management. The following is a top-level list. It is not necessary to have all these skills, the list indicates some of the skills that would be useful.

Posted by jamesr at 07:34 PM | Permalink
Categories: Content management

Identical vs derivative reuse

Ann Rockley has written an article on identical vs derivative reuse. To quote:

Reuse can bring many content benefits to an organization including increased productivity, reduced costs, greater consistency, more usable content. But is reuse really realistic? Don't you need to modify content for the channel (e.g., web, print) or the audience (e.g., region, product).

When content is reused identically, it is reused without change. Derivative content is reused with change, content stays related to the original component.

This is always an interesting topic, and while I agree with the definitions in this article, I would question that even 15% of content can be reused. Also, the idea of "derivative reuse" is optimistic using most commonly available CMS products. Still, this is topic always worth discussing.

(I wrote an article on this a while back.)

Posted by jamesr at 07:25 PM | Permalink
Categories: Content management

Collaboratively creating CMS scenarios

A month or so ago I published an article on creating CMS scenarios, for use during vendor demonstrations. This week, as part of one of the many selection projects I'm involved in, I took a different approach to creating the scenarios.

The context was that the client wanted some more help to construct the scenarios, as well as engaging the whole project group in the process. This would gather the widest input, as well as helping to ensure that everyone ended up on the same page.

So I pulled out my coloured pens and sticky notes, and we did several rounds of affinity mapping. This is how it worked:

• The first round involved everyone writing up possible features or activities to include in the demos, one per sticky note.
• We then clustered them into groups, following the standard affinity mapping process.
• Pulling out another colour of sticky notes, we then came up for labels for each group.
• I then stuck up sticky notes for the following categories:

  scenario 1
  scenario 2
  scenario 3
  scenario 4
  "other items to demo"
  not current in req's
  not demoed
  tech, assess separately

• The group then did a first cut to pull together the sticky notes under the various headings.
• We then talked through each category, tweaking until it was the right size with the right type of items.

As always, it's fun to use these kinds of hands-on techniques, and the outcome seemed pretty reasonable. I'm not sure I'd use this approach frequently, but it was the right one to use here.

Reviewing the session, these were the strengths of the approach:

• makes a hard task easier and more fun
• builds consensus amongst the group
• provides an opportunity to double-check the requirements
• sparks good discussions about CMS capabilities
• works well in a group setting

And the limitations:

• still lots of writing to be done, this is just creating the "table of contents"
• the real scenarios will only become apparent once the narrative is written in detail
• scenarios will almost certainly be further shuffled once writing begins
• can be shallow as a process
• "hard" issues can be avoided by the group

Anyway, shared for interest, your mileage may vary...

Posted by jamesr at 07:01 PM | Permalink
Categories: Content management

Building block definitions (containers)

Joe Lamantia continues his series on designing portals, by looking at building block definitions. To quote:

The different kinds of Container blocks in the system play different roles, based on their relative size, in the overall effort to construct dashboards or portals. The smaller blocks--Tiles, Tile Groups, and Views–-enable the display of content, and support users' interactions with content. Sections, Dashboards or Portals, and Dashboard or Portal Suites–-the larger blocks–enable the navigation, organization, and management of collections of content. Pages straddle the middle of the size continuum; they are the largest block whose role is primarily to provide a framework for display of dashboard or portal content, and the smallest building block which plays an important navigational / organization role in the system. The different kinds of blocks work in concert to enable the creation of a scalable, navigable, and maintainable information architectures that support high-quality user experiences.

Posted by jamesr at 09:28 AM | Permalink
Categories: Content management

Do you need an ECMS, WCMS, or a portal?

Tony Byrne has written an article exploring the business cases for ECMS, WCMS and portal. To quote:

You want to find a good fit with your business objectives. First that means figuring out which type of technology will provide the biggest near-term value. Then it means knowing what type of scenario(s) you're addressing, to begin to isolate vendors who potentially hit that sweet spot. It doesn't matter whether you employ our list of scenarios or not; the key thing is that you carefully outline what you're trying to achieve with which types of content. A little analysis here can save you a lot of time and money later.

Posted by jamesr at 09:14 AM | Permalink
Categories: Content management

How to make the most out of a vendor demo

Seth Gottlieb has written a superb entry on running CMS vendor demos. To quote:

After you watch a couple of vendor demos, it doesn't take long to realize that the performance of the demo (how well the presenters know the product and how well they understand and connect with the audience) plays as much a part of the product impression as the quality and the capabilities of the product itself. Given that the sales team probably is not going to be around during your implementation or when your users first start using the system, this should scare you if you are basing your selection on the product demo. While it is important that a software vendor cares enough about your business to put some thought and effort into showing you the product, you also want to build your system on the the most suitable product. Here are some tips to manage vendor demonstrations that will isolate the important aspects of the vendor and the product and filter out the extraneous information that may confuse or distract you.

Posted by jamesr at 09:42 AM | Permalink
Categories: Content management

CMS and user-generated content?

I'm chairing a conference on content management at the moment, thus the flood of CM related posts. One of the topics that has repeatedly come up is web 2.0 and user-generated content in specific. The question was raised: what do content management systems provide in this space?

The answer is: not much. There is a significant gap in the ability of CMS products to handle user-generated content. Let's explore this further...

Content management systems are fundamentally designed to support a publishing process. That is, people within the organisation produce the original content, it's reviewed and finally published. There is also a focus on the manageability of the site around this, including review and expiry dates, etc.

Then web 2.0 comes along, and we want to provide site visitors with the ability to interact with the site. This ranges from the very simple to the very complex:

• adding comments to pages
• "was this page useful?" functionality
• adding reviews to supplement editorially-produced content
• seamlessly associating discussion with static content
• having the majority of the content of the site produced by site users

At present, CMS products have been caught on the "back foot" regarding these needs, and are still stuck in the world of traditional editorial processes. I see this is a challenge on two levels...

In the short-term, CMS products need to catch up their feature set to encompass some of these needs. Beyond this, there is a significant architectural challenge for CMS products in handling user-generated content. For example:

• How should user-generated content be captured?
• From the wrong side of the firewall?
• Is it versioned?
• Or reviewed?
• Via workflow?
• How is it managed in the CMS repository?
• What tools should be provided to site administrators?

These aren't easy questions to answer. Right now, it means that product purchasers are bound to be disappointed by the functionality offered by CMS solutions in this regard. It's also going to require a lot of thinking and talking to work out what the solutions should be, and what role CMS products will play.

PS. for vendors thinking they are offering web 2.0 functionality by including "blogs" and "wikis" as CMS modules, think again, you've got a lot to learn.

As ever, email me your thoughts...

Posted by jamesr at 01:13 PM | Permalink
Categories: Content management

What does a web CMS do?

In a lot of the work that I'm doing at the moment, I'm seeing very ambitious goals for content management system (CMS) projects. Bundled up in the project are many different capabilities, beyond just page publishing functionality.

This is causing a lot of problems. Organisations are going out to market looking for too much, not understanding what CMS products are best designed to do. This leads to a lot of disappointment, as well as blown out budgets.

So I thought it might be useful to post a quick summary table listing what a CMS does, and what should be obtained and implemented separately:

In practice, there are three reasons why you would get something separately from the CMS:

• CMS doesn't do it
• it may be a module, but could be obtained separately
• there is a whole other marketplace of tools in the required space

Note of course that the capabilities of CMS products vary widely, and many have various "modules" that can offer some of the functionality listed above. I would still argue that this isn't core functionality for a CMS, so I would always think twice.

Posted by jamesr at 05:04 PM | Permalink
Categories: Content management

The price of staying in the CMS game?

I've just released an article titled: Does your CMS vendor have product expertise?

Following on from that, I would argue that this is now the "ante" for CMS vendor to stay in the game, and will be one of the major differentiating factors in terms of who survives, and who doesn't.

To expand on that...

Even the big international vendors started from humble roots, and still go through periods of "growing pain" whey they have difficulty supporting their ever-expanding client base. Some vendors have also gained quite a reputation for the difficulty in migrating from one product version to the next.

Alongside these established vendors, new CMS vendors are constantly entering the market. (In Australia alone, there are 140+ vendors, 120 of which are local to the region.) Some of these vendors have excellent products, having had the opportunity to learn from the mistakes of others.

For all these vendors, however, the challenge is in migrating their business away from custom development to "product management". Those that cannot do that will ultimately fail.

(As outlined in the article, I include managing upgrades, code versioning, revision testing, support plans, etc in "product management".)

For new vendors, I would also argue that if they don't have a concrete plan (and the resources) to put in place the necessary product management from the outset, they shouldn't even bother launching.

In some ways, maybe this even relates to open source vendors, where the community must play the role of managing the "product" instead of the vendor.

So, what do you think?
Does this match your experiences (good and bad) with vendors?

Posted by jamesr at 09:59 AM | Permalink
Categories: Content management

Does your CMS vendor have product expertise?

Choosing a content management system (CMS) is not just about finding the product with the right functionality. It's also about dealing with a vendor who can support your needs for the lifetime of the solution.

You need to be confident that there will be more than just help-desk support - the vendor should offer regular (trouble-free) product upgrades, a clear development plan, and good mechanisms for handling the needs of each CMS customer.

The challenge is that many vendors are great at code development, but poor at product management. While they are small this doesn't matter, but as they grow in scale, customers start to feel the pinch.

This briefing explores the way most CMS vendors have evolved, what this means for the way they work, and what you should be looking for when purchasing a solution.

Evolution of vendors

Most CMS vendors start off as web development or web design agencies, custom-creating websites for their clients. Over time, customers increasingly demand the ability to maintain their own sites, and a variety of simple editing interfaces are developed on a case-by-case basis to support this.

Once this has been done a dozen times, this editing code starts to be pulled together into a single code-base, which is still tailored for each customer. As the agency grows, there comes a point where this editing and publishing code is given a name, and it starts down the road of becoming a 'product'.

[CM Briefing 2007-16, read the full article]

Posted by jamesr at 02:15 PM | Permalink
Categories: Content management, James' articles

Using scenarios to select a CMS

Scenarios are narrative descriptions or stories that concisely outline how something will work in practice.

In the context of a content management system (CMS) project, scenarios are a very effective way of documenting key CMS requirements, and they complement the formal lists of functional requirements typically found in tender documents.

Content management scenarios provide a 'day in the life' description of how the CMS will be used, for example:

Richard enters the text for the page, and creates a link to the supporting PDF. Once the content has been spell-checked, Richard submits the page for review by Jane, his manager.

By using this story format, a large number of details can be conveyed in relatively few words. In practice, a single scenario can cover the same scope as several pages of functional requirements.

Scenarios are most effectively used during vendor demonstrations, to provide a 'script' for vendors to follow. This ensures that the vendor shows how the product will work in practice, meeting the specific needs of the organisation.

Having a common script across vendor demos also makes it easier to compare solutions, as well as providing a strong foundation for scoring the products against functional requirements.

This article will outline how to create effective scenarios, including concrete examples, guidelines and suggestions.

[September KM Column, read the full article]

Posted by jamesr at 01:55 PM | Permalink
Categories: Content management, James' articles

Will podcasting survive?

Alex Iskold has written an interesting article that asks: will podcasting survive? To quote:

What is going on with podcasting in general? We certainly no longer hear about it as much as we did in the past. Is it because it simply became part of our culture that we take for granted? Unlikely. It seems that podcasting has not really made it into our daily lives. In this post we look at podcasting and try to decipher why it never got big.

Posted by jamesr at 10:58 AM | Permalink
Categories: Content management

Centralized or distributed?

Alan Pelz-Sharpe has written an item on centralised vs distributed approaches to ECM. To quote:

I was trawling through some old presentations the other day - when I came across a couple that were given at crisis points in major ECM implementations. What struck me about these was the focus on the architecture of the ECM system. In particular whether it should be centralized or distributed (most of my clients have been very large and often global in nature). The pro's and con's of federated ECM - the issues of replication etc are well understood. But what I think is less understood is the impact that this architectural approach has on ECM as a practice.

Posted by jamesr at 12:04 PM | Permalink
Categories: Content management, Information management

A lexicon for document analysis

Tony Byrne has written an article on the confusion of terminology in the content management industry. To quote:

One of the challenges of any content technology project is standardizing on a particular set of terminology. Without that, you risk confusion among the business users, developers, managers, vendor staff, and consultants who may all participate in your project.

And one area where I see a lot of different terminology is in the domain of content analysis. Content analysis is becoming increasingly important, particularly on the web, where more enterprises want to take advantage of the latent structure of some of their online information to better re-use information across locales and channels.

Posted by jamesr at 11:58 AM | Permalink
Categories: Content management

The CMS marketplace is starting to crystallise

"We're extremely busy, and so are all the other vendors."

This is what I heard from a number of the vendors at the recent Open Publish conference in Sydney. More than just being busy, many vendors now have their "pipeline" of work fully committed through to October, or beyond.

As a consequence, many of the vendors are now focusing their efforts on just a few market segments, whereas previously they would've taken on any work that came their way. They are now passing up work because it doesn't fit with their core focus or strategic direction. They are also consolidating their existing customer base (whether it be local councils, state government, marketing websites, etc).

This is something that I've been predicting for some time now. Whereas some of the industry analysts have been claiming that the marketplace is consolidating and converging, I've been seeing the opposite. Vendors (and their products) are still diverging, each looking for the "killer feature" that will knock off their competition.

Instead of consolidation, what we're now starting to see is crystallisation. Individual vendors will group around specific market segments, so there becomes the six major vendors each for healthcare, intranets, events, etc. By necessity, this must be an organic process, in the absence of any overarching marketplace strategy.

This crystallisation will take some time, will be painful and confusing, but inevitable. It is simply not viable for each vendor to try to see to all prospective customers, when there are so few good channels to raise the visibility of products.

I'll watch with interest over the coming year to see how this unfolds...

Posted by jamesr at 11:39 AM | Permalink
Categories: Content management

It costs $5mil to write a CMS

There are a lot of content management system (CMS) products in the marketplace, over 140 in Australia alone. There are new products springing into existence even as this is written. As discussed by Seth Gottlieb, there are also an uncounted number of homegrown CMS packages, developed by individuals for one-off projects.

There is a lot that goes into a successful CMS, something that is often taken for granted by both developers and purchasers. Having spent a lot of time talking with local vendors, I would estimate that it costs at least $5 million to develop a fully-functional CMS.

This is real money (cash) that needs to be found and spent by vendors, to produce an acceptably good mid-market solution. This isn't a all-singing-all-dancing product we're talking about here, but rather a CMS that just "works right", and meets the expectations of most purchasers.

This is a lot of money.

There are some natural consequences and observations that arise from this:

• If you're thinking of taking your home-grown solution and making it into a commercial product, you need to be able find $5 million. That's the price of entry into this marketplace now, and the minimum requirement for commercial success.
• A lot of this money is not spent on implementing functionality, but on improving performance, fixing bugs, handling special cases.
• There's a lot of difference between the maturity of products, between CMS solutions that work to a point, and those that have spent the time (and money) to "dot the i's and cross the t's".
• While all the products can probably "tick the boxes", you want to purchase a solution that has devoted sufficient resources to get their product to an acceptable level of stability, functionality and maturity.
• The $5mil is just the beginning, as the bar is being raised all the time for "best in breed". So vendors have to keep spending a significant percentage of their income on R&D, just to keep up with their competitors.
• While $5mil is a fair bit of money, this is still quite achievable by hundreds of vendors, so it doesn't naturally mean that only the big players will survive. (Particularly as the general selling price of products has fallen five-fold over the last 3 years.)
• And no, don't try to build a solution yourself. Trust me, buy a product from a vendor that has already spent this money on your behalf, to build a solution that really works.

Posted by jamesr at 12:51 PM | Permalink
Categories: Content management

What makes a content management system?

Gadgetopia has published an article exploring what differentiates a home-grown publishing tool from a CMS. To quote:

I got to thinking the other day: exactly when do you have a "content management system?" We've all built apps that manage content, but when do you graduate from a "relational database with an admin section" (RDBWAAS) to the lofty and deserved title of "content management system?"

Posted by jamesr at 10:13 AM | Permalink
Categories: Content management

Homebrew CMS

Seth Gottlieb has written an article about the perils of writing a homebrew CMS. To quote:

I have seen (and replaced) enough home-grown content management systems to know that they are not as easy to build as you would think. As a software architect, I understand the temptation. You just want something simple and you don't want to put up with all the compromises, limitations, and cost that a CMS framework comes with. After all, its just a matter of writing some data to the database and then presenting that same data elsewhere. We have all designed dozens of systems that do that! And look! You can even download a free WYSIWYG editor to make your homebrew CMS usable?

But before you go ahead and build the one billion and first CMS, here are some things that typically burn generalist architects when they try to design their first CMS.

This is an excellent list, and it accords with my personal experiences (I actually started my content management journey a decade ago by writing a custom CMS for technical writers). I would just add one extra item to this list:

Editing environment. If the authors can't easily and efficiently get their words onto the site, you're toast. There's a huge amount that goes into a good editing tool, including table support, CSS, images, spell checking, and clean cut-and-pasting from Word. Even if you chose to use one of the commercial editing tools (a good idea!), it still needs to be tightly integrated into the CMS.

Posted by jamesr at 10:05 AM | Permalink
Categories: Content management

Introduction to the building blocks

Joe Lamantia continues his series on the building blocks methodology for designing portals. To quote:

Part 1 of this series "The Challenge of Dashboards and Portals" discussed the difficulties of creating effective information architectures for portals, dashboards, and tile-based information environments using only flat portlets, and introduced the idea of a system of standardized building blocks that can effectively support growth in content, functionality, and users over time. In enterprise and other large scale social settings, using standardized components allows for the creation of a library of tiles that can be shared across communities of users.

Part two now outlines the design principles underlying the building block system, and the simple guidelines for combining blocks together to create any type of tile-based environment.

Posted by jamesr at 12:59 PM | Permalink
Categories: Content management, Information architecture, Usability & user-centered design

Is the personalised intranet portal dying?

Toby Ward has written an article on issues with personalised intranet portals. To quote:

Very few organizations have actually enacted or properly implemented user personalization once they've purchased a portal product. Most employee portal implementations feature customization. The difficulty with personalization is that it requires a phenomenal amount of work and planning; the technology component is relatively simple. Organizations that roll-out personalization have to identify and define multiple roles and content and then map all the content to those roles and ensure that the content is provided on an ongoing basis (writing, updating, publishing, formatting, etc.). Even more troublesome is that while employees like the idea of personalization, few will ever use it.

Posted by jamesr at 02:02 AM | Permalink
Categories: Content management, Intranets

Where collaboration tools fit in (Brisbane, Melbourne, Sydney)

To meet the huge level of interest in collaboration at the moment, we've organised three more sessions on Where collaboration tools fit in, with dates as follows:

• Brisbane (12 September 2007)