Last week I wrote a post on why people have few nice things to say about their CMS. I titled it Content Management and the Problem of Scale. That title sucks. I mean really, who but a handful of content management geeks would be inspired to read a blog post titled Content Management and the Problem of Scale? What was I thinking?
I should have called it something like Why You Hate Your CMS. In fact, I have renamed that post Why You Hate Your CMS. Not sure if that is the best possible title (apparently I suck at titles) but I’m sure it’s an improvement.
This is not the first title I have written that sucked. A few years back I worked on a product that used XML for configuration. There were a number of different XML document types involved in a complete configuration, and, because this was a partitioned system in which many different people contributed modules that had to be integrated with each other, those documents were often written by different people, often working for different companies.
The product developers assumed that schema documentation generated by one of the standard schema documentation tools would be all the documentation that we needed. But it was clear to me that we needed something more than this.
A schema is just a grammar. It tells you what tag is allowed where. It does not define the semantics of the content or the business rules that apply to it, especially when different documents that follow different schemas have to be coordinated. And some of the schemas in this system defined multiple document types, and reused elements in different places, where they had very different business rules attached to them.
For all these reasons, I argued, the users did not need a schema reference, they needed a reference for each of the XML document types that they would be creating, which would include not only the syntax but the business rules that applied to each setting in context. So, we crossed Schema Reference off the list of planned documents and wrote in Document Type Reference.
The problem is, the title Document Type Reference sucks (so does Schema Reference, but that’s beside the point). The document should have been titled Configuration Settings Reference, and in the next release, it will be.
There’s no great mystery about why the sucky titles suck, or about why the better titles are better. The better titles speak to the user’s concerns. They say, if you hate your CMS, this is the blog post for you; if you want to configure your system, this is the reference for you. The sucky titles suck because they don’t do that. This post isn’t about how to write good titles. It’s about figuring out why, despite knowing what a good title should do, I sometimes write bad ones.
The Document Type Reference title sucks because I am a geek (an XML geek, in particular) and I was having a geeky argument with some developers about the difference between a schema and a document type. The title Document Type Reference was a flag planted in the field of victory. And as is usually the case in these things, no one gave a thought to the needs of the civilians.
The reason Content Management and the Problem of Scale sucks is perhaps more subtle. It is a summation. The essence of my argument in that posting is that the reason people don’t like their CMS is that a CMS is attempting to address content on one scale using techniques appropriate for a different scale. The process does not fit the problem, so the tool cannot possibly be satisfying to the user. So, the problem is one of scale, and the subject is content management, so, in summation, the post is about content management and the problem of scale.
But summaries don’t make good titles. They point to the conclusion rather than the problem. It is the problem that attracts the reader’s attention, not the conclusion. If they had the conclusion, they wouldn’t need the article. It is because they have the problem that they might be interested in the conclusion, and so the title should point to the problem, not the conclusion.
How I made this mistake is interesting to me, because for titles, as for so many things, it is pretty obvious how to do a good job if you think about it. I’m sure we could all write a set 0f tips on writing a good title, and they would all cover most of the same points. And yet we all still manage to write bad titles sometimes. We all manage to do all sorts of other things badly though we know perfectly well how to do them well. And yet our minds set themselves on a particular course, and we forget everything we should know in pursuit of a single idée fixe.
Writing should be a team sport. The reason we need editors is not because we don’t know how to write well, but because writing well is such a multifaceted project that it is hard to keep every consideration in mind as you work. We need editors to catch what we would have caught had our minds not been running on a different set of rails at the time. But we don’t have editors anymore. Writing has become a solo event.
So my question is, how do we keep it in all in mind when we are forced to work alone? How do we access all the stuff we do actually know, when our focus on the immediate subject, the immediate argument, or the immediate conclusion, blocks all that stuff out?
Thoughts? Because I really want my titles to not suck in future.