Error feedback in Kube

One of the most frustrating user experiences is when you get an error message that you can’t do anything about, or even worse, that you don’t even understand.

While it’s very well possible that the error message is entirely justified, wouldn’t it be great if the system didn’t just tell you that something is wrong, but also what you can do about it? Error messages can be even more infuriating if they block you from doing your work even if they are not directly related, thus interrupting your workflow unnecessarily. Wouldn’t you rather have a notification that something does not work as it should, while otherwise letting you go about what you wanted to do, instead of just popping up a blocking popup that you have to click away before you can do anything else?

That’s what we’ve worked on last week.

Kube has a log view that collects “things” that happen in the system, and as part of that, errors. That view will eventually turn into a timeline of all things that happened;  downloaded attachments, sent mails, warnings, errors, … but that’s a topic for another post. For now the logview will mostly serve as place to capture errors and make them visible to you.

However, to go a little beyond a bunch of text that tries to explain what’s wrong, we support specialized UI’s for certain classes of log entries. Point in case; one of the most common errors is a problem with your credentials, and we have thus created a dedicated error view for that error case.

Not only does this view tell you clutter free what’s wrong, but it also allows you to directly act upon it, and thus resolve the issue.
Because the handling of the error is optional this also doesn’t interrupt your workflow, you can perfectly well browse your local mail without correct credentials after all, so why not let you until there is an actual necessity to fix the problem. So instead of showing up a blocking dialog, we notify the user with a little notification (that is perfectly safe to ignore), and hint at where you could find more information about that by highlighting the log view button (the icon is work in progress…).

With this approach we can directly support the users in the problems they face; Instead of writing an FAQ somewhere hidden in a wiki, why not support the user as best we can directly in the application.

Of course there are only so many classes of problems that the user can do something about, there are also bugs sometimes where the user can do nothing but report the problem and hope for the best. But even in that case we can support the user in gathering the right information and submitting that to the right place.

For more info about Kube, please head over to About Kube.