Style notes

From rejetto wiki
Jump to navigation Jump to search

In general terms, we follow Microsoft guidelines for terminology, as detailed in:
Microsoft® Computer Dictionary, Fifth Edition (Microsoft Press, 05/01/2002).
This establishes basic meanings, spellings and wordforms.

Unfortunately, this has not been updated for more than five years although MicroSoft (MS) terminology changes almost as often as they issue software patches.

More recent glossaries can be accessed through

Some exceptions are noted below:

We use ie. (NOT i.e.) for "that is", and eg. (NOT e.g.) "for example". This violates Microsoft documentation standards, but we like to live dangerously.

We also use etc. as an abbreviation for "et cetera" (it means "and so on"). Curiously, this also violates MS standards, but you'll find many examples of this in their software and documentation.

Like MS, we use both "System tray" and "Notification area" as the name of the right-hand section of the Taskbar that normally includes the clock. (If anyone's actually interested, there's a whole debate about it [here].)

For Your Amusement

are always controversial. But all writers need these things to cling to.
The following rules make a good litmus test. In general, if you can understand how these sentences break the very rules they promote, you can consider yourself to have mastered English.
The point of many of these sentences is very hard to understand for those who use English as their second language, but mostly obvious to educated natives.

Writer's Rules, OK ?

These rules are normally attributed to William Safire, "the most widely read writer on the English language". In reality, these "Fumble Rules" have a long history and there are many, many variants of these lists. Some may have descended from the "xeroxlore" that circulated throughout campuses and offices in the 1970s.

01. Remember to never split an infinitive.

02. The passive voice should never be used.

03. Do not put statements in the negative form. 

04. Verbs have to agree with their subjects. 

05. Proofread carefully to see if you words out.

06. If you reread your work, you can find on rereading a great deal of repetition can be avoided by rereading and editing.

07. A writer must not shift your point of view.

08. And don't start a sentence with a conjunction. 

09. Remember, too, a preposition is a terrible word to end a sentence with.)

10. Don't overuse exclamation marks !!

11. Place pronouns as close as possible, especially in long sentences, as of 10 or more words, to their antecedents.

12. Writing carefully, dangling participles must be avoided.

13. If any word is improper at the end of a sentence, a linking verb is.

14. Take the bull by the hand and avoid mixing metaphors. 

15. Avoid trendy locutions that sound flaky.

16. Everyone should be careful to use a singular pronoun with singular nouns in their writing.

17. Always pick on the correct idiom.

18.The adverb always follows the verb.

19. Last but not least, avoid clichés like the plague; seek viable alternatives.


Unfortunately, life and writing are seldom simple, and despite its obvious brilliance, (7,12,17 in particular) Safire's list has attracted some criticism. 
4 is particularly controversial, 5 & 6 might be combined, 9 could be "improved" by putting the period outside the bracket, etc.

The following list may also be useful.

Never use a preposition to end a sentence with.

Avoid anoying alliteration.

Don't verb nouns.

Don't use no double negatives.

Make each pronoun agree with their antecedent.

When dangling, watch your participles.

Don't use commas, which aren't necessary.

Verbs has to agree with their subjects.

About those sentence fragments.

Try to not ever split infinitives.

Its important to use apostrophe's correctly.

Always read what you have written to see if you've any words out.

Correct spelling is esential.

Proofread you writing.

Between you and I, case is important.

Verbs has to agree with their antecedents.

George Orwell

George Orwell (1946) reckoned that writers "need rules to rely on when instinct fails". He proposed the following rules. (Slightly modernized here.)

1. Never use a long word where a short one will do.
2. If you can cut a word out, always cut it out.
3. Never use the passive where you can use the active.
4. Never use a foreign phrase or jargon if there is an everyday English equivalent.
5. Never use a metaphor that has become a cliché from overuse.
6. Break any rule rather than say anything outright barbarous.

Mark Twain

Mark Twain wrote (in a letter):
"I notice you use plain simple, language, short words, and brief sentences. That is the way to write English."

Dialog boxes & property sheets
Dialog boxes contain command buttons and various kinds of options through which users can carry out a particular command or task. For example, in the Save As dialog box, the user must indicate in which folder and under what name the document should be saved.
Property sheet
Property sheets display information ("properties") about an object in the interface. For example, the Taskbar property sheet shows information such as the size of the Start menu icons and whether the clock is shown on the taskbar.

Property sheets have command buttons and, when properties can be edited, they can contain options, as dialog boxes do. Both dialog boxes and property sheets can have tabbed pages that group similar sets of options or properties.

Dialog box
In most documentation, treat elements in dialog boxes and property sheets the same way. Avoid differentiating between property sheets and dialog boxes in end-user documentation. In general, avoid using the term dialog box or property sheet if you can and refer to property sheets as dialog boxes if you can't avoid a descriptor.
In programming and other technical documentation, buttons and other dialog box elements are called controls, especially in discussions about creating them. Do not use that term in end-user documentation.

Dialog box syntax

These terms are most commonly used for user actions in dialog boxes:

Use for commands, command buttons, option buttons, and options in a list.
Select and clear:
Use for checkboxes.
Type or select:
Use to refer to an item (as in a list box) that the user can either type or select in the accompanying text box. You can use enter instead if there's no possibility of confusion.
Choose and select: Use these terms only when documenting generic procedures, not mouse procedures. Use choose for commands and select for options.

Except for the identifiers box, list, checkbox, and tab, the generic name of an item within a dialog box (button, option, and so on) should not follow the item's label, especially within procedures. Checkbox in particular helps differentiate this item from other option boxes.
Use bold for dialog box titles, labels, and options.
The following example shows typical procedure wording for dialog box elements.

To view bookmarks:
1. On the Tools menu, click Options, and then click the View tab.
2. Select the Bookmarks checkbox.

Dialog box elements

In most documentation, especially for end users, do not differentiate between elements such as dropdown combo boxes, list boxes, and so on. Do use the term check box, however.
Use the correct label (for example, Save as type) with the term box or list if necessary to locate where the user should be and then direct the user to click, select, or take other action.

Is documentation important?
Anyone who doubts the value of good, consistent, documentation might consider the following report taken from the BBC web site (22 September 2005).
Computer terms 'confuse workers'
Most office workers find computer jargon as difficult to understand as a foreign language, a survey suggests. Three quarters of workers waste more than an hour a week deciphering what a technical term means, the poll found.
Terms such as jpeg, javascript and cookies are among the problem words highlighted by firm Computer People. The recruiter, which questioned 1,500 workers, says effective technology professionals "understand the need to tailor their levels of jargon".
Most office workers admit an over-reliance on IT support staff.
Three quarters of workers waste more than an hour a week deciphering what a technical term means, the poll found.
The findings revealed that younger workers were just as likely to make a mistake over computer language. It also points to problems which regularly leave workers baffled.
Just under two thirds had sent e-mails with large attachments which had blocked clients' systems.
Jargon Problems

An over-reliance on IT staff was admitted by 67% of office workers.
Logging off instead of re-starting is a mistake made by 14% those surveyed.
Some 44% of office workers feel it is their duty to improve their IT knowledge.
More than one in four people are not sure what a firewall does, tempting them to turn it off.
Turning off firewall - software to protect computers against hackers - is the worst course of action to take, according to IT experts.
And a quarter of those surveyed had to ask for technical help to download information.
Mr Fletcher, managing director of Computer People, said: "We're finding that many clients are increasingly requiring professionals who have concise communication expertise as they recognise this improves company productivity in the long run."