5 Answers
5

In English, both in computers and under the blue ceiling, title-style capitalization (capitalizing first letters of nearly all words) is for titles, and sentence-style capitalization (capitalize only the first letter for the first word) is for sentences. Titles generally include headers for your documents, pages, and sections therein and labels for controls. They are often sentence fragments lacking either the subject or predicate. Sentences are “regular” content, each generally including a subject and predicate, although sentences in the command sense often have “you” as the implied subject.

There are some gray zones. Style guides provide specific guidelines on when to use each. For example Apple recommends title-style for menu names, menu items, buttons, and any label that isn’t a full sentence. Apple recommends sentence-style for messages, check boxes, and radio buttons, even if they aren’t sentences.

However, style guides don't all agree with each other and sometimes they change. For example, the Windows UX Guidelines used to recommend title-style capitalization for buttons and menu items, but now recommends sentence-style capitalization. Title-style capitalization is only recommended for tabs, window titles, pages, programs, folders, and other “major components.”

In these gray areas, capitalization style is mostly a matter, of, uh, style. Sentence-style capitalization gives your app a more conversational tone, as if the user is interacting with an agent rather than a tool, which may or may not be a good idea in your case. I suspect title-style capitalization can make it easier to scan for key words in labels, but that’s just a hunch.

I'm not sure that using title case (capitalizing the first letter in each word) can be described as correct or incorrect. FWIW, I have personally moved away from using title case in, say, checkboxes, radios, and list items. I now limit their use to one sentence, e.g. dialog title and button labels, e.g "Save File".

A group of professionals will always disagree on some detail or other. Nothing illustrates making a mountain out of a molehill faster than professionals trying to decide how to capitalise, punctuate, spell, write, or organise text.

If you establish a committee to generate consensus, they still won't agree on all the details. Someone will have to overrule and impose a decision, or the group can vote. Either way, some people will feel they lost.

It's labour intensive to write, maintain, and publish a style guide. Your style guide won't be up to date for long,

People who don't like the decisions in the style guide will find excuses not to follow it. ("Oh, I couldn't find it" or "Oh, it's out of date" or some other passive-aggresive baloney.) When some people don't follow the style guide, you don't really have a style guide.

When the style guide is produced externally, you can say: "I don't like all of it all either, but we'll just have to hold your noses and follow this style guide completely." It's easier, cheaper, and more effective than writing and maintaining your own style guide.

I realise the above sounds cynical. There is a way to get an internal style guide written that has buy-in from those involved: a barn-raising. This involves your team sitting together, away from their usual desks, but with their laptops. Try once a week in a meeting room. Let people choose a topic to write from a list that the team has prioritised into high, medium, and low. Set a timer as you write. Writing time is quiet time. Each person writes a different topic, then the group reviews the topics together. After the timer goes off, review a topic if its writer feels it's ready for review. After the timer goes off, it's OK for one person to consult or poll others about their topic and then take it for another iteration before they ask the team to review it. Start the timer with 10 minutes; you can increase the writing time, as needed. Find a way to quickly share the topic that's being reviewed: via email, your LAN, a projector, etc.