ChrisScott.org

Content is king, is it? Well maybe. There’s no getting away from the fact that good quality content drives traffic. But in the struggling publishing industry, with waning advertising revenues, we might have to conclude that the current approach to web publishing is just not working.

That’s not to say there aren’t exceptions. Julian Sambles (@juliansambles), head of audience development at the Telegraph Media Group, talked at the resent ePublishing forum on his success in terms of SEO and bringing new audiences to the Telegraph site. No doubt other publishers have had similar successes. However there are problems associated with that kind of drive for SEO – not least because it is a very expensive process in a climate where large budgets are scarce. But, for me, I have more important reservations about focusing heavily on search engine optimised content.

Firstly, there is the issue of editorial integrity. If content was truly king then its quality would be the single most important factor in growing (and keeping) an on-line audience. For a lot of publishers  content isn’t king though – search is. In that scenario a publisher is not controlling how it’s content is consumed, or in what order. They will, undoubtedly, find that their political and social stances are watered down as well, as traffic heads more to soft news and opinion. In circumstances like these the focus actually moves away from the content and towards how the content is structured – the role of the publisher gets closer to that of an aggregator.

The next problem with relying on search engines to supply ones’ on-line audience is inherent: the consumer is researching not discovering (@matt_hero’s search trilogy is, loosely, relevant here). I seriously doubt Google is inundated with searches for the word “news”. Perhaps terms like “football results” are more common but still not that frequent. If a visitor arrives at a site from a search engine it is fairly safe to assume they fall into one of two categories:

1. They’ve already read the news elsewhere, first.
2. An aggregator has presented them with summaries and the content suppliers only get a hit (and, hence, revenue) for the stories they are really interested in.

Of course, if that visitor then stays on the site – or book marks it even – then great. Of course search engine optimisation creates new users and they can become regular visitors. The problem is that without a strong brand the proportion of stray surfers who end up on a content producers site to those which are converted into frequent readers is much smaller.

The prevailing opinion these days is that the fickleness of consumers comfortable with search is inescapible; that hitting the top spot on Google is overwhelmingly the best way to drive traffic. I just can’t believe that. Certainly that sentiment doesn’t apply to me. I’m quite modern in my consumption of the news: I almost never buy a physical paper any more. But that doesn’t mean I don’t appreciate the editorial “package”, as Drew Broomhall (@drewbroomhall), search editor for the Times, described the journey a (print) newspaper reader is guided through. Every morning I embark on such a journey, lead (very ridgedly) by the BBC’s mobile site. And, while monetizing mobile content is harder than on traditional web pages, that builds a very strong brand loyalty for me. If I read any news at work, or explore in more depth a story I read that morning, it’s always on the BBC news site.

So I would argue that the readers experience – the editorial journey – is far from a thing of the past and, in fact, is as important now as it ever was for print media. There is no need to limit that experience to mobile channels, either. There are a wealth of frameworks available for producing widgets and apps on all kinds of platforms. Another talk at the ePublishing forum, by  Jonathan Allen (@jc1000000), explored in more depth how to take advantage of these output channels. iGoogle widgets, iPhone apps, Facebook applications are all great examples.

This approach not only allows publishers more of the editorial control which they had in producing print media (and lost to the search engine) but also creates a better user experience. Focused distribution channels for on-the-rails feeds can give a consumer the feeling that a publisher is doing something for them. With news being such a commodity in the on-line world these channels add real value for the audience. And if there is value for the audience, they will promote that content themselves. Creating, for example, a widget for an iGoogle user’s homepage, which displays featured articles, engages them (and presents a link back to the original content) before they have even done a search.

We see this kind of, selected content, approach commonly in the form of RSS feeds (although, too often as “latest” not greatest). Widgets and apps aren’t really doing anything different, rather they are making the stream more accessible, more user friendly. There’s another attraction to widgets and apps over RSS feeds, though – a point from Jonathan’s talk which almost makes these channels a no-brainer – they really help to boost the main document’s search engine ranking. So contrary to being an alternative to SEO widgets help drive traffic both ways.

You can take this one step further and allow the audience to define their own paths through content. As semantic understanding becomes more and more achievable, through tools such as Nstein’s Text Mining Engine (TME) and the dawning of an RDF bases semantic web, publishers will be able to offer dynamic widgets with content ordered by an editorial team and filtered by a user. The iGoogle widget described above could easily be filtered for a Formula One fan based upon data from the TME to create a custom feed of stories they are interested in. Or if a consumer enjoys the “package” they can take the unfiltered list.

