×
Namespaces

Variants
Actions
(Difference between revisions)

Error Messaging

From Nokia Developer Wiki
Jump to: navigation, search
jimgilmour1 (Talk | contribs)
m (minor spelling)
hamishwillee (Talk | contribs)
m (Text replace - "Category:Mobile Design" to "")
 
(8 intermediate revisions by 5 users not shown)
Line 1: Line 1:
[[Category:Mobile Design]][[Category:Usability]]
+
[[Category:Usability]]
===Introduction===
+
{{ArticleMetaData <!-- v1.2 -->
 +
|sourcecode= <!-- Link to example source code e.g. [[Media:The Code Example ZIP.zip]] -->
 +
|installfile= <!-- Link to installation file (e.g. [[Media:The Installation File.sis]]) -->
 +
|devices= <!-- Devices tested against - e.g. ''devices=Nokia 6131 NFC, Nokia C7-00'') -->
 +
|sdk= <!-- SDK(s) built and tested against (e.g. [http://linktosdkdownload/ Qt SDK 1.1.4]) -->
 +
|platform= <!-- Compatible platforms - e.g. Symbian^1 and later, Qt 4.6 and later -->
 +
|devicecompatability= <!-- Compatible devices e.g.: All* (must have internal GPS) -->
 +
|dependencies= <!-- Any other/external dependencies e.g.: Google Maps Api v1.0 -->
 +
|signing= <!-- Signing requirements - empty or one of: Self-Signed, DevCert, Manufacturer -->
 +
|capabilities= <!-- Capabilities required by the article/code example (e.g. Location, NetworkServices. -->
 +
|keywords= <!-- APIs, classes and methods (e.g. QSystemScreenSaver, QList, CBase -->
 +
|language= <!-- Language category code for non-English topics - e.g. Lang-Chinese -->
 +
|translated-by= <!-- [[User:XXXX]] -->
 +
|translated-from-title= <!-- Title only -->
 +
|translated-from-id= <!-- Id of translated revision -->
 +
|review-by= <!-- After re-review: [[User:username]] -->
 +
|review-timestamp= <!-- After re-review: YYYYMMDD -->
 +
|update-by= <!-- After significant update: [[User:username]]-->
 +
|update-timestamp= <!-- After significant update: YYYYMMDD -->
 +
|creationdate= 20091031
 +
|author= [[User:Aadhar14b]]
 +
}}
 +
==Introduction==
 
Error messages should give the user the information needed to solve the problem. In many situations, this means the underlying code needs to better differentiate error conditions.
 
Error messages should give the user the information needed to solve the problem. In many situations, this means the underlying code needs to better differentiate error conditions.
 +
{{Note|Original article published at [http://www.littlespringsdesign.com/blog/2007/Mar/design-pattern-error-messages/ Little Spring Design]  under [http://creativecommons.org/licenses/by/3.0/ Attibuttion 3.0]}}
  
===Design Guidelines===
+
==Design Guidelines==
<UL>
+
  <LI> Put error codes at the end of the message. This allows any support personnel to get the relevant information without costing the user is time to read it ... or risk having the code push some of the words off the bottom of the screen/window.
+
  <LI> Keep the message short.
+
<LI>    Give clues regarding what the user can do to resolve the situation.
+
<LI>    Be specific.
+
<LI>    Log the critical errors
+
<LI>Consider using a dialog box rather than a full screen, if your platform and device supports it.
+
  
<BR>[[Image:Network-error.jpg]] <BR>
+
* Put error codes at the end of the message. This allows any support personnel to get the relevant information without costing the user is time to read it ... or risk having the code push some of the words off the bottom of the screen/window.
<b>Example of Error Message</b><BR><BR>
+
* Keep the message short.
 +
* Give clues regarding what the user can do to resolve the situation.
 +
* Be specific.
 +
* Log the critical errors
 +
* Consider using a dialog box rather than a full screen, if your platform and device supports it.
 +
*: [[File:Network-error.jpg|frame|none|Example of Error Message]]
 +
* If possible, categorize errors into based on whether the user can fix the problem, the user needs to retry later, or an unfix-able error has occurred. Of course, many unfix-able errors should be fixed by the developer.
  
<LI>If possible, categorize errors into based on whether the user can fix the problem, the user needs to retry later, or an unfix-able error has occurred. Of course, many unfix-able errors should be fixed by the developer.
+
==Commands (softkeys, links, or buttons)==
</UL>
+
 
+
===Commands (softkeys, links, or buttons)===
+
 
Frequently, the best commands are "Retry" and "Cancel."
 
Frequently, the best commands are "Retry" and "Cancel."
 +
 
Provide the user the ability to do some set of:
 
Provide the user the ability to do some set of:
<UL>
+
* Try the action again (Retry)... used to perform the same action again immediately or restart the process
<LI>Try the action again (Retry)... used to perform the same action again immediately or restart the process
+
* Fix the user entry (Edit)
<LI>  Fix the user entry (Edit)
+
* Abandon the task (Cancel)... returning the user to a logical starting point
<LI>  Abandon the task (Cancel)... returning the user to a logical starting point
+
* Save the data (Save)... allowing the user to abandon the task without losing context  
<LI>  Save the data (Save)... allowing the user to abandon the task without losing context  
+
 
</UL>
+
== Related articles ==
  
<BR>
+
*[[Error message]]
----
+
--Submitted by - Aadhar14b
+

Latest revision as of 06:42, 9 May 2012

Article Metadata
Article
Created: User:Aadhar14b (31 Oct 2009)
Last edited: hamishwillee (09 May 2012)

Contents

[edit] Introduction

Error messages should give the user the information needed to solve the problem. In many situations, this means the underlying code needs to better differentiate error conditions.

Note.pngNote: Original article published at Little Spring Design under Attibuttion 3.0

[edit] Design Guidelines

  • Put error codes at the end of the message. This allows any support personnel to get the relevant information without costing the user is time to read it ... or risk having the code push some of the words off the bottom of the screen/window.
  • Keep the message short.
  • Give clues regarding what the user can do to resolve the situation.
  • Be specific.
  • Log the critical errors
  • Consider using a dialog box rather than a full screen, if your platform and device supports it.
    Example of Error Message
  • If possible, categorize errors into based on whether the user can fix the problem, the user needs to retry later, or an unfix-able error has occurred. Of course, many unfix-able errors should be fixed by the developer.

[edit] Commands (softkeys, links, or buttons)

Frequently, the best commands are "Retry" and "Cancel."

Provide the user the ability to do some set of:

  • Try the action again (Retry)... used to perform the same action again immediately or restart the process
  • Fix the user entry (Edit)
  • Abandon the task (Cancel)... returning the user to a logical starting point
  • Save the data (Save)... allowing the user to abandon the task without losing context

[edit] Related articles

This page was last modified on 9 May 2012, at 06:42.
118 page views in the last 30 days.

Was this page helpful?

Your feedback about this content is important. Let us know what you think.

 

Thank you!

We appreciate your feedback.

×