Projects/Usability/HIG/Wording: Difference between revisions

From KDE TechBase
< Projects‎ | Usability‎ | HIG
No edit summary
Line 5: Line 5:


== Guidelines ==
== Guidelines ==
* KDE personas are not tech savvy; so your app should use an easy to understand terminology.  
* Use a terminology that is familiar and easy to understand for the target audience (i.e. Persona) of your application.  
* Avoid abbreviations, acronyms, and tech-babble.
* Avoid abbreviations, acronyms, and tech-babble.
* Use a tone that’s informal and friendly, but not too familiar.
* Use a tone that’s informal and friendly, but not too informal.
* Keep information short and consistent; avoid redundancy or unnecessary words.  
* Keep information short and consistent; avoid redundancy or unnecessary words.  
* Don't abuse [[Projects/Usability/HIG/Capitalization|capitalization]] because it draws people’s attention.
* Don't abuse [[Projects/Usability/HIG/Capitalization|capitalization]] because it draws people’s attention.
* In respect to chronological information consider that your app is potentially used for decades; don't use fix dates like ''this year''.
* In respect to chronological information consider that your app is potentially used for decades; don't use fix dates like ''this year''.
* Follow system-wide conventions for basic functions to keep wording consistent.
* Follow system-wide conventions for basic functions to keep wording consistent.
== Examples ==
== Examples ==
* Delete, Move to Trash, Remove and Uninstall
* Delete, Move to Trash, Remove and Uninstall

Revision as of 09:41, 30 December 2013


Purpose

Every word displayed in an application is part of a conversation with users. This conversation is an opportunity to provide clarity and to help people feel comfortable in the system.

Guidelines

  • Use a terminology that is familiar and easy to understand for the target audience (i.e. Persona) of your application.
  • Avoid abbreviations, acronyms, and tech-babble.
  • Use a tone that’s informal and friendly, but not too informal.
  • Keep information short and consistent; avoid redundancy or unnecessary words.
  • Don't abuse capitalization because it draws people’s attention.
  • In respect to chronological information consider that your app is potentially used for decades; don't use fix dates like this year.
  • Follow system-wide conventions for basic functions to keep wording consistent.

Examples

  • Delete, Move to Trash, Remove and Uninstall
    • When a file or object is completely removed from the system, use Delete.
    • When a file or object can be recovered, use Move to Trash for files and Remove for list objects etc.
    • When a file or object can be removed and was originally installed, use Uninstall.
  • Settings, Options and Properties
    • Use Settings for a configuration dialog which allows you to set specific properties or functionality. This usually applies to application configuration tools. For example, Konqueror Settings.
    • Use Options for a configuration dialog which provide. This usually applies to object configuration tools.
    • Use Properties for a list of metadata or details that are associated with a particular object which cannot be edited or interacted with in any way. For example, file "properties" dialog in Dolphin.