In so many areas, software is getting better. Languages are more
robust, databases are easier to line up, and interfaces are more
intuitive. But web content management systems continue to be ...
umm, off-target. Why is that?
I was thinking about that puzzling phenomenon this week while
hacking through a problem with a CMS we are implementing, Umbraco.
Now Umbraco is a pretty cool tool, both from a coder's point of
view and an author's point of view. For developers, it snaps
together like a .NET project -- in fact, our team is using Umbraco
"macros" (their jargon) and .NET controls interchangeably on pages.
For authors, organizing the site is like organizing folders in
Windows -- intuitive.
Yet here we are, on this particular project, trying to reconcile
the graphic artist's CSS/HTML with the developer's need for
leveraging .NET controls and the author's expectation that the
interface should be as easy as Word. And by the way, will this end
up being a website people will, you know, use?
The problem
Part of the problem is that there are so many CMSes, and they
differ so much from each other, that there's no easy way to gather
or share hard-earned knowledge. As Tim Bray says: "I know of no
place where you can go and read a concise summary of all this
tribal wisdom. The only way I know is to go to a conference and
talk to your peers. That's the only way to find out where the
bodies are buried."
Part of the problem is the continual tension between the
orderly, methodical process of software development and the
organic, chaotic nature of creative development. It's hard to build
a one-size-fits-all page template when you haven't written any
content yet and therefore don't know what "all" consists of.
There's always a tradeoff between consistency and flexibility, and
you just have to make your best guess and accept you'll miss a
few.
Finally, part of the problem is the danger of inwardly focused
development (aka navel gazing). The developer tends to see the
system in terms of entities and objects and classes, while the
author tends to see it in terms of words and images and workflow.
Who is keeping the reader in mind?
The solution (or part of it, anyway)
At StoneHenge Partners, we spend a lot of time planning a
project with the end-user in mind. It's part of our Nimble
Methodsm,
our unique blend of practices and methodologies that enables us to
promise, with confidence, to deliver projects on time, on budget
and on target. Two key practices speak to this issue:
- UX: During the Discovery phase, I build a User
Experience Blueprint. The UX includes personas of the primary and a
couple of secondary users; a mind-map of their needs, tasks and
"happy paths"; and page wireframes, process flows and content
modeling. (Maybe you can tell I love this stuff?) This helps us get
into the mind of the only key player not represented in person
during development: the end user.
- DDD: During the Design phase, the technical
architect builds a Domain-Driven Design. As Matt Peters so ably
described it here, DDD is the
practice of defining chunks of code -- be they .NET controls,
Umbraco macros, or whatever -- in terms of the end product. If
you're building a car-rental reservation process, he says, then
call your objects "car" and "renter" and suchlike. The same applies
to a CMS.
Anyway, we're learning as we go. Next up is a website for fly
fishermen. That should be interesting.