Handling errors in a non-geek interface
source link: https://evilmartians.com/chronicles/handling-errors-in-a-non-geek-interface
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Handling errors in a non-geek interface
Contemporary interfaces can be complicated, tieing a lot of data sources together: i.e., a contact list can be imported from the device’s local storage, user pics come from the cloud storage, and the status comes from a social network. The more data vendors you have, the bigger is the chance something may go wrong and cause a malfunction.
It’s important to keep in mind that ill-timed, hard to find, or intrusive error messages can damage user experience significantly.
There are four basic ways to report an error:
- An interface-blocking message;
- A section-blocking message, leaving the other sections unblocked;
- A non-blocking message;
- An inline message displayed next to the malfunctioned element.
Interface-blocking messages
This type of reporting an error is the easiest one to make on the app. These can be native or custom pop-ups and alerts, blocking the interfaces or replacing interfaces as full-screen messages. In this case, the user can’t continue using the app, before the error is resolved or the pop-up is closed.
The interface-blocking messages are the most noticeable of all, but, at the same time, the most distracting. They should only be used in cases when any further work with the interface is useless, both for the user and the system.
Do: “Error 500, can’t display page”. The interface can’t be loaded, so the user has nothing to work with.
Do: “Session expired” in banking apps. Further interaction is unavailable or potentially unsafe.
Don’t: Internet connection is lost while a map is loading. The map can’t be refreshed, but the user can work with the parts already loaded. There’s a chance a piece of the map he was looking for is already on the device.
Use interface-blocking messages for major errors that make further work with the app useless.
Section-blocking messages
This way of reporting an error is more complicated in the making, but it, obviously, is a more delicate one.
If the interface is built with some separate widgets, receiving data from different sources and sending different queries, it makes sense to display an error in the malfunctioned widget, leaving the working ones intact.
For instance, if the page contains chat, friend list, exchange rates, and weather reports. If the weather widget has malfunctioned, there’s no need to disturb the other widgets. In that case, even a small error message with an OK button may disturb the user working with another widget, so there’s no need to use it.
However, don’t use section-blocking messages if the data had already been loaded into the block, and the error has occurred when updating it.
Do: “Unable to load exchange rates”. No data was loaded, further interaction with the widget is pointless.
Don’t: “Unable to update chat”. Just like the map case—the user may have received the information he needed, no point in disturbing further use.
Use section-blocking messages for local errors, making further work with the block pointless.
Non-blocking messages
Such messages are snackbars, pop-up statuses, and Android toasts. This type notifies the user about an error, without blocking any parts of the interface. Use it in cases where further work with the loaded data makes sense for the user and the system.
Do: “Unable to load a piece of a map”. The user can continue using the loaded parts but should be notified about an inability to update.
Don’t: “Form filling errors”. In that case, the user’s attention will be drawn away from the fields, in which the error is found. The user will have to look for the filling errors themselves. Another scenario is, the user may not know any errors have occurred, and wait, thinking that the form is processing.
Use non-blocking messages for major errors that don’t make further work with the app useless.
Inline messages
These are the hardest in the making. Inline messages appear next to the malfunctioning object, i.e. with invalid forms.
Inline messages are great because they draw the user’s attention right to the place where it’s needed.
Do: “Username is already taken”. Choose a username that’s free.
Do: “Invalid email address”.
Don’t: “Unable to send the form”. The user will focus on the element of a form, even though the error is global and related to the whole form. In that case, it’s best to use a non-blocking message.
Use inline messages for local form validation errors.
Next time, I’ll tell you what exactly you should write in your local form validation error inline messages.
Don’t forget to download the poster for your viewing pleasure.
Recommend
-
55
Mistakes happen. That’s a given. According to Murphy’s law, whatever can go wrong, will go wrong. Your job, as a programmer, is to be prepared for that fact. You have a set of tools that are prepared to do precisely that....
-
26
Handling Errors in JavaScript: the definite guide Photo by
-
40
README.md errors
-
37
Go 2 aims to improve the overhead of error handling , but do you know what is better than an improved syntax for h...
-
28
I actually covered this topic before, inthis post, but given my recent experience I feel it needs reiterating and a bit of restructuring. It boils down to the observation that any error handling I have encountered — be i...
-
18
When designing how to handlenetwork calls in your app, you might think that you are done as soon as you define your interface. You are halfway there: you have defined the "happy" path. But what happens when not everything...
-
9
Errors and Error Handling in JavaScriptWhy handle them in the first place?
-
21
What Can One Non-Geek Do?* Nov 24, 2002 The FuzzyBlog! : What Can One Non-Geek Do?* The FuzzyBlog! Marketing 101. Consulting 101. PHP Cons...
-
10
Raymond CamdenHandling Errors in Vue.js
-
7
A Quick Guide to Handling Express.js Errors in Your ApplicationMarch 17th 2021 new story5
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK