Your application is finally being deployed, and running now in the real world. It is your application and the user now, face-to-face.
The user will interact with the application, be that too often or otherwise, doesn’t matter, but interaction is at least there.
Since the user is interacting with your application, makes us assume that it at least met the user’s requirements who will be expecting some sort of reaction each time a request is made.
But, the question that arises here is: What if the application failed in reacting to the user’s request? Or, what should be done if some sort of failure occurred?
A good solution is to show an error message, since we don’t want the user to stay there confused and just wondering what has just happened.
Another question arises: How should the error message look like?
Let’s not forget that whenever an issue occurs with the application, the user will look for support, and you, or if a company, the support team, will be the target.
So, imagine that the error message that you have designed to be displayed whenever a failure occurs was something like the one shown in the following figure.
When the user gets the error, he will most likely make a call and tell you or the support team that he had an error, and the error was: Sorry, seems something went wrong!
What will you do? How will you deal with such error? And, how will you diagnose it?
Yes, a general error message doesn’t help.
A good practice to do as a developer here, is that when you test your program, pretend as if you were the user of that program. (I want to mention here that I will not go deep in discussing the roles of the developer and the roles of the tester, and the differences between the two, I’m just trying to emphasize how to feel with the user)
So, when testing a new functionality in your application, pretend as if you were the user of the application. Having an error occur, look at the error message, and ask yourself the following two questions:
1– Is it easy for me to understand the error message?
2– Does the error message help me locate the problem?
If you answer “Yes” to the above two questions, the error message is most likely useful, and thus, will be easy for the user to understand, and for the support team to locate the problem. Otherwise, the contrary is true.
Did you notice something?
Yes, the first question is targeted to the user, and the second one is for the support team.
The issue here is providing some sort of balance and reconciliation for an error message that combines between two different targets, the user, and the support team.
A workaround for this could be in doing two things:
1– Displaying an easy to understand message that targets the user.
Example: Could not login
2– Hyperlinking the text in the message to target the developers and testers. In this case, users, developers, and testers, can follow the link and provide more information on the error (The link in this article is just an http:// link for description purposes)
Example: Could not login [Click for more details]
We can also add the functionality of sending the error message through email to the support department once clicking on the link. And, this is suitable in stand-alone systems.
There are other techniques in handling and reporting errors, such as logging, but as you saw in this article, we want something that balances between the user and the support team (Developers and testers).
In this case, we will not leave the user clueless, and, at the same time, we will be able to increase the functionality of the support team especially when it is easy to locate the error.
Abder-Rahman Ali
Reference
Practices of an Agile Developer










