CMSish

where web content management and user experience collide

Hey, agile developers: the CMS is a different product from the website

So you’re working on a big new website development, overhauling all the functionality and delivering a better user experience to your site visitors. Naturally you’re using an agile development methodology. It’s going to rock.

In this scenario, it’s very easy to think of the CMS as merely a component of your solution. Probably there’s a little box for it on your high-level architecture diagram.

But really, the CMS is a distinct product (in the agile sense). It has a different set of customers, ie. the staff who will be updating the site content. They have different goals from your site visitors.

That means the CMS needs its own agile track in your development process. Most importantly, CMS development (or, more likely, customisation) must have its own customer representative, who represents the product stakeholders (the staff), and who drives development priorities.

If you treat it just as a component, then chances are your developers will implicitly be taking this role on themselves. They will be setting priorities and making decisions on behalf of stakeholders who they simply don’t represent and quite possibly haven’t even spoken to. This is a recipe for bad product.

How will you know if you’ve succeeded? Again, you should apply many of those same techniques that you’d use to optimise your site to ensuring that your CMS is also great. A/B testing might be tricky given the likely small size of the customer base. But you should definitely have a clear idea about success metrics and how to measure against them. Whatever methods you’re using to evaluate the site, it’s worth thinking about whether and how they can apply to the CMS.

It’s puzzling to me that there are some developers who seem to think that this is a waste of time. I bumped into one on Twitter recently. But over the last decade in particular, developers have benefited enormously from better tools and processes, making them way more productive and happier with their work [yeah, "citation needed", but I believe it’s true]. Why would you expect that you can dump crappy tools on other staff and still expect them to do the best possible job?

This post based on a true story.

Filed under: Development, ,

You know what’s fun?

Gamification does sound like an interesting idea. Can we make business software more enjoyable by adding game mechanics? Embed things like leaderboards, badges, etc to make our applications more engaging. It’ll be fun! 2010 saw a surge of buzz around this idea, followed soon enough by a backlash. I’ve read way more anti than pro gamification posts in the last year.

Well, maybe that’s just because of poor, lazily thought out implementations? A recent article on New Scientist [paywalled] suggests not. Adding these kinds of mechanics can actually reduce productivity and user satisfaction. You get a similar unintended consequence with, for example, paying school students to read books; research seems to show that these children become less likely to read books when they’re not being paid. The intrinsic motivation of reading because it’s actually fun has been replaced by an extrinsic motivation of reading in order to get rewards. Not really the desired outcome!

This reminds me of Raph Koster’s Theory of Fun. One of the criteria that makes something fun, in Koster’s view, is precisely that you don’t have to do it.

OK, so forgot gamifying the interface. What would make the user experience for business software, if not fun exactly, then at least more enjoyable?  In the realm of content publishing and curation, here are some ideas:

  • You can always undo whatever it was you just did
  • You don’t have to repeat the same action a thousand times like a mechanical monkey
  • You can update a whole bunch of documents in one go
  • You can leave work half-finished without getting errors (aka “go to lunch”) and come back to where you were
  • You never have to drill down through deep hierarchical folder trees (unless you’re a developer. Developers love that crap)
  • You don’t have to jump through irrelevant workflow hoops dating from when the system was installed
  • You never lose work because something crashed
  • You don’t have to translate what you want to do into a language the system understands

I think you see where I’m going with this. Usability is the new fun! Goal oriented design is the new gameplay!

On a completely unrelated note: I’m in Florida atm, working on getting Contentment’s first product to beta release while waiting to watch the space shuttle launch. It’s sad to see the shuttle program coming to an end. But it’s interesting how the smaller and more agile approach has yielded better returns in space exploration over the past decade. As with space exploration, so with content software?

Filed under: Publishing, Usability

Design vs content in digital magazines

Data journalism and infographics
I was over at Guardian HQ last Friday for a small but well formed event on data journalism. A panel of five discussed infographics and the business of digging news stories out of data.

Simon Rogers kicked things off with a summary of what the Guardian is doing in this space. Back in the day when we both worked at Guardian Unlimited, I didn’t always see eye to eye with Simon, but I admire the good work he’s doing these days with the data blog.

David McCandless, author of Information is Beautiful, was also on hand. Perhaps his most startling infographic was his CV. It turns out he never trained as a designer or did much more than dabble in design until a few years ago. Not bad for somebody who wrote what (I’d guess) was the year’s best selling design book.

