Game Development Reference
In-Depth Information
from the error is particularly important in the mobile arena, where browsers may not have an
easy-to-find “back” button, where contextualization is frequently difficult and where re-entry of
URIs as a means of error recovery is particularly difficult.
It is noted that errors due to networking, connection and some kinds of mistyping of URIs are
not within the control of the content provider, which has no way to influence how such errors are
presented to the user. However, where errors are within the control of the content provider the
user should be provided with clear information regarding the fault they have experienced. This
should help them to understand whether the fault was temporary or permanent, whether they
should retry the attempt to access the content and how they may be able to escalate the problem.
It should also be possible for the user to escape from the error condition. They should either
be able to return to the page they were on prior to the error, or to be able to move onwards
to a convenient part of the service from where they can retry or alter the transaction they
were attempting.
5.4.13.2 How to do it It is noted that many Web servers provide a default error page,
especially in the event of a request for a non-existent page (404) or an internal error (500). Where
possible, applications should trap all error conditions by overriding the default pages if necessary,
and handle them in a user-friendly, and graceful, way.
Error messages should be provided in the same language as the application that was being used.
They should be clear and concise, adhering to the same Best Practices as the rest of the application.
They should be provided in a format that the device can handle.
The error message should detail whether the issue is likely to be temporary or permanent, whether
the user may be able to solve the issue themselves (for example, by changing input data or a
handset setting), or whether it is an issue that can be escalated to the content provider or network
operator. In the latter case, contact details, such as an SMS address or a support line number,
might be appropriate.
The error message should provide one or more of the following navigational constructs:
1 A “back” link to return to the previous page (particularly for devices that do not have an
easy-to-find back button);
2 A “retry” link to attempt the relevant part of the transaction again (note that this may not be
equivalent to a page “refresh”);
3 A “home” link to allow the user to return to the main part of the application.
The error message can provide an error code to be used for diagnosis of the issue. However, the
use of an error code is not a substitute for a human-readable message. While some users may
understand “404” to mean “page cannot be found”, this must not be assumed to be true for all users.
Search Nedrilad ::




Custom Search