This is the first article in the Use of Language series. It is worth reading them in sequence:
1) Chrome Browser: A Novel Approach to Language
2) SQL Response: Choosing Our Words Carefully
3) SQL Response: Does Everything Need a Name?
As a Technical Author, one of the most important tasks that you face is to make the language of applications as obvious, intuitive and accessible as possible. Google's approach to language attempts to do this AND to reflect its overall ethos - that it's homely and easy and accessible to all. Brian is pondering whether this is a general trend, and how he can apply it.
I’ve recently downloaded Google's new Chrome web browser, and after playing with it for half an hour, I stumble across the Options dialog box:
As a technical author, I'm interested in Google's approach to naming the various tabs in this dialog box: "Basics", "Minor Tweaks", and "Under the Hood". My first response is that this all seems rather colloquial for a piece of software.
The expression "Under the Hood" in particular is a shock; it challenges my many working assumptions as an application documentation specialist. For one thing, it isn't proper "technical language", and for another it's an idiom that is US-centric. Here in the UK, cars don't have "hoods"; they have "bonnets".
Is it even a metaphor that all users of Google Chrome would understand? IT-literate types understand that "under the hood" refers to settings that may be more complex, wide-ranging in scope, or fundamental to the way an application operates… but would my father, for example, get the reference?
“
As an application that
(they're hoping) will
be used by billions
of people, it makes
sense to use normal,
everyday language.
”
Looking more closely at what the Options dialog box contains in Google Chrome, I begin to understand a little more why the tab names aren't very descriptive. There is little connection between the various options within each tab. The "Under the Hood" tab contains settings for cookies, blocked popups, proxy server, downloaded files, and whether to send usage information back to Google. It's a mish-mash of stuff with no obvious common theme. The "Minor Tweaks" tab contains a similarly unconnected set of options for passwords, fonts, and save folders.
Lots of applications have an Options dialog; most of our applications at Red-Gate can be tweaked in numerous ways, some of them "basic", several that are essentially cosmetic or "minor" and some that are "under the hood". I think Google have tried to organise options by some sort of scale of "techiness" - even though there aren’t really any connections between those options. But the language makes it seem all rather vague and friendly and folksy. It seems to be almost admitting that there isn't much obvious difference between the tabs - just some stuff here, some stuff there, more stuff elsewhere.
My more considered reaction to the naming style in Google Chrome, once I've questioned my own accumulated prejudices as someone used to following rules and conventions of formal language, is that I quite like it. As an application that (they're hoping) will be used by billions of people, it makes sense to use normal, everyday language.
The Google Toolbar Options dialog does something similar:
"Features", "Buttons" and "More". "More" is hardly a descriptive term, but from a user's point of view, it makes sense to me. It tells me that there is "more" stuff in a third tab that I didn't find in the first two. That "more stuff" is probably more complicated, and less basic than what's on the first tab.
So maybe Google are onto something. The names that the various parts and functions in a piece of software are given matter a huge amount. When names are intuitive and obvious, we don't notice them; but when they are obtuse, difficult, ambiguous, or baffling, they confuse us, slow us down and can even stop us in our tracks altogether. Like a good referee in a soccer match, or background music in a film, names in an application should barely register in the mind.
Clash of the write'uns
I sent a picture of the Google Chrome Options dialog to the rest of the technical authors at Red Gate to see what their take was on this approach to naming. It prompted an interesting debate.
One of the authors was far from impressed:
That’s an almost painfully posed attempt at nonchalance and cool. Potentially also quite disconcerting for users familiar with established terminology.
Another author philosophized:
I sort of really like the idea of being able to do this - getting away from formality just for the sake of formality … but colloquialism and humour unfortunately usually have to be avoided for good reason: they don't necessarily mean the same thing to everyone…
What a shame! Or have I fallen into the trap of sticking with a nice safe set of rules without questioning deeply enough?
I responded:
I think there is a balance to be struck between precise, unambiguous, consistent language, and projecting an image of your company as progressive, accessible and friendly. It depends primarily on your target audience.
The prevalence of web based software (like Flickr, Facebook etc) is gradually altering people's expectations of how they interact with software, and how that software communicates to them. So it's not a war between stuffy tech authors and trendy web designers, but it's more like a gradual evolution of everything.
I think that this debate has only just got going. Here at Red Gate towers, we're very keen to be seen as an accessible, open company who produce tools that really are dead simple to use. But the people who are responsible for the names of everything in all our tools are technical authors; and I think it wouldn't be too harsh to say that technical authors are by and large people who prefer following well established sets of rules and conventions to trailblazing new ideas and approaches.
Then again, if there is an evolution in the way software is being used, then perhaps we would be wise to consider our approach to these issues as we move forward. As a matter of fact, my time spent playing with Chrome has led me to take a closer look at the language we’re using in our soon-to-be-release SQL Response product.