For some time now, the tech writing industry has been moving away from optimizing usability and navigability of documentation for print, and on to optimizing docs for the online use. One style convention that is coming under increasing fire is the use of title casing.
Revoking an integrated login privilege (Sybase Central) <– sentence casing
Revoking an Integrated Login Privilege (Sybase Central) <– title casing (notice the capital letters)
The deception of title casing
Title casing is admittedly more majestic. It presides over a page. It is Ruler Of Topic.
Sentence casing? Far less imposing. It barely makes a statement unless you embolden it to. But what it lacks in appearance, it makes up for in adherence to truth. Sentence casing teaches the reader which words are standard words and which are proper nouns. It stays true to the meanings of words and avoids unnecessary confusion.
Set up a Linked Server Using an Interactive Application <– which are the proper nouns – can you tell?
Turns out none of them are. But I would have assumed that either, or both, ‘Linked Server’ and ‘Interactive Application’ were proper nouns. Likely some kind of component, maybe even something I got for free with my software, yay!! This type of cueing can cause confusion for users, and certainly perpetuates many authoring mistakes. Editors and red pens everywhere would likely breathe a sigh of relief to see the casing of titles stay true to the actual nouns they deliver.
The officiousness of title casing
Switching hats to being a consumer of docs, now, I find there’s also an officiousness about caps that is off-putting. Perhaps because caps are often used in cryptic software acronyms, which I appreciate the efficiency of once I learn them, but which put me off until I do (yup, we have them too 😏 ). And then there are all those esoteric acronyms I encounter in chat, IYKWIM. But it could also be because caps are used to SHOUT AT PEOPLE in text: also off-putting, especially when they come in the form of error messages (PERMISSION DENIED: Contact Your System Administrator).
The distraction of title casing
But if easier maintenance, improved consistency, and less shouting aren’t considerations in the case for sentence case, then there is the aspect of cognition in word recognition that many psychologists have been studying. They’re proving reasons why we are more likely to detect some typos vs others. For example when the word ‘test’ is misspelled ‘tesc’ we almost always catch it, but when it’s spelled ‘tesf’, we almost never do.
It’s something to do about word shape, and our ability to skim past a word once we’ve spotted a few recognizable letters and the word’s general shape. Read a rock solid article by Kevin Larson on this on the Microsoft site (http://www.microsoft.com/typography/ctfonts/WordRecognition.aspx). Unlike me, Kevin did the work to read all pertinent studies and summarized – thank you, Kevin 🙂
Anyway, this discovery means that if we don’t want users to be able to read titles fast and glean meaning quickly, we should change the shape of the words.
For Example, If You Want Your Users to Really Slow Down to Read the Warnings, Disclaimers, and Recommendations that
They Haven’t Been Reading, Maybe Gum Up the Wording with Lots of Caps.
Stop the madness
The choice of casing for titles should be about usability in online use, not just appearance at the top of a topic, because titles become navigation aids during online use. We feed users lists of titles in TOCs, in bulleted lists of title links inside content, and in lists of related topics at the bottom of a topic. Poor user has to digest these blocks of words to decide where to go next.
But in reality, the choice of casing for titles is often a non-choice. “It’s the way we’ve always done it”. Or the more considered response, “We don’t like title casing either but we don’t have the resources to switch existing content over so we have to keep using it”. And now, with the advent of content reuse, “Our topics are now going to be reused in that older book so we have to switch over to title casing to match their style.”
In multiple-thousand-topic docsets, the latter two arguments truly are compelling; you likely don’t have the resources, and you likely will have inconsistencies if you blend the styles. But why not a longer term approach: “From now on, 1) all new topics will have sentence casing (new), 2) when we update existing topics we’ll switch it to sentence casing (incremental), and 3) when we have free time, or folks have a few spare hours, we’ll update some more titles to sentence casing.”
Don’t think you can script the change, though; you can’t because there are more exceptions to case in software docs than you’d realize. You’d go blind reading them all to find the mistakes, and likely also have to hire a new editor.
In the short term, users might notice the mixture of casing, but they also may not. In the visual mayhem of title casing in blocks of links, they already have to slow down to parse each line. They aren’t likely to notice mismatch too much. Over time, though, you will have optimized these navigation aids for them.
I leave you with an example comparison: A list of title links much like you’d find at the bottom of any webpage, complete with underline, blue color, and teensy font like you’re used to. One is set in title casing, the other in sentence casing. Both are intentionally dense to the eye, but if you had to pick one, which would you rather? Happy digesting!
|Title Casing||Sentence casing..|
Security concerns: Unrestricted database access
Integrated Login and the login_mode Database Option
Security concerns: Unrestricted database access
Integrated login and the login_mode database option