In the Q&A there was discussion about whether some visualisations are only beautiful; nothing more than illustrations that add a bit of colour without clarifying anything—or in the worst case, even misrepresent the story. The latter case aside, I’d say visual variation is a legitimate end in itself. There’s nothing wrong with being pretty.

Still, it’s also the case that the best infographics work as an integral part of the story, and can bring out new insight. Design is being used here as part of the storytelling process. In the current Age of Skim Reading, the infographic is the story for many readers.

Which came first, the design or the content?
Which brings us to web templating and digital magazines.

Web template design is done before the content has turned up. The design is a bucket that gets filled with content. So there’s no real relationship between the design and the content; the design is not part of the story, merely part of the brand.

Most magazines, otoh, are designed around the content. Sure, there will be brand assets, master grids, baselines and so forth that get reused continually; but the design for each set of pages essentially starts with a blank slate and the story. The finished product is a story told with a mix of words and design.

There are pros and cons to each approach. Templating is highly scaleable. It has low production overheads once the templates have been created, so fits better into a tight production schedule. It deals better with distribution to multiple channels and devices; for each template A you can have (say) a matching mobile template A*.

But templates have to be “content-proof”, so that they don’t blow up when they encounter unexpected content; this is a really big constraint in practice. Templates don’t relate to the particular content of any story. And obviously they tend to look a bit “same-y”. All in all: an inferior user experience.

So this is the hard problem for digital magazines: is it possible to design content in a way that 1) can work across channels, and 2) can be done quickly enough and cost effectively enough to be viable.

Magazine options
Some people think magazines ought to just get with the programme, and adopt the web design paradigm so that their content can be easily pushed out to whatever digital channels are appropriate. This needn’t be as limited as it sounds. Your templates don’t have to be dumb buckets; you can make them pretty smart, so they introspect the content and format accordingly. It’s still lossy though; you’re still decoupling the design process from the storytelling.

Come to think of it, that decoupling is what in the CMS world we call “separation of content from presentation”, and it’s generally thought of it as a Good Thing. Is that a shibboleth we need to abolish in the magazine world? For search indexing etc, maybe it’s enough that it can be separated, after the fact.

Meanwhile, Adobe and Woodwing are building iPad-oriented solutions based around InDesign, the magazine publisher’s weapon of choice. This is a high-fidelity approach, which follows exactly the same design process as print. Which means it’s quite time intensive, and requires new design work for each device aspect ratio/orientation. Not to mention that the only way that they’ve found to make this non-lossy to date is to, er, bake the pages out as images… There’s talk about “adaptive design” and generating HTML5 in future releases. The truth is that a transition from InDesign to HTML (5 or otherwise) is likely to be quite lossy for the foreseeable future. Being a bit elastic is precisely one of HTML’s great strengths.

Which is the best approach? In short: I don’t think anybody’s there yet. It’s a matter of making a pragmatic decision that works for the moment (eg. only target iPad, “letterbox” your design for other devices, forget smartphones), while waiting for developments.

Filed under: Design, Publishing, , ,

Great open source user experiences

So software is (finally!) in the Age of Experience, where the world’s biggest tech company could plausibly be described as a user experience business, and where better UX is helping drive millions of dollars of market growth.

In that light, I’ve compiled a bulleted list of open source apps that offer a truly great user experience, with screenshots and  detailed notes:

Now I’m pretty sure I’ve missed one or two there. Please do set me right in the comments. But it’s going to be a pretty short list however you cut it. Why is that?

My first guess is that it’s about the social organisation of open source projects, that makes it difficult for people who aren’t hardcore devs to get involved. But I could be totally misinformed on this.

btw, this is NOT about being anti-OSS. It’s a good model that has produced a lot of great code, some of which I use every day. But nothing very user-facing.

Filed under: Design,

Always wrong is doing it right

On an agile project—and is there another kind these days?—being wrong is no big deal. It’s usual, even. You might as well get used to it. You’re wrong because:

  • You don’t have all the information to hand at the outset.
  • You don’t have time to wait for all the information you need.
  • If you waited, the requirements would change anyway.
  • There’s usually more than one way to tackle a problem, and the best way often isn’t clear up front.
  • You might know the right thing to do, but have to descope or hack it in order to hit a deadline.

That last one is after all a key aspect of agile: the trade-off you make to achieve hard deadlines is to jettison functionality. Leaving you wrong by design, as often as not.

