Writing User Interface That Your End User Understands

Writing For Users Of All Languages When Developing Your Software                                                                                                

This is written to help software developers why it is important to create user interface that is understandable, consistent, easily translated and repeatable.  Usability is vital! The user of your product must understand the commands, words and phrases within your software. Phrases like “holder info file processor ship to” may seem understandable to the programmer, but the user will have a difficult time knowing what the content is about.

Your user interface (UI) needs to be written for the user. Who are your users: are they tech savvy, engineers, laymen, or students? Do they have specific programming knowledge? Are they Mr. /Ms. Average Joe, whose comprehension is in simply written statements, without jargon, acronyms and multi-meaning terms? Example: Fill, Load, Touch, Mouse, Screen….

Who is using your product?

What will they be doing with it?

What do they need to understand?

What is their reading comprehension level?

Are they Non-English speakers?

Writing User Interface That Your End User Understands

 Most programmers write for programming; it is not understood by the end user and often lost in translation. Process to developing good content: 

1.      Software developer writes code

2.      Technical writer collaborates with developer and rewrites the UI for the end user.  

The user interface should be written by a technical writer. Some companies in the interest of time and budgetary restraints forego the technical writer and the programmer writes both the code and user interface. This actually creates delays in translation and confusion amongst all users. The written code needs to be translated to Plain English by a technical writer and then translated for non-English speaking users. To do this efficiently and well style guides need to be created and Plain English rules need to be established. Eliminating the technical writer can often create confusing instructions and commands resulting in hard to use devices and software. Add the dimension of other languages to this and you now have communication issues in multiple languages.

I highly recommend investing in creating good user interface at the beginning. You will save money 

I highly recommend investing in creating good user interface at the beginning. You will save money and time in the long run. Most importantly, your product information will be understood, used correctly and enjoyed.

As everyone knows, if you cannot understand commands and instructions you become frustrated. Your image will suffer, your sales will suffer and your fantastic product will not be utilized by the masses.

From OpenOffice.org User Interface Text Style Guide, Elizabeth Matthis author:

“Mark” Versus “Select”

“Select” is used to refer to the selection of objects/items, for example, paragraphs or characters which are then deleted, moved, copied, given a new font, etc. It is also used when selecting options from list/combo box drop-down lists and for radio buttons.

To discuss the use of check boxes, use the verbs “mark” and “unmark” or the adjectives “marked” and “unmarked”. Writing “mark” is also in the interest of using internationally accepted English, because it side-steps the usage of “tick” versus “check”. “Tick” is unacceptable in US English, whereas “check” is sometimes considered incorrect in UK English, where “tick” is more common. In the past, other words like “select”, “check”, and “activate” were used inconsistently alongside “mark”. Our goal is to avoid using different words to refer to the same function.

(http://www.openoffice.org/specs/collaterals/guides/text-style-guide.html#Localization)

Use existing terminology. This becomes an issue when new developers come on board and do not use established terms.

Create Glossaries and Style guides. These steps  will help the technical writers and translators maintain consistent messages using  established styles and terminology.

Once you decide what terms to use, is the statement clear?

Is the term used for multiple functions?

Creating UI In English While Keeping Other Languages In Mind.

Use Variables and keep Variables consistent; do not create new Variables when there are current ones you can use.

Do not leave text phrases open-ended.

Do not separate a command into separate resource strings.

Translators are not developers; they do not always recognize Variables and may think they are typos. Your Variables must be consistent and noted in your style guide. At times, it is difficult for a translator to recognize Variables… where they start and end, what symbol is part of the Variable -- remember your translators are not developers or native to the English language.

Do not end sentences in prepositions. They must be accompanied by a noun, for example:

 

Send file to (incorrect)        Send file (Correct)

Folder                                  to folder

Recipient                             to recipient

Symbols:

If you feel you must use symbols, make sure they are recognized internationally. A translator may be able to recognize commonly used symbols like # in American English, but it is hard to know the context.  It is best to use words when you write.

Space:

Know your spacing limitations when writing UI . Many languages are longer than English, some as much as three times as long. When you are writing your string, know your spacing limitations and the adjustments that will need to be made for other languages.

Spacing:

Do not add additional space before or after text. For example, using a carriage return instead of automatic formatting creates a separation in your sentence.  It will cause errors in the translator’database, making it difficult to understand and translate your text. The formatting issues will create delays in translation, if not errors, due to not understanding the original meaning.

Dates/Time

Do not hardcode dates/times/measurements. Allow the option for your user to choose his/her regional choices. 

                                                                                                                                                  

The Following is from Microsoft Windows User Interface Text:

 Globalization and localization

Globalization means to create documents or products that are usable in any country, region, or culture. Localization means to adapt documents or products for use in a locale other than the country/region of origin. Consider globalization and localization when writing UI text. Your program may be translated into other languages and used in cultures very different from your own.

·         For controls with variable contents (such as list views and tree views), choose a width appropriate for the longest valid data.

·         Include space enough in the UI surface for an additional 30 percent (up to 200 percent for shorter text) for any text (but not numbers) that will be localized. Translation from one language to another often changes line length of text.

·         Don't compose strings from substrings at run time. Instead, use complete sentences so that there is no ambiguity for the translator.

·         Don't use a subordinate control, the values it contains, or its units label to create a sentence or phrase. Such a design is not localizable because sentence structure varies with language.

Incorrect: 

Correct:

In the incorrect example, the text box is placed inside the check box label.

·         Don't make only part of a sentence a link, because when translated, that text might not remain together. Link text should therefore form a complete sentence by itself.

o    Exception: Glossary links can be inserted inline, as part of a sentence.

For more information, see the Go Global Developer Center. http://msdn.microsoft.com/en-us/library/windows/desktop/dn742478%28v=vs.85%29.aspx

 As you develop your software, keep in mind your end users will likely be non-English speakers in other regions around the world. Ninety-five  percent of consumers are located outside of the United States Writing with them in mind will create content ready to be sold around the world.

Reference:

http://www.openoffice.org/specs/collaterals/guides/text-style-guide.html#Localization
Elizabeth Matthis Consulting, http://www.emc-services.de   

http://msdn.microsoft.com/en-us/library/windows/desktop/dn742478%28v=vs.85%29.aspx

Learn more about All Clear Translations.

Visit our website at www.allcleartranslations

Reach out to our President, Linda Richardson linda@allcleartranslations.com to discuss your language challenges and how we can help.

Call us at 866-489-9109

More about the author and All Clear Translations:

Linda Richardson is president of All Clear Translations. All Clear Translations is located in Western Pennsylvania and was established in 2010. Their main clients are manufacturers, software developers and marketing agencies. All Clear Translations assists with translations, telephone interpreting and voice-overs in many languages.