With the amount of exposure the practice has nowadays, a whole industry has sprung up around it. And CMS vendors have been quick to jump on the bandwagon, offering a myriad of SEO "features," "modules," "plugins," and "wizards."  From what we can see, customers are finding it increasingly hard to distinguish sense from nonsense.

This is why I recently wrote an advisory paper, "SEO and your CMS," for our Web CMS stream subscribers. It describes the mechanics of SEO, a critique of the magic bullets that vendors are offering, and offers practical advice on how your CMS can help with search engine optimization. 

One such truths is that in general, your implementation cost for an enterprise implementation will come to 7 to 8 times that of initial licensing.

Vendors sometimes inadvertently highlight this hidden cost. Recently, I witnessed the regional sales director of a large infrastructure vendor tell a potential customer that for every Euro spent on his company, 7.5 Euros went into the local economy. It was meant as a nationalistic appeal -- but it sort of backfired when the customer inquired whether this meant they were going to spend 7.5 times the license cost on additional integration services. (The reply took about five minutes but boiled down to "yes.") This was a pretty savvy customer, and they had actually calculated that the average cost of most of their enterprise IT projects was 7.4 times the initial offering; to them, this episode was just an indirect affirmation.

However, like all generalizations, this 7-8x multiple is not some unalterable law of the Medes and Persians. Among other things, it can depend on what exactly you count as implementation cost, and what you count as licensing cost. For instance, internal resources are usually not billed to a project budget; and likewise, annual maintenance and support often don't hit the project sheet beyond the first year (though they should). And, of course, open source isn't free -- don't even think that 7.5-times-zero means the whole project will be gratis. And for a more comprehensive paper on how to calculate cost, you may want to check my colleague Apoorv's recent advisory for CMS projects.

But if you're budgeting your project, or a vendor calculates ROI for you, use this as a yardstick. You may be getting a bargain -- but remember that if it looks too good to be true, it probably is.

Clearly, this is going to put some customer IT departments in a bit of a pickle in the near future. The latest version of Internet Explorer, IE9, only runs on Vista and Windows 7. The upcoming version 10 (which has already been shown in a first version, with Microsoft apparently speeding up the release cycle) will only run in Windows 7 and 8. If your enterprise is still on Windows XP (and the latest figures suggest around 60% still do), once IE10 comes out, you're out of luck. And that's probably going to be early next year.

With a disregard for large enterprise deployments that's typical for Google, the company says, "if it’s been a a while since your last update, we encourage you to get the latest version of your favorite browser," and helpfully provides some download links.

It's just that, well, most IT departments try to control their desktops and what's installed on them, since otherwise it's impossible to effectively support and secure them. It's not up to the individual user to just download and install any executable.

So if your enterprise signed up for Google Apps, this may force IT departments into hasty migrations to new versions of Windows. Or they will be forced to install Chrome for everyone instead (quite possibly that's what's lurking beneath Google's rather naive comment above). If so, there's a whole new game of vendor lock-in about to start.

This is probably not the kind of consequences anyone would expect from a collaboration tool that runs "in the cloud" with the interface "in the browser."  It does, though, speak volumes for Google's assumptions about its customer base.

It should serve as a reminder that procuring enterprise solutions is never simple or straightforward, even if at first blush it would seem that way. Which is exactly why our social computing vendor evaluation research around Google isn't a cheerleading flyer -- but fourteen pages of critical analysis. You may want to read it before committing to a "quick win."

That sounds great, doesn't it? It's like the multi-tool of content technologies. Imagine a major vendor and integrators turning up at dinner to explain how great their Swiss Army Knife is for any purpose, and yes, it's excellent to carve your food with, too. Why go with just a knife, if you can have a whole range of additional functionality in one system?

The idea is appealing: instead of picking and maintaining all of these different implements, why not just have an all-in-one? The upkeep would be a lot easier than having a whole toolbox of various provenance. The magic word here is synergy. "The latest generation of the world famous original continues the virtues of yesterday, while nevertheless still meeting the demands of today with regard to functionality, user friendliness and quality." That's Victorinox' description, not Microsoft's.

But don't forget the drawbacks in that analogy. In recent consulting engagements, I've been asked about SharePoint's suitability for web content management or enterprise search. As it turns out, Microsoft's Swiss Army Knife isn't necessarily the best system to use, especially if you're having soup. Or a stew. The synergy is pretty much gone if the tool isn't well suited to its main purposes. And it'll leave you with a lot of nice-to-have but possibly useless extras -- the tweezers, saw, and screwdrivers of the more expensive version will probably go unused at a dinner party.

If you're considering SharePoint, this Swiss Army Knife may, on the surface, be a great option. But depending on your scenarios, you might be better off with a spoon, a Craftsman box of professional tools, or a Leatherman Multi-Tool. Needless to say, that's not really something for an impulse buy -- but we can help you find the right tool for the job.

You start with commenting, of course. No blog would be a real blog without it. And most kinds of social & collaboration software wouldn't be considered very social (or collaborative) without the option to comment on content, either. And the best thing about commenting: how hard can it be, really?

The basic concept is easy enough to realize. This is what developers tell salespeople, and what the salespeople tell you, the customer. Almost every Web CMS we cover now has a commenting "feature," "module," or "plugin." And if you have in-house developers, they will chime in saying it'd be easy to roll your own, and build it yourself. How hard can it be: comments really just represent a list, where you can type in your name, your comment, post it, and it gets added to the list. In fact, I recall having built a commenting service once, and it took me about two hours. (And I'm such a terrible coder I'd never dare to call myself a "developer.")

The reality is a bit different. In fact, getting a commenting service right is quite difficult, and nobody is really happy with theirs (including us). Most people are used to the commenting built into best-of-breed blog software, like WordPress or Movable Type. Comments can be nested, you get a nice avatar next to your post, it remembers your credentials for the next comment, it emails you when somebody reacts, and maybe you can vote on others' comments.

Build this yourself and you'll spend quite a lot more time than those initial two hours. Look at what most WCM systems offer, and it's usually the bare bones basics. This disappoints and annoys visitors used to a higher standard -- not something you want when you try to engage your audience.

It gets worse when you invite the public at large to take part (and not just your trusted colleagues on an intranet). What do you do when visitors start spouting filth? That won't look good, so you'll need "naughty filtering". (Ideally, in any language -- not just the language of your content. You may not understand the Russian swear words, but quite a lot of people would take offense.)

And what do you do with other undesirable behavior: competitors deriding your brand, readers ganging up on you, or the ever-present trolls? You'll probably want to moderate -- even post-facto -- what's being posted. That sounds great until you realize how much work this will entails to stay current. So you'll need some automatic rules to help out. But even if you have a commenting system that allows you to set some variables here (e.g., "automatically approve if poster has been approved before"), you'll find you'll need constant tweaks to get the mix just right.

Then there's spam. Comments are a favorite place for user generated or robotic spam, creating as many backlinks possible to promote the pagerank of some disreputable off-shore meds or fake brands sites. If you don't have moderation, your site will become a linkfarm (and possibly get demoted in its own ranking). If you do have moderation, you'll spend quite some time wading through the thousands of fake comments and trying not to miss the real ones. You can use an external service to separate the spam from the bacon, like Akismet (originally for WordPress) or Mollom (originally for Drupal). But then you just reverse your work: dealing with false positives lingering in your spam queue.

I just spent quite some time trying to tune our own commenting service, hosted via IntenseDebate (it should now be easier to add comments either as a guest, or using FB or Twitter connect). It wasn't easy. And if you read TechCrunch, you may have noticed that blog, within the course of the past 10 months, switched from WordPress' built-in commenting, to Disqus, to Facebook comments. They had an even harder time to get it right (and are still experimenting). Even using "proven" solutions is tricky -- let alone trying to quickly whip up something yourself.

So, think commenting is a simple, straightforward feature? Think again. When a developer tells you he can build it in a day, press for details. If some sales guy says their product already has commenting, be inquisitive (it's usually something a developer whipped up in a day). The devil is in the details. You don't want him in your comments.

I, for one, always enjoy seeing the winner and runners-up in the competition. That's not to say that you should enter just for the benefit of the greater good. If you've ever struggled with getting management buy-in or user engagement, think how nice it would be to be able to point to the glass trophy. As James writes, "Who can say no to an award winner!"

Submissions are open until 31st of May. If you're proud of any aspect of your intranet, this is your chance to showcase it. But if you're too modest for that, this is also a nice opportunity to let us all share and learn.

So why don't we review MarkLogic in our Search & Information Access research? It's a fair question to pose, and some of our subscribers do ask, often after talking to MarkLogic salespeople.

To answer it, my colleague Theresa Regli and I wrote an advisory paper "Is MarkLogic an Option for Enterprise Search?" It describes what enterprise search is; what MarkLogic is; and why MarkLogic isn't enterprise search.

Subscribers can download the paper here.

In order to be able to index SharePoint and other sources, the Search Appliance (GSA) uses Google's "Enterprise connector framework." This formerly required an external server to run on. Only in version 6.2 of the GSA (released by the end of 2009) was this actually deployed on the yellow boxes themselves, making indexing SharePoint a point-and-click UI affair.

But the nice thing about the Framework is that Google actually open sourced it (under an Apache license). This means it's easy to adapt it to other repositories (if you have the developer acumen to do so, and a server to run it on). More interestingly, perhaps, is that this also means it's not too hard to use Google's Framework to feed SharePoint content to Solr, instead. And this is exactly what Lucid Imagination has done in their latest 1.7 release of the LucidWorks distribution. Using the connector, it's now as easy to index SharePoint with Solr as it is with a Google Appliance.

However, if you're looking for a discount search engine for SharePoint, LucidWorks Enterprise isn't necessarily it. It's not "free" as in "free beer": you'll need a $64K annual subscription with Lucid to run it in a production environment. If money matters, do the math.

More importantly, don't forget that while a cost comparison is difficult enough, it's only one variable in the mix. And with various search solutions mix-and-matching their components, this becomes comparing Grapples to Orangelos. The good news is there are plenty of options; but then there's plenty of homework, too...

Exhibit A: copy/pasting from Microsoft's Word.

Where does content commonly come from when it's repurposed for the Web? Microsoft Office, which is pretty much the standard for office productivity applications. In fact, it's quite usual for editors to send in their content as Word documents -- with webmasters or web managers diligently copying all the text, and pasting it into a rich text editor within a CMS.

Or rather, pasting it in Notepad, and then pasting it into the editor. Because what Word leaves on the clipboard is Microsoft's interpretation of what HTML should look like -- and that's quite a mess. Redmond's proprietary tags routinely break pages and standard layouts. And then there's the separate problem of content encoding -- those magic quotes often don't translate too well. In short, Word doesn't really separate content and design -- one of the basic tenets of content management.

Most systems nowadays have some sort of solution to this. Popular rich text editors like CKEditor and TinyMCE have buttons to either paste plain text only (the equivalent of the Notepad intermediary) or "clean" the Word content. Alternatively, your CMS may offer filters that will try to scrub the HTML after it is saved.

Cleaning, however, never quite works. Either too much gets stripped, so tables or more complex document structures don't make it across; or too little, leaving us with a bunch of tags with unpredictable results. All of this is difficult to get right. (I know this all too well, having once tried my hand at writing an XSLT filter for the purpose. The horror!) Unrealistic expectations here can lead to many help-desk calls -- "the CMS screwed up my document" -- and the like.

The reality is that the only reliable way to get text from Office to the web editor is "text only" -- forget any formatting. That's what the Notepad-route does; and it's what Google's Chrome browser now does with CTRL + SHIFT + V.

It's fair to say only Microsoft could really fix this. How hard would it be to just paste minimal markup, instead of proprietary lingo? This isn't exactly rocket science, cold fusion, or teleportation. So, I asked the company.

The problem for Microsoft, of course, is that while pasting into web applications is common, pasting from one Office document to another is much, much more common. In those cases, you'll often want to preserve formatting, and according to Redmond, "the HTML clipboard format in Word is optimized for those scenarios." What's more, there's now the Office Web Apps -- so Microsoft enables pasting into those web versions of the Office suite with all formatting intact, too.

That's all fair, but what about the web editor and her tedious clean-up process? Well, according to Microsoft, "[Y]ou can save your documents as 'Web Page, Filtered' where the extra markup will be removed and you will be left with a simpler set of HTML markup." Alas, even filtered HTML is not entirely MS-free. 

So, there's a glimmer of hope, yet we remain pretty much were we've been the past decade on this problem. There is no single answer to something as simple as copying text from an Office document and pasting it into your CMS. Microsoft's solution is a bit cumbersome and incomplete, and Google's rips out tables and other content you may like to keep.

However, instead of blaming Microsoft for this, consider it a reminder. The trenches aren't glamorous, but it's where you're most likely to encounter hurdles. There are plenty more day-to-day obstacles to getting it right. And nobody's going to magically fix this for you any time soon.

The thing is, adding Google to SharePoint usually doesn't make a lot of sense. SharePoint's native search capabilities compare pretty well to what Google can do. I've only seen a couple of actual bake-offs between the two, but users don't tend to discover big differences in the quality of the results.

The only thing they do notice: the Google logo instills a little more faith in the results of a search. If Google can't find it, it must be the searcher's fault, the assumption goes. With Microsoft, it might just be SharePoint's fault.

So if you're having issues with the search in SharePoint, Google is unlikely to fix them. A cynic would say that Google's logo would at least let the users blame themselves, instead of the IT department. But simply deferring the blame will come with a hefty price tag. Do the math carefully and you'll find you'll easily spend tens, and quite probably hundreds of thousands on Google Appliances. These aren't cheap machines, if only because they have limits on how many records you can index.

Microsoft's FAST, on the other hand, may look like the logical alternative. However, FAST, even in Microsoft's much-reduced licensing, isn't cheap, either. But more importantly, it'll add a lot of complexity you may not be prepared to deal with -- and may not need. Using FAST for scenarios where Google would be viable is overkill.

Meanwhile, there's plenty of alternatives for specific scenarios if you want to improve on search within, and especially outside of, SharePoint. So if you're currently thinking about only two options -- either bolting on Google Appliances, or adding FAST -- alarm bells should go off. Not because either is a bad solution -- but because it suggests your requirements have likely not been adequately thought through. Since you'll spend a lot more money than you think, this not something to decide off-the-cuff.

Got SharePoint search issues? Take a long look at current environment and how to fix it within SharePoint itself. By the time you fully understand the issues, you might come up with better alternatives, too.

I'd say it's perfectly feasible to be more agile in your web development. The process itself shouldn't be a problem. The cross-organizational change required to put the process in place is much more of an issue. Yet, 9 out of 10 companies I've talked to the past few years seem to get stuck in first gear.

So get past the scrum and back into play: start with getting the basics right.  Here are some ideas.

Remember you're developing websites, not software
Often, the process works like this.  A concept of a site will get specified. The specification will then be handed over to developers. They will work to turn it into a functioning CMS implementation and front-end website, using agile methods. There's a watershed between marketing/communications departments and IT -- and it's reinforced by agile methods themselves. (See for instance the Chicken and the Pig analogy.)

This is doomed to fail, because agile is not meant for completing 100% of a set specification at a specific deadline date. And even if the developers would succeed, the goals of the project will have shifted and moved on by the time they're done. Because you're aiming at a moving target -- that's the nature of the web.

Instead, think about this as web development. That may sound obvious, but it really means that every stage, from concept to UX and IA, from content strategy, to graphical design, to software customization and templating, should be part of the agile process. Not just the software development bit. You can't just drop an idea and move on: everyone needs to be actively involved in the ongoing agile process, but most notably the business team. Remember: watersheds tend to lead to waterfalls.

Agile is not an excuse for not knowing what you need
Problems get exacerbated if the original concept is too vague. That'll lead to dissatisfaction if you're using waterfall methods -- but agile will only serve to amplify the effect. If you keep changing your mind, then asking developers to change their plans to suit you, you're just leading them on a wild goose chase. The project will never be finished.

Yes, your website should be in constant evolution to keep up with a rapidly changing reality. But you still need a clear plan. Conceptualize and develop what you can chew off in the short term -- and let that be part of an iterative agile process. But also keep a sense of direction for the longer term. You don't have to know where you'll be in five years, but you do have to know whether you want to turn left or right at the next crossing. Otherwise, you'll just wander aimlessly, chasing an elusive mirage.

There's a time and a place for waterfall and agile
You can't just throw a switch and start being agile. You need the technical and organizational infrastructure first. Take the time to do this thoroughly. Don't jump in the water right away. You might drown before you figure out how to be agile enough to swim.

If you're starting an overhaul of your organization, the CMS, and the website, get a thorough foundation in place. A friend of mine claims the Tower of Pisa was built using agile methods from day one -- which is why the building itself looks nice enough, but it's rather noticeably lopsided. Foundations need thorough specification and execution, because no matter how agile your fixes afterward, they'll always be crooked.

Finally, and I've said this a couple of times before: a website isn't like a book that's finished and sent of to the printers. You're never done with it. Agile methods suit this constant evolution very well. But getting into a constant flow is far from easy; don't underestimate the expertise and time you'll need. We can help you with expertise -- but don't expect miraculous quick fixes.

Take Alterian, and its Alterian Content Manager product. It's not, in fact, one product. In 2010, it was two quite different products sold as "editions" of one. In 2011, it will be one product sold in two editions. That's a much bigger change than it sounds.

Almost a year ago I reported that Alterian would drop Content Manager Corporate Edition (CMC), the former Immediacy product. Only the Content Manager Enterprise Edition (CME), the former Mediasurface product, would remain.

So where does that leave existing Alterian customers?

Well, if you're a customer you needn't worry about your current implementation too much. Alterian has since released CMC's last version ever, 6.3, but the company also stated it will support Immediacy/CMC until April 2015. This should give you plenty of time to migrate. What's more, Alterian will even throw in a free CME 7 license. Appealing as that may sound (what could be better than free?), beware. Don't forget that CME (Mediasurface) is quite different from CMC (Immediacy), and licensing is only a fraction of the total project cost. CMC to CME is not an upgrade -- it's a migration. You should treat this as a CMS selection project, and carefully investigate alternatives.

And what if you are in the market for a CMS?

Alterian CME version 7 was "launched" in November 2010, which somehow means it will actually become available at the end of this month. (Maybe the large amount of snow in December in the U.K. meant it couldn't actually lift-off yet.) Then, starting this year, Alterian wil sell two versions of the former Mediasurface Morello: the "Professional Edition" and the "Enterprise Edition".

But this time, the two offerings really will constitute "editions" of the same system. And that system will be based on Mediasurface/Morello.

We've recently updated the Drupal review in our Web CMS Report to a preview of version 7. Major updates like these are always difficult to review -- because there are no actual production instances yet to glean real world experiences, as we customarily do. That makes us cautious to predict anything about how it will fare in real life scenarios. And you should be equally cautious if you're considering implementing it in a production environment.

There's a lot to like about what the Drupal community did in version 7. The software's interface (which, like DotNetNuke, is meshed into the visitor-facing website) has been overhauled and dragged into the current decade. Drupal finally has native content modeling (this formerly required an optional module, CCK) so you can have different content types. And perhaps most importantly for the high-traffic customers Drupal has been attracting the past few years, some of the Pressflow distribution's features for better scalability have been ported to Drupal Core. (Though, paradoxically, a simple Drupal install will probably be slower than version 6.) These make Drupal a much more serious contender for the high stakes game than before.

Of course, that's all relative to the previous version. Version 7 is one giant leap for Drupal, but one small step for mankind. It doesn't fundamentally change how it stacks up against most of the platform systems we cover. Drupal still lacks a lot of the infrastructure that's considered a commodity in other platform systems.

Yes, with the plethora of free add-in modules available Drupal can be made to do a lot of things. But at this crossroads between version 6 and 7 the problem with that is quite obvious, too. A lot of version 7 modules are still in pre-release alpha or beta. And it suddenly becomes painfully clear that quite a few modules have been orphaned: their developers have abandoned them in version 6. Modules require due diligence; because you will, always, need modules. (Without a module, Drupal Core doesn't even have a rich text editor.)

There are global release parties this Friday. And as usual, there will be quite a few headaches after that. If you don't have a Drupal tattoo, you'll likely want to be a spectator for a few months before jumping into the melee. So if you're thinking of betting on Drupal, check the odds in our research now -- and then check them again in six months' time.

This also means there is no easy answer. You'll have to do your homework to figure it out. Inevitably, any system will have its advantages and drawbacks. It's up to you to figure out which product has advantages that are a good match for your scenario, while you could still live with (and plan for) the drawbacks.

So which is better, Drupal or WordPress? I've seen quite a few blog posts covering that in the past year. But there's only one truthful answer: ...it depends. Drupal has strengths in community-oriented sites and placeless content. WordPress has an edge in editor usability. I could go on for another 33 pages to describe other differentiators in detail. (In fact, I have.)

But really, to ask whether Drupal or WordPress is better is asking the wrong question. First of all, if you only compare those two, you'll surely want to broaden your horizons a bit. In the grander scheme of things, Drupal and WordPress are actually very similar systems. There's a lot more out there. Preference for one over the other will come down to specifics. Secondly, those should be your specifics; nobody can answer the question for you. You'll have to think for yourself.

That's why I can't offer a generic answer to the question. Which is the best, Drupal or WordPress? Quite possiby neither. We'll gladly provide you with independent information to help you choose; and assist you in reaching a conclusion. But answering the question, ultimately, is up to you.

Think about it. If someone has spent the last ten years mastering a particular product, and one product only, are they likely to be critical of it? Their expertise is their livelihood, and that livelihood is closely tied to the success of a particular system. Also, it may be the only tool in that category they really know.  The effect gets worse when they have gone through extensive training to become fully certifiable. (Pun intended.) And the more proprietary a system is, the stronger the seasoned veteran will proclaim that way to be the best way.  Not all product experts are this way, but many follow the pattern.

I'm not going to name examples because this isn't specific to any specific vendor or project. If you browse through the comments on blog posts here I'm sure you can find several, often contradictory, examples of what I mean. Sometimes commenters will be honest in stating their ties to the product's success. But quite often they'll simply deride anything that in their mind seems to attack their beloved system. Pretending that unlike everything else, which "of course" has major flaws, their system is without a fault. Unsurprisingly, these aren't particularly useful voices to listen to.

By contrast, we have nothing to gain by promoting one system over another. We don't work for vendors in any way (we don't speak at their events, we don't write whitepapers for them, we don't get a commission when a particular system wins the selection procedure). That means we can afford to be very critical (though we spend a lot of effort to make sure the criticism is well founded). If you want to get the cheerleading, "this is the most awesome thing since sliced bread" story, you can easily get that from the vendors -- and increasingly their consulting partners. For us, there's little point in putting out a weather alert for a nice summer's day. Our point will often be to warn of the cloud on the horizon and to bring an umbrella just in case.

Some observers don't seem to get that at all. As the proverb has it, "to the crooked eye, all things are crooked." If one commenter angrily shouts that obviously we're against system X and totally on the take of Y, and a week later another reader accuses us of always being pro-X and not taking Y seriously, that doesn't really reflect on us. It reflects on the communities making those allegations. (Which is why we don't usually remove those comments.)

My colleague Tony Byrne has been praised for being "an equal opportunity critic." I like that; it's our job to stand by the content technology buyer, and to warn them of pitfalls. Not because we're pessimists, but because forewarned is forearmed. When our readers use that knowledge to navigate the minefields towards success, it makes it all worthwhile. And I feel privileged to work for a company that values integrity over easy money -- even if that means being criticized for being a critic.

If you want the blow-by-blow news, read all about it on CMSWire. The most interesting tidbit is that the new owners have no experience in content technologies; it's an investment firm with a large, diverse portfolio, none of it internet (let alone web) related. The majority of EPiServer shares were previously owned by another investment firm. Following the cancelled IPO earlier this year, this was a good alternative for them to still cash in. As the vendor changes hands from one investor to the next, there aren't any strong ideas for sudden changes to the EPi-everything product line-up.

So what about a new strategy? Well, new owner, IK Investment, says it usually invests in companies that "have potential" and are currently "underperforming." The plan is to conquer the world with EPiServer -- currently mostly dominant in Scandinavia and with a growing presence in the UK, but there's a lot of markets the Swedes haven't really found their footing yet. Together with the EPiServer acquisition, Harbour Software in the UK was bought -- basically already the UK subsidiary, but it has now come under full ownership of EPi. For now, that's the extent of the ambitions.

So what will this mean for current and future customers of EPiServer? Well, the vendor is going to try very hard to expand and gain marketshare. That's not exactly a big break from what they were doing previously. So, to summarize in one word: yawn. I'll wake you up when there is a serious change in course.

The thing is, the rumor of the web's demise has been greatly exaggerated. Rather, what we're seeing here is warped statistics. As the old adage has it: "Lies, Damn Lies, and Statistics." Or another favorite: "Statistics are what a lamp post is to a drunk: mostly for support, rarely for enlightenment."

Wired's article is a case in point. It opens with a large colorful graph, showing how web traffic is decreasing in importance. Of course, the graph is relative. That is to say, if the total volume of internet traffic has increased, it's likely that web traffic has increased a lot over the past few years, as well. It's just that web traffic hasn't increased as much as say, video. But video files are a lot larger than webpages: a small amount of video downloads creates a disproportionate amount of traffic, which distorts the view even more. Last but not least, let's not forget that the source is Cisco; and of course, with all this video traffic, you'd really need Cisco routers to cope, right?

Instead, Wired draws the conclusion that what's really happening is that traffic is shifting from the web, to mobile apps. That, too, is the apotheosis of a buzz building the past few years. Because the general consensus is that mobile now equals iPhone or Android apps. It's the applification of the mobile internet.

Enter more statistics. A study released by the Dutch Ministry of Economic Affairs last year clearly showed that most of the mobile internet usage was through Apple iPhones. (Also, there were 20 million mobile phones in use in The Netherlands -- on a population of about 16.5m.) Or look at the world map of mobile marketshare. Clearly, IOS reigns supreme almost everywhere in the world. So if you want to go mobile, you'd better build an iPhone app, right?

Then again, maybe not, because if you look at a more recent graph, perhaps the picture is slightly more nuanced. There's plenty of Opera (which runs on many different platforms), Nokias, and Blackberries; plus, Android is moving up. And to add even more nuance: all three of those -- that last graph, the government report, and the world map are using the same source of data. Yet, they don't quite match up? And about that source -- it's StatCounter, which provides free visit counters for websites. What they don't provide, however, is a breakdown of who actually uses their free counters.

So let's turn to one last stat: as TechCrunch's headline put it, "Android Share Jumps To 25.5 Percent, Now Second Most Popular OS Worldwide." Apple is steady at around 16-17%, Blackberry dropped from 20% to 15%, and the biggest looser of all is Symbian, steadily declining from 45% to 36%. So at least, if you hedge your bets with Android, iPhone, and Blackberry apps, you'll be safe; everybody understands by now Symbian is loosing the battle. Except, you see, it's not: in absolute figures, Symbian went from 18m handsets sold to 29m! The big winner is the smartphone -- the big looser is the non-web-enabled "dumb" phone, not a specific smartphone OS.

So look away for a minute from the Androids and iPhones you and everyone around you are using 24/7, and all the cool kids on the Sillicon Valley blogs are talking about. This is not a time for early-adopter egocentrism. You can't really rely on statistics to guide your mobile strategy, either. It's very hard to quantify even current usage and to find numbers you could trust. But more importantly, mobile devices are a very volatile market. Even if you'd have the money to waste on building four different apps for the most important platforms, you may be hopelessly behind in a year's time. If the new Windows Phone 7 or MeeGo make a surge, what will you do? Ask for the budget to create even more apps? And if existing platforms start coming out in new form factors, will you update each one to make use of tablet resolutions? Do you really want to tie your mobile presence to something this fickle? (Unless, of course, it's actually an application, and not just a nice wrapper for your content.)

If you really want to be on the forefront of the mobile revolution -- and by now it should be evident that's where we're heading -- invest in a flexible delivery platform. That platform is the mobile web -- not apps. And the mobile web is delivered by a capable Web CMS. Start planning for publishing to a whole lot more than just one-size-fits-all, be it a large or a small screen. Take a look at what features you'd need (and of course, our Web Content Management vendor evaluations would be a good place to start). Because, well, you read it here first: the Mobile Web is an App killer... And for most purposes, Apps are dead already.

Which is definitely true. But first, I'd have to be able to afford a Ferrari; and not just the purchase, but also the maintenance. I'd also want to have learned to drive it to its full potential before even thinking of getting one. And preferably, I would be able to do some work on it myself, so I wouldn't have to send it off for days on end to get it fixed.

In fact, those are the reasons I drive a Mazda Miata, and not a Ferrari. I don't really care what the Miata's reputation is; I got it because it's affordable, and it's great fun to drive. And if I do ever get that F355 I'm eying, at least I'll have had plenty of practice in a rear-wheel drive manual transmission. I wouldn't let the expensive car spin out of control the first day got it.

Which, in fact, is a lot like the enterprise software we evaluate. So ask yourself: do you really want a Ferrari?

As we've noted before, Google is slowly catching up with what it's been marketing for years. One milestone was version 6.2, which integrated the SharePoint connector onto the Appliance itself -- instead of requiring a stand-alone intermediary server. And a key example in the 6.8 release is dynamic navigation, also know as "faceted" search, or "guided navigation" (an Endeca trademark).

Here, too, there was a "Labs" feature for "results clustering", which looks similar on the screen, but was very limited in its usefulness. It would take the first 1000 results of a query, and then display clusters of those results as links to navigate. Not exactly how you'd drill down on thousands of documents to find the one match to your criteria.

In version 6.8, however, the facets are complete -- they're produced during the indexing, and actually cover the entire corpus, not just an on-the-fly subset. If you look at the screenshots, you'll now see that behind the facets in the navigation, there's actually an exact number. (A first for Google -- normally, as on the web, the number the engine displays is a pretty broad approximation.) That may not look like a big thing, but it will be if you're using it to dig through your fileserver or intranet. Because "refining" a search doesn't really work if, well, the navigation isn't very refined.

Of course, Google's implementation still isn't very sophisticated (or flexible). Test the Appliance carefully before you commit, and compare it to other vendor's products. The GSA's ease of use may outweigh the shortcomings; but you'll want to know exactly what the drawbacks are before your purchase. The Google Appliance isn't a cheap shortcut. It's much too expensive to be an impulse buy.

His last slide argued that the old adage "content is king" is no longer true -- instead, "contact is king." That statement made a lot of sense at this conference, and was reiterated somewhat less eloquently by other attendees. If the event's all about mobile and social, why should there still be such a focus on content management?

Well, while Peter's talk was very insightful, let me be blunt about it. He was wrong about content. It's easy to think that in the totally interconnected, web 2.0, social, digital world, contact rules. However, without content, contact is nothing.

Without content, we're reduced to cavemen going "uuuurgh" at each other. A lot of social media is about pointing each other to interesting content. In fact, strip a Twitter feed of its shortened links, or take the shared pictures, videos, and blog posts out of Facebook statuses -- and "uuuurgh" is pretty much what you end up with. Without content, we're reduced to liking, or retweeting, grunts.

It's true social media isn't about that one handwritten manuscript secured in a monastery anymore. (The iPad is just drawing out publishers' hopeful belief they can still, somehow, imprison us in those middle ages where the medium would guard the monopoly.) You shouldn't just "publish out" your content to the web as if it were a book going to the printers. You can't just let your content sit there and wait for it to find an audience, or push it out and expect it to be consumed.

But that doesn't mean you should simply "go social" and care about contact only.

The truth is, networks remain very much about content -- about enticing people with information. Content doesn't live in one place anymore. No, it flows back and forth along new paths and channels, passing through the Googles, Facebooks, and Twitters that are vying to be the number one hub for the streams. But that just means it's become more complicated to manage -- not that you should give up on it and focus on the raw streams, instead.

In a digital age, content is the most valuable thing you've got. Forget about the content, and you'll eventually find yourself stuck in a lonely cave, discontentedly howling at the moon. Instead, manage your content -- and be part of the information age.

But of course, you should certainly buy Peter Hinssen's new book. If only to prove my point. And when you do... don't forget to tweet about it.

For instance, my colleague Apoorv Durga blogged about mashup vendor JackBe's app store a few months ago: "interesting but not new". But it's part of a bigger trend: by next year, nearly every product we cover, from Search to ECM, will have its own app store. I hear a new one being announced almost every month.

As Apoorv noted, the concept of a digital catalog of add-ons isn't novel, but the hype around it certainy is.  Alas, the sexy term "app store" doesn't remove the traditional burden to carefully assess the performance, stability, accessibility, security, upgradability, and play-nicely-with-others attributes of any 3rd-party modules you incorporate into your system. 

Things will get particularly confusing if you have multiple systems and services. For instance, Google has the Google Apps Marketplace. It contains anything from add-ons to single-sign-on cloud services, and even professional services. (Really, even consultancy is an app now?) Presumably, all of these would be excellent upgrades to your Google Apps environment. Perhaps you'll find Google Apps a bit limited for collaboration. So why not get Jive from Google's App Marketplace?

Even better, Jive has also announced its own App Store. It's not available yet (it's coming in version 5, slated for early next year), but over 50 third-party developers have already signed up to provide apps.

And what better way to use these than through an iPhone? Thankfully, that, too, is provided for: just get Jive's iPhone application. Of course, you'll have to go to Apple's App Store for that.

And then, you'll have the app for your iPhone from the Apple App Store, to work with the apps from Jive's App Store, while interfacing with Jive as an app from the Google App Marketplace, added on to Google Apps. One reason I could imagine this wouldn't work, is if Jive Express (the Google Apps app) wouldn't support the Jive Mobile Module (which is required for the Apple App Store app). But I'm hopeful it will.

A cynic would say I've intentionally tried to confuse you. Just in order to sell you more of our research, by telling you it would clear up this confusion. Of course, I'd never stoop to that level. (Though let's be clear on this, our research would certainly clear up the confusion.) In reality, what I'm looking forward to is a larger cloud service to house all of these app stores. Maybe we could call it the Sky Mall...

You may remember Cuil (pronounced "cool"), the would-be Google-killer that launched about two years ago. It was going to have a bigger index and a better interface. Some of the innovations they tried out in their interface were interesting -- the rest of it, not so much. And after Cuil's fifteen minutes of fame, visitors largely forgot about the site. As it turns out, a fresh UI and lots of results aren't enough. Searchers actually like to see relevant results, more than anything. And now, it's curtains for Cuil: the site's offline.

Then there's Clusty, Vivisimo's showcase for their query-side clustering technology. Vivisimo has moved on to producing a full enterprise search product in Velocity, which doesn't just cluster but collects and indexes, as well. Clusty never became a huge hit. However, it has served Vivisimo well: first as a nice live example, and then, when it was quietly sold off a few months ago, it also made the company a tidy $5.6m. Clusty is still there, but now it's called Yippy. (Seriously, who makes up these names? Maybe Clusty and Yippy could cheer up Clippy, who's been out of a job for a while.)

Of course, both were public web search engines, which is an entirely different scenario than enterprise search. But if you're working on enterprise search projects, you may still find value in looking at the web for examples. In the case of Cuil, because they might give you some ideas for improving the UI of your own implementation. The bland Google-like copies most vendors ship as standard with their products could usually do with some improvements.

Clusty was interesting as a public example is a large-scale, working proof of concept. Many of the vendors we cover in our Search & Information Access Evaluation Report have started out in, or showcased their technology with, a public web search engine. A non-exhaustive list would include:

• Exalead
• FAST, who started out with alltheweb.com
• Google and the Google Appliance
• Autonomy and the Blinkx video search
• Vivisimo with Clusty
• Other smaller players...

These can demonstrate that the technology does, in fact, perform at some scale. You just have to be careful with assumptions there, since the public search versions are often highly customized, or even completely different software. They can also display some of the quirks of the specific vendors. Just throw some odd queries at them and see what they make of it.

So, let's say goodbye to Cuil and Clusty, and hello to Yippy. And let's keep public web search engines in the corner of our eye when watching enterprise search evolve.

One of my pet peeves about both mobile and social is the amount of hype surrounding the topics. There's no denying they're of huge importance to any enterprise right now, but the buzz can be deafening. However, conference organizer Erik Hartman has created a great program, with a nice mix of theory, tools, and a lot of practical use cases. I think attendees will get many useful ideas out of it.

I'll be talking about mobile delivery and social engagement through the tools and systems you may already have (such as a web content management system). Theresa will focus on digital assets -- getting video, audio, and brand assets to the mobile web. But of course, we're not just there to talk -- the interesting bit of any event is always to listen. (Fortunately, about half the presentations will be in English -- so no need to learn Dutch to attend.)

So join us the 7th in Utrecht, and if you're there, come up and talk to us. As a reader of this blog, you'll receive a 200 euro discount by using the discount code RSG2010.

If you read the announcement, you'll note Movable Type is mentioned nowhere. It's all about creating "a modern media company." Read: it's about delivering ads to audiences. Put more cynically, it's about the (overlapping) VCs behind the two companies dreaming about revenues worthy of a decent cash-out -- creating a social media Google, minus the search thing.

Looking at the SAY Media site that went live today, you'll have to check carefully to find Movable Type. (Hint: down below between the grey links.) It's hard to tell if there is any actual mention of the product, since the site has no search engine and hasn't been indexed by Google or Bing yet -- but I haven't been able to find it. I'm pretty certain the SAY website doesn't mention Britney Spears, either. And that should be unnerving to current Movable Type users.

The Movable Type site still showcases Britney Spears as a major reference, and through a strange coincidence, the two iconic brands have managed to coordinate their rise and fall. As Movable Type changed from free to for-fee licensing in 2004, Britney entered a difficult period in her life and career. Of course, MT still had some staunch supporters, and Britney's fans kept defending her through her ordeals as well. Then, by the end of 2007, Spears released her album Blackout, and MT went open source. Things where looking up.

But that's where the parallels end. While Blackout was a successful comeback, Movable Type's open sourcing hasn't managed to recreate the community that once was. To further fragment it, there's also a fork of the MT project called "Melody." Unfortunately, that doesn't really seem to be able to carry a tune, either. Movable Type came out in a new version 5 at the beginning of this year, but that version was long overdue and somewhat disappointing. Worse, the "enterprise" version of MT is still in version 4 over half a year later. It's a lot like releasing remixes instead of new original material.

If you're a current MT user and want to be reassured, you'll have to make do with the only quote on that I've been able to find: "Alden says that Say Media will continue to support and grow the Typepad and Moveable Type platforms." That doesn't exactly sound like the step up in pace MT would need to stay competitive.

However, if there's one thing Britney Spears could learn from Movable Type, it's conquering Japan. While Britney never managed to gain an audience there, Movable Type seems to be a popular CMS in that market. But being big in Japan alone may not be enough for a sustainable career. Unless you're firmly committed to Perl over PHP, and static publishing over dynamic, I'd suggest you go down to your local blog shop and consider some alternatives.

You can still get Movable Type, with regular bugfixes; but it's not the party it once was. The label has moved on.