So you’re wrong. Then you iterate, and with each iteration you’re less wrong. But you probably never eliminate all the wrongness. The requirements change again, or it’s simply not cost effective or a good use of your time to go back over something that’s wrong but good enough.

A great current example is the iPad. It’s so full of wrongness, missing so much functionality that you might naively think it couldn’t possibly go to market yet. Want to transfer a document from one app to another? Want to style some text in any app whatsoever apart from Pages? etc. It’s funny that Apple explicitly rule out “beta” apps appearing in their App Store; well, unless you consider all apps are always beta, because they’re always wrong. But actually the iPad has more awesomeness than wrongness, and the former more than makes up for the latter. They’ll sort the bad stuff out later, probably.

Which leaves this problem: it’s human nature to dislike being wrong. Even worse to be told so. We all know developers can be a, erm, stubborn bunch convinced of their own innate correctness, who find it harder than most. For sure I count myself in that camp.

I wonder whether this isn’t one of the harder virtues of the agile developer: to be able to live with being always wrong, and not mind having it pointed out where necessary.

PS. Yes, sure, you can also be wrong just because you’re, well, wrong. Because you’re a dumb-ass and clueless. otoh you might get lucky with your project and be 100% cast iron right from end to end. So I should really have titled this post “If you’re not always wrong you’re probably not doing it right”.

Filed under: Development,

You need to pivot for your internal customers too

I’m a fully paid-up fan of the lean startup movement, as popularized by Eric Ries. The core idea: iterate fast to discover who your customers are, and pivot to better address their needs. Given the way agile methodologies and modern web frameworks have accelerated the pace (and reduced the cost) of web software development, this approach makes a lot of sense if you’re building a new consumer-facing app.

But are these ideas also applicable in the CMS world? I think so. CMS is a broad church, with many products and very many features bundled into the average product. That diversity is good because (as, eg. Tony Byrne and co never tire of telling us), so are customer needs and use cases. For most CMS projects of any size, there will be a significant amount of implementation and customisation work to get the product tweaked for the particular scenario; often half the budget or more.

One approach would be do to a detailed analysis before you start the implementation; define stories, roles etc. Then configure your product to match that specification.

Or you could go the lean route. Just ship. Install the product, watch what the users do, and tweak the implementation as you go: pivot to meet their needs.

But that suggests some new requirements for your CMS. First, you need to be able to see what users are doing: what kind of analytics does the CMS expose for editorial usage? To some extent you could use surveys or workshops here, but hard stats will certainly help. And then how quickly can you act on your findings? For example, how easily can you reconfigure your CMS UX—and then roll back if you get it wrong?

There are risks with this approach of course: your editorial users need to be involved in the process so that they don’t get frustrated by the ground shifting under their feet: consistency is close to the first law of UX, after all. But on the plus side, you can get started more quickly, and your solution should end up better aligned to editorial needs.

I’d be interested to hear any success (or horror) stories from people who’ve gone down this route.

Filed under: General, , , ,

What the iPad means for web content management

Publishers are understandably excited about the iPad, for a couple of reasons other than simple gadget lust. First, Apple have already implemented a hugely successful paywall in the iTunes store, selling music, games, TV, films and apps. With the introduction of the new iBooks app, publishers hope that consumers will (finally!) be willing to cough up for magazine and news content delivered over the web.

In addition, many see the iPad as offering an opportunity to deliver more engaging content. It seems likely that iPad content will be able to achieve something close to print quality layout and typesetting, but with the added goodness of video, audio and social features. That could be pretty exciting, especially for magazine content (though I expect there will be teething troubles, eg. the return of the splash page…)

These two things aren’t unrelated: more engaging content will help justify the introduction of charging. I’d guess many publishers are also hopeful there will be a resurgence of professionalism, figuring that only they will have the experience and skills to generate quality layout on a regular cycle.

But there’s the rub. As Bill Jensen of the Village Voice pointed out during a panel at SXSW this week, existing production processes are unlikely to support the necessary workflow.

For print-to-web productions, here’s what typically happens at present: copy and images are prepared for the print edition (using, say, InDesign), with attention to word counts and layout so that it all fits on the page. Then the raw content is exported to a WCM, discarding all the layout information (which would be pretty useless anyway, as tablet dimensions and resolution will be significantly different from the printed page).  In the WCM, there’s likely some extra metatagging etc carried out by the web team, with rich media content blended in. But there’s not usually any layout to speak of: content is simply pumped out through fixed web templates. At most, the web team choose from a set of pre-existing templates.