No silver bullet for publishers struggling in the migration to the web, for sure, but thinking about how content is offered as a package is a strong, and often underused, way of strenthening a brand and driving traffic. As always, IMHO…

At the tail end of last month I spent two days attending talks at the yearly Internet World exhibition. I always enjoy listening to speakers and the quality was, by and large, very good. On the final day CMS Watch (@cmswatch) hosted a panel discussion in the Content Management theatre entitled: “Open Source v Traditional Software”. It’s was a strange title, I thought, as the line, for many vendors, between open and closed source becomes more and more vague. This blending was, however, represented in the panel, which included Stephen Morgan (@stephen_morgan) of Squiz – a commercial open source vendor.

On the whole the panel was very good and the debate interesting. The open source contingent argued eloquently  the pros of spreading knowledge throughout the community and of the response times to bug fixes compared with the release cycles of proprietary software. One of Stephen’s responses when asked for reasons to go with an open source system, however, struck me as – at best – ill conceived.

Stephen had argued that as a customer of a closed source software retailer you fall, entirely, to their mercy in terms of functional changes. The assertion was that when you – as a customer – have access to source code you can modify it to suit your needs. Conversely, he claimed that changes to a closed source solution could only be requested, may never happen and would be subject to a lengthy release cycle even if they were implemented.

Now I’m sorry but that is just not the case; as I told the panel once the discussion was opened to the audience. The software I work with, Nstein’s WCM, features an expansive and  well designed extension framework to do just what Stephen was referring to. In fact, I went further and put the polemic to the panel that hacking core source code is obviously not desirable and severely hinders an applications upgrade path. Stephen’s countered with the fact that changes made to the code-base can be submitted to Squiz (or almost any other open source software maintainer, for that matter) and may be committed into the core application.

Before I start a holy war here (and a succession of flames in this sites comments) I would like to state my position on open source: I love it. I love the concept. I love free software. I love the freedom to modify and distribute software. Basically, I get it. I’m a huge fan of Linux and at the end of the day a PHP programmer. Just yesterday, I spent my Saturday contributing PHPTs (that’s PHP tests, for non-geeks) with the PHP London user group. I really do dig open source. Also, for the record, I thought Stephen Morgan represented his brand and community very well and I enjoyed his commentary; this is not meant to be a personal attack ;-) .

In fact, this post is not criticizing open source software at all. The discussion here, as far as I am concerned is about best practices. Okay, sure, one can modify the source code to an open source project and that change may be incorporated into the software. May be incorporated; probably won’t be. And with closed source software that option is not available – you have less choice. But that is, I think, a good thing.

At least the prelude to a good thing. Software evolves, like all technology, and the beautiful simplicity of Darwinian evolution applies. It’s survival of the fittest. If we, at Nstein, were to compete with open source CMS projects with a solution which was not customisable, which had no mechanism for modification we would have died out. The fact is we make a vast amount of customisation possible – we’ve had to. Because we don’t encourage customers to delve into the core source code (it’s a PHP app so they can if they really want) we’ve had to employ other methods. Extensible object models built around best practices derived from industry experience. Plug-in frameworks. Generic extension frameworks. If one of our customers cannot extend or change something that they need to the chances out that another client will at some point want that same, absent flexibility. So, through good design practices we have constructed a system which clients can (and do) modify, yet when they decide to upgrade to the next point release it is a trivial process.

Now, I’m not saying that open source software is poorly designed. I’m writing this piece now on WordPress – a fantastic example of an open source project – which features an extremely rich and well documented plug-in framework. The sheer number of plug-ins and themes available for WorldPress is a testament to the system. And, as with Nstein’s software, when I upgrade WordPress all of my extensions still work (at least 95%, or more, of the time).

I doubt anyone would disagree with the merits of a plug-in based system. My interest, however, is in this question: how much of a temptation is there to hack open source software? I know I’ve done it in the past. I’ve heard a number of times that Drupal upgrades are nigh on impossible due to the nature of the inevitible customisations a Web content management system requires. I’m not in a position to answer that question authorititively, and I won’t attempt to. I would like to stir the debate up though. So, thoughts, please….