Style and Us

Stylus is about style and us, writers. Stylus brings up for discussion matters related to the language we use as technical communicators. Style is not related to rules of grammar that are at the core of language. Rather, style is built on top of the core of grammar and does not conflict with the grammar of a language.

In other words, what is ungrammatical cannot be OK because of something called style. However, what is grammatically correct may not be OK for reasons of style. We delve into this a little before discussing the relation between technology and terminology: that is, tools and terms.

Style is not about typographical conventions, such as using bullets and headers and footers - although historically, style may have such connotations, owing to the origins of the mother of all style manuals - the Chicago Manual of Style.

Tools and terms

Technical language as a subset of any language (technical English, technical German, and so on) involves naming of tools and things associated with technology in general or a particular technology domain one is dealing with.

Let us be clear that the rules of language apply as rigorously to technical writing as to any other form of writing. As Noam Chomsky (Syntactic Structures, 1957 and a dozen other publications) reminds us, the possible grammatically correct sentences in any given language are limitless. The rules of language are limited but the possible expressions that the rules can generate are infinite (Chomsky called this set of generative rules 'generative syntax' for sometime).

That said, what distinguishes technical writing from other forms of writing are not the rules but the choice of rules, a subset of rules used in technical language. We choose not to use some structures and forms that lead to ambiguity and multiple interpretations.

In other words, as a community, we perform self-censorship, to achieve utmost clarity. We look at these in another article, but a quick example should help for now:

You must have logged in as administrator.

This is a grammatical sentence. The 'must' can be interpreted as an indication of probability or as an imperative. To disambiguate, we use one of the following forms, although the above is grammatically correct:

You must log in as administrator.
You should have administrator privileges.

This is a choice or limitation dictated by style. Thus, style governs and limits the infinite choices that grammatical rules provide for language production.

Notice also that use of bullets and table formats are typographical conventions (which were, for the first time in the history of publishing, laid down in the Chicago Manual of Style (CMS) for typesetters: in later years, over more than a century, the CMS grew to encompass a range of publishing and language guidelines - unfortunately, style is often stuck in the typographical quagmire.)

In this article, we look at terminology, specifically technical English.
Take for instance the terms 'telecom' and 'telecommunication' which at first glance seem to be interchangeable: telecom refers to the industry and telecommunication to the technology. When we point this out to an engineer, typically the response is: 'whatever'.

Engineers are happy as long as a firewall is not misspelt firewell and the kind of nitty-gritty over which writers sweat is for them 'cosmetic'.

Terms and us, and users

As professional communicators we have a primary responsibility towards the user to convey the meaning accurately and also, in accordance with the terminology that is consistent with usage in the domain. It is not enough to use it consistently within the organization.

Take for instance, in an organization, the term tablet is used to refer to what is otherwise called a handheld device: knowledge of English is not sufficient because in plain English, there is nothing wrong with 'table'. Knowledge of your product and use of terms in the organization is of no help either.

Note also that being at the bottom of the linguistic food chain, we need to create terms and expand the language for others to consume - not always, but when required. Thus, in your organization, it is your role to ensure that the terminology used is in sync with the outside world, in order that the users do not encounter something strange in your documents, different from what they are used to.

In other words, we don't want this situation to occur:

"Ultimate Technical Support. Good morning, how can I help you?"
"My PC is not working, I need a replacement"
"Hmm, are you sure you turned on power?"
"No, I cook on gas."
"You are talking about the pressure cooker?"
"Yeah"
"OK, let me transfer you to the girl who handles our prestigious customers"

The moral of the story is that PC is a personal computer in the IT domain, but it could connote a pressure cooker in the consumer's mind: it is our responsibility to make sure that our communication (in documentation, support, and such) syncs up with the customer's weltanschauung.

This is a cooked up example: If one day you see it on the Internet as a 'true story', don't blame me for propagating an urban legend.

To recapitulate the story so far:

• Technical writing is subject to the rules of grammar as much as any writing.
• Technical writing uses a subset of language rules: mainly avoiding structures that lead to ambiguity.
• The use of layout and formatting differently is not a language issue, and let us not mistake that for style.
• Style governs and limits the infinite choices provided by generative-syntactic rules.
• In translating technology terms, we need to find a style that accommodates the specific terminology used in the organization and yet confirms to the broad framework of the domain.

This task involves:

• knowing the terms used in the technology domain (some resources are provided further down)
• negotiating a common ground with the geeks in the organization
  providing adequate guidance on terms used in a unique way in your documents (organization style)
• not bringing in one's own mistaken or confused concepts into play (this is individual style; this and the above will be dealt with in a later piece)

A few resources on the web

www.Whatis.Com is an excellent resource for technology concepts. Moreover, you can register with whatis for an email service that delivers a technical term with definition and description, every day. Let us not forget the good old dictionary, say www.m-w.com

It is not that the traditional dictionaries do not carry technical terms: indeed, there may be occasions when you would not use a term that is not listed in a 'classic' dictionary, although the term enjoys wide currency in the high tech domains. For instance, when writing an executive summary of a product or service.

Negotiating common ground on terminology

There is a strategic, interpersonal angle to the issue of terminology: we need to convince the engineers and others who review the documentation that the terms used are valid in the domain and hence need to be so. We need to persuade UI designers to change the labels accordingly.

Let us face it, we don't know the user most often: product managers, marketing and sales personnel do. Not even the engineer knows a great deal about what the users need or do with a product. In this context, it is important to be aware of the concepts and terms commonly used in the domain, and work with product and marketing people closely to prepare a glossary that acts as a definitive resource for UI designers, the documentation team, and all stakeholders in the product's presentation and user experience.

postscript: Pillay's play

There was this German doctoral student at my alma mater (the U of Hyderabad): he was in Hyderabad for several years and picked up enough 'Hindi' as spoken in the Deccan.

One time we went to have his mo-bike get a fix, and the mechanic said, in Hindi:
'There is Pillay in that box' [pointing at something]
[German guy to me] 'What is he saying?'
'I don't know' [I said to the German guy. I heard 'Pillay' as 'play' and that to me was a technical English term: and, until then, I didn't know the technical meaning of 'play', which, as I learnt later, meant that something that should grip got loose and is playing around instead of running on a defined, firm course.]

[German guy to me] 'You know Hindi, don't you?'
'Yeah, but I have no clue what "play" is'
[German guy to me] 'Oh, he says there is play?'
[Me to German] 'Yeah, you are the zen-mobike* guy, you should know what's play'
[German guy to me] 'I know motor cycles and maintenance, but he said 'Pillay'
… Then he explained 'play' as above: he may be wrong. Or, I may have got it wrong.

[me to German]: Well, 'play' is pronounced as Pillay sometimes: it is an Indianism.

And thus ended a very informative session, where the mechanic learnt that play and Pillay are different animals, I learnt the games bikes pillay, and the German learnt that he did not have a grip over Hindi as much as he thought he did.

* The author of Zen and Motor Cycle Maintenance, Robert Persig wrote another book called Leela; I only mention it because Leela is roughly translated as 'play' in some dictionaries.

Inviting contributions

This column is meant for sharing issues related to style and us (writers). It will be a vastly better column with contributions from folks, and I earnestly request, nay, solicit the same.

STC India | Home | Contact Us

Copyright © 2006 India Chapter STC. All rights reserved.