Bringing per-page design, layout and typesetting back into the equation is a big shift, and one that I’d guess most existing WCM solutions will have trouble coping with, certainly not without expensive customisation or reengineering. In the short term this might create greater opportunity for vendors like Issuu, who are already generating “digital editions” of print publications, albeit without much in the way of webbish enhancement.

But if the iPad is successful and this scenario does play out in the wild, then pure-play WCM vendors may need to gear up to make significant changes in their product functionality; hopefully via a deeper integration than just bolting on a standalone iPad solution as an additional layer of production workflow.

Filed under: Publishing, , ,

Stickybits: more content management for the internet of things

http://www.stickybits.com/

where “things” in this case are identified by barcodes, rather than any kind of geocode. Yeah, barcodes, the poor man’s RFID. Except that 1) you can actually find them in the wild, and 2) barcodes are like class variables to RFID’s instance variables. In a lot of contexts (eg. shopping) that’s more useful.

Stickybits’ focus seems to be on tagging barcodes with related digital assets; but you can add text as well, and you can imagine how the service could be quickly extended to add more CMS-like functionality (assuming anybody turns out to want it).

Unsurprisingly – given the somewhat porny name – they’re a startup. My guess is that most of the interesting plays in this new arena are NOT going to come from established CM vendors, though there might be a bit of acquisition down the line.

Filed under: Recently seen, ,

CMS events at SXSW 2010

Here’s a list of the obvious content management-related events I’ve found in the SXSW schedule. Do let me know if I’ve missed anything.

Web Content Management Systems from a Designer’s Perspective
Sat, 9:30
Not a lot of info at this one. By Scott Fegette from Adobe and  Chris Charlton from XTND.US

CMS Admin. UX Gateway to Heaven or Hell
Sat, 11am

With so many different people using Content Management Systems there should be a best practice, intuitive user experience for the admin. So why do Drupal, Joomla, WordPress and others do it so differently? Take an inside look at the UX process used in developing some of the leading CMS admins.

A topic dear to my heart. Though if those are the only products under consideration, the scope is a little narrow.

Bringing it All Back Home: CMS Communities
Sat, 12:30

When you adopt a Web content management platform, you’re not just getting the software, you’re also becoming part of a community that develops, uses, and supports it. With the help of representatives from the Drupal and SharePoint communities, we’ll explore how different CMS communities are structured and operate, and the impact that they have on the experience of using that software.

Managing Your Content Management System
Mon, 9:30

An effective content management system is a must for any content-based web service. This technical session will discuss elements of designing and building a custom CMS that leverages technology and existing web data from sources such as Flickr and Wikipedia to automate research and increase time spent writing original content.

R.I.P. Content Management System
Mon, 11am

The medium is the message. On the web, the medium is community. This shift has made legacy CMS products as outdated as scribes and printing presses. Open source technologies are disrupting this market and moving into mainstream enterprises. Join Drupal founder Dries Buytaert as he discuss how social publishing will bring content and community together.

Slightly provocative (ie. troll baiting) title for this talk by Mr Drupal, Dries Buytaert

ExpressionEngine 2.0: Total Domination!
Mon, 12:30

ExpressionEngine is growing in popularity and with the release of 2.0, it’s power has expanded to the stratosphere. Powering great websites such as Change.gov, A List Apart, and Campaign Monitor, it represents an amazing way to build websites and publish content. Join us as 5 experts give best practices from a beginner front-end level up to extension developer supreme

Official winner of the “most product-pitching event title”, 2010.

It’s worth noting that there are many other events of interest to CM people; in particular, a load of stuff around content strategy.

Filed under: Events, , ,

What’s the core entity in the WCM data model?

Is it Document or Page? Or should you go lower level: what about Component or even Attribute?

Actually, trick question. I’d say the core entity is more like Task or Process. Without these kinds of things, where’s the “management”? You’ve just got a content repository. WCM is about letting people do things with their content. If you’re doing goal oriented design (a good idea!) then this is the place to start.

Filed under: General, ,

My tweets

Error: Twitter did not respond. Please wait a few minutes and refresh this page.

Other stuff

Follow

Get every new post delivered to your Inbox.