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 over the next few weeks. Thanks for all your past and future contributions.
m (Formatting and bold of some text)
|Line 58:||Line 58:|
<b>--- Edited by Mayank on 16/06/2009 ---</b>
<b>--- Edited by Mayank on 16/06/2009 ---</b>
Revision as of 18:49, 26 June 2009
There are lot of times when despite the best efforts of the developer/designer, they can not avoid a run time error from happening and it becomes imperative to notify the user in such cases. For instance the user wished to download a file or say delete a file from the mobile and for some reason the download failed or the file deletion did not happen. Now in these cases unless and until we notify the user they would be under the impression that the action was successfully completed. This is certainly not desirable as when the user does discover that the request didn’t complete successfully they would end up feeling let down by the application they were using.
Reliability of the solution remains a crucial aspect, one that drives user confidence in the system which in turn leads to higher satisfaction levels. The user probably would not mind seeing an error provided the user does make sense to them and doesn’t come across as either too complicated to understand or as an obvious software bug.
Have you ever run into an error message that just didn’t make any sense? I know I have! It’s rather annoying to get a notice that says the system will be shut down but not telling why. Have I done something wrong? Did I push a button I wasn’t supposed to? WHAT HAPPENED?? (the caps are intention to denote the frustration of the user with the software because they cant seem to understand what happened and neither were they notified of it)
There are guidelines for designing error messages. The main point to remember is to tell the user:
* Something has gone wrong
Always notify the user if something has gone wrong and specially if that’s something which would potentially require user intervention to rectify. For instance if the user tried to play a media file and it doesn’t exist, or he specified an access point which doesn’t exist to create a connection etc. In these cases the software would probably be relying on the user to provide it with something more meaningful like a valid file name, access point etc.
However in cases where though an error has occurred but that’s something from which the system can recover on its own, in those cases we first want to give it retries before notifying the user. As too many errors could very well end up convincing the user that the software is half baked.
Use the right images/language to attract the user’s attention. For instance it might be a good idea to use a red exclamation point. Another thing to remember is not to overdo the error message or the icons that you use, something like using a skull-bones icon to depict a simple connection failure or something.
* What has gone wrong
Most users don’t understand the technical complexities behind the scenes and neither do they need to know about them, hence it is our job to ensure we keep that hidden from the user even during error conditions. While displaying errors try to use sensible and easy to understand languag as most users don’t understand technical terms.
* What to do about it
In case it is possible to overcome the error by doing something then do notify the user and if possible provide help to recover from the occurred error. In cases it is not possible to do anything about the error let the user know of that as well so that they don’t end up attempting the same thing again only to be frustrated. For instance if the user is trying to make a call without a SIM card, let them know something like Only emergency calls supported, please insert SIM card to make calls. In another case where the user tries to make video call when the operator doesn’t support video call video call not supported by network and then possibly open up the alternate choice list like voice call, SMS etc.
* Localize and personalize
Like all the other aspects of user interaction, the error messages should also consider the localization and personalization aspect. Consider using locale specific content depending upon the geographies, also keep in mind the target user and their skill sets to display an error message which would appeal to make more sense to them.
So NOT like this:
NOTE: This error message was made for this occasion with Atom Smasher’s Error Message Generator.
--- Edited by Mayank on 16/06/2009 ---