Tools

Namespaces

Variants

Views

Actions

Search

Contents

Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries. Thanks for all your past and future contributions.

Language and terminology

(New page: Language is a big part of an application. First, you need to think of language from localization point of view. The user should have the opportunity to use the application on her/his nativ...)

Language is a big part of an application. First, you need to think of language from localization point of view. The user should have the opportunity to use the application on her/his native language. Second, you need to use language and terms that the user knows and expects to be used. There are a lot of established terms in the world of handsets. Although change is good, some things are better left untouched. The user is more likely to be frustrated than pleased if s/he can’t find a feature by s/he is looking for by the term s/he is used to.

In addition you have to avoid technical terms and keep the terminology consistent throughout the application. Youn can’t say exit here and out there and mean the same thing. It confuses the user and stresses her/his memory.

+

[[Category:Usability]][[Category:Quality]]

+

+

Language is a big part of an application and the correct usage of it goes a long way in ensuring a high usability index and in turn end user satisfaction. While designing applications careful thought needs to be given to the kind of language/words/tone etc needs to be given due consideration. If the budget of the project allows for hiring a full time technical writer that would be the best thing to do as s/he would bring in expertise in this area. It would be the job of the technical writer to validate all the text/content being diplayed to the user as part of the application whether on the view, command options, information dialog etc, through the online/offline/context sensitive help. The technical writer needs to understand the target user’s language to be able to word the content and information in a way which makes sense to them.

+

+

Some key points to consider while designing the language usage aspect of the application :-

+

+

+

<b>* Think of language from localization point of view.</b>

+

+

The user should have the opportunity to use the application on her/his native language. This is important because sometimes the target audience might not be familiar with the default language you might be using for development i.e. English. For instance in countries like China, Russia etc it would make lot of sense to actually localize the content so that it can be displayed in Chinese, Russian respectively. In these cases we end up forcing the user to learn English to understand the information/content being displayed without which they might find it difficult to use the application. This could severly limit the reach of the application, something which the marketing team would be very vary of.

+

+

Localization and internationalization can be achieved successfully only after a detailed study of the culture and linguistic patterns of the target audience. For more details on language localization, see [http://en.wikipedia.org/wiki/Language_localization Language Localization]

+

+

Comparision of localization v/s no localization after language change

+

+

<table>

+

<tr>

+

<td align="left">

+

''''''Change of language from English to Nederlands '''<br>

+

[[File:Lang Change.jpg]]

+

</td>

+

<td align="left">

+

'''Current language'''<br>

+

[[File:Current Lang.jpg]]

+

</td>

+

</tr>

+

</table>

+

+

<table>

+

<tr>

+

<td align="left">

+

'''No localization'''<br>

+

[[File:Screenshot0008.jpg]]

+

</td>

+

<td align="left">

+

'''Localization handled'''<br>

+

[[File:Screenshot0009.jpg]]

+

</td>

+

</tr>

+

</table>

+

+

+

Localization resources for :-

+

+

==Symbian C++==

+

[[How to define localization messages]]

+

+

[[Symbian C++ Localization Articles]]

+

+

==Java ME==

+

[[Java Localization Articles]]

+

+

==Python==

+

[[Localization Example for PySymbian]]

+

+

+

<b>* Use language and terms that the user knows and expects to be used</b>

+

+

<b>* Avoid using cryptic language full of technical jargons</b>

+

+

There are a lot of established terms in the world of handsets. Although change is good, some things are better left untouched. The user is more likely to be frustrated than pleased if s/he can’t find a feature by s/he is looking for by the term s/he is used to.

+

+

Surprise is an absolute no-no when designing the usability of the application and this applies even to the usage of language. The average user is more often then not conversant with the day to day mobile terms and those should be used instead of inventing your own terminologies which might only succeed in confusing the user.

+

+

<table>

+

<tr>

+

<td align="left">

+

'''Example of wrong terminology used'''<br>

+

[[File:Wrong text.JPG]]

+

</td>

+

<td align="left">

+

'''Example of correct terminology used'''<br>

+

[[File:Right command.jpg]]

+

</td>

+

</tr>

+

</table>

+

+

In addition you have to avoid technical terms, with which you might be very comfortable but the end user might not fathom what those really mean or connote.

+

+

<table>

+

<tr>

+

<td align="left">

+

'''Cryptic language used'''<br>

+

[[File:Cryptic.jpg]]

+

</td>

+

<td align="left">

+

'''Technical language used'''<br>

+

[[File:Too tech error.jpg]]

+

</td>

+

<td align="left">

+

'''Easy to understand language used'''<br>

+

[[File:Screenshot0073.jpg]]

+

</td>

+

</tr>

+

</table>

+

+

Keep the terminology consistent throughout the application. For instance you can’t say exit here and out there and mean the same thing. It confuses the user and stresses her/his memory.

+

+

<table>

+

<tr>

+

<td align="left">

+

'''Example of wrong command options'''<br>

+

[[File:Wrong command.JPG]]

+

</td>

+

<td align="left">

+

'''Example of right command options'''<br>

+

[[File:Right command.jpg]]

+

</td>

+

</tr>

+

</table>

By using terms that are familiar to the user you can support her/his learning process. It’s easier to learn how to use an application if the terminology relates to the users’ tasks and goals and stays consistent. Also, consistent terminology makes using of the application more effective. User’s memory is not loaded with unknown terms and things that need to be remembered. Being able to concentrate on ''doing'' things instead of trying to figure out where to ''find'' things increases the level of satisfaction.

By using terms that are familiar to the user you can support her/his learning process. It’s easier to learn how to use an application if the terminology relates to the users’ tasks and goals and stays consistent. Also, consistent terminology makes using of the application more effective. User’s memory is not loaded with unknown terms and things that need to be remembered. Being able to concentrate on ''doing'' things instead of trying to figure out where to ''find'' things increases the level of satisfaction.

+

+

<b>* Avoid using racial/ethnic/religious/sexual/violent connotations in the language</b>

+

+

It is an absolute no-no to use language which might have a racial/ethnic/sexual/religious bent to it. You don’t want to offend the sensibilities of the user in any ways what so ever. It is always advisable to keep the language formal and simple, so that there is no ambiguity and the reader is not able to derive his own conclusions from them. The wordings and tone should be neutral and congenial so to speak.

+

+

<b>* Treat the user with respect</b>

+

+

Always use wordings and tone which is respectful of the user. Using derogatory or harsh tone/wordings is a no go as far as the language of the application is concerned. Treat the user with respect and use soft meaning words and tone rather than an ove the board kind of usage. Provide the user with help and helpful content where ever possible so that they can make best use of the features of the application.

+

+

<table>

+

<tr>

+

<td align="left">

+

'''Wrong language used'''<br>

+

[[File:Wrong lang.jpg]]

+

</td>

+

<td align="left">

+

'''Rude language used'''<br>

+

[[File:Rude.jpg]]

+

</td>

+

</tr>

+

</table>

+

+

+

<table>

+

<tr>

+

<td align="left">

+

'''Cordial language used'''<br>

+

[[File:Cordial.jpg]]

+

</td>

+

<td align="left">

+

'''Helpful language used'''<br>

+

[[File:Helpful.jpg]]

+

</td>

+

</tr>

+

</table>

+

+

Usage of the correct language would certainly go a long way in ensuring that not only does the user understand the intent/content but is also satisfied with the overall information being displayed. The language usage tips should be applied to all the artefacts that are exposed to the customer, be it the command options, text on the view/dialog/error boxes etc, the help manual etc.

Latest revision as of 03:42, 9 May 2012

Article Metadata

Article

Created: SannaH
(31 Oct 2007)

Last edited: hamishwillee
(09 May 2012)

Language is a big part of an application and the correct usage of it goes a long way in ensuring a high usability index and in turn end user satisfaction. While designing applications careful thought needs to be given to the kind of language/words/tone etc needs to be given due consideration. If the budget of the project allows for hiring a full time technical writer that would be the best thing to do as s/he would bring in expertise in this area. It would be the job of the technical writer to validate all the text/content being diplayed to the user as part of the application whether on the view, command options, information dialog etc, through the online/offline/context sensitive help. The technical writer needs to understand the target user’s language to be able to word the content and information in a way which makes sense to them.

Some key points to consider while designing the language usage aspect of the application :-

* Think of language from localization point of view.

The user should have the opportunity to use the application on her/his native language. This is important because sometimes the target audience might not be familiar with the default language you might be using for development i.e. English. For instance in countries like China, Russia etc it would make lot of sense to actually localize the content so that it can be displayed in Chinese, Russian respectively. In these cases we end up forcing the user to learn English to understand the information/content being displayed without which they might find it difficult to use the application. This could severly limit the reach of the application, something which the marketing team would be very vary of.

Localization and internationalization can be achieved successfully only after a detailed study of the culture and linguistic patterns of the target audience. For more details on language localization, see Language Localization

There are a lot of established terms in the world of handsets. Although change is good, some things are better left untouched. The user is more likely to be frustrated than pleased if s/he can’t find a feature by s/he is looking for by the term s/he is used to.

Surprise is an absolute no-no when designing the usability of the application and this applies even to the usage of language. The average user is more often then not conversant with the day to day mobile terms and those should be used instead of inventing your own terminologies which might only succeed in confusing the user.

Example of wrong terminology used

Example of correct terminology used

In addition you have to avoid technical terms, with which you might be very comfortable but the end user might not fathom what those really mean or connote.

Cryptic language used

Technical language used

Easy to understand language used

Keep the terminology consistent throughout the application. For instance you can’t say exit here and out there and mean the same thing. It confuses the user and stresses her/his memory.

Example of wrong command options

Example of right command options

By using terms that are familiar to the user you can support her/his learning process. It’s easier to learn how to use an application if the terminology relates to the users’ tasks and goals and stays consistent. Also, consistent terminology makes using of the application more effective. User’s memory is not loaded with unknown terms and things that need to be remembered. Being able to concentrate on doing things instead of trying to figure out where to find things increases the level of satisfaction.

* Avoid using racial/ethnic/religious/sexual/violent connotations in the language

It is an absolute no-no to use language which might have a racial/ethnic/sexual/religious bent to it. You don’t want to offend the sensibilities of the user in any ways what so ever. It is always advisable to keep the language formal and simple, so that there is no ambiguity and the reader is not able to derive his own conclusions from them. The wordings and tone should be neutral and congenial so to speak.

* Treat the user with respect

Always use wordings and tone which is respectful of the user. Using derogatory or harsh tone/wordings is a no go as far as the language of the application is concerned. Treat the user with respect and use soft meaning words and tone rather than an ove the board kind of usage. Provide the user with help and helpful content where ever possible so that they can make best use of the features of the application.

Wrong language used

Rude language used

Cordial language used

Helpful language used

Usage of the correct language would certainly go a long way in ensuring that not only does the user understand the intent/content but is also satisfied with the overall information being displayed. The language usage tips should be applied to all the artefacts that are exposed to the customer, be it the command options, text on the view/dialog/error boxes etc, the help manual etc.