Developers silly ideas

Unnecessary error messages

There is nothing as upsetting, puzzling or emotionally unsettling as an error message. Common in Windows, error messages which in most scenarios are usually absurd also manifest in other platforms. You will come across many types of useless error messages. In our case, we will highlight a few examples based on Microsoft extensive page which explains what to do or not to do when creating error messages which is applicable to messages universally.

Excess technical details

Such an error message is composed of specialized information that the user cannot understand. An error message that is largely created using scientific language puts off an average user. The user does not bother to read it. They are incapable of developing a basis for solving the problem.

Programmers also have a habit of communicating programming errors using the end-user dialog box resulting in a secondary kind of this error. Users end up becoming very mixed up by useless memory violations or variable problems which result from errors.

Shifting the blame to the user

Error messages have a tendency of shifting the blame to the user. Users should not be made to shoulder any blame merely because of making an unintentional mistake. Neither does using cruel language help. It makes users more frustrated.

Lack of clarity

It does not help to create an error message that is very ambiguous. The user is at a loss on what to do when an error sound is detected followed by unknown error. If there is no bit of supportive details regarding the error, a user will click ok and ignore it.

Useless errors

Endless popup ads have encouraged most users to speedily eliminate dialogue boxes. Though error messages are in some instances useful, their continued use increases the possibility of users assuming them. It is an unwise move to create error messages for imaginary problems.

For example, where a user decides to abort a backup operation it is unnecessary for an error message to inform them of their action. Since they initiated the action, a dialogue is not necessary though the action might be interpreted as an error from a softwares perspective.

Forms and selection boxes that are awful

The expected type of input is the most important regardless of a programmer’s preferred option: selection boxes, dropdown lists or requests a user to key in a value. Ordering alphabetically is very suitable for dropdown boxes as it makes it simpler to browse the list. But it is very difficult to browse through a list of floors in an ABC order as opposed to a numerical order.

Inline authentication failure

This is definitely where programmers make users almost go nuts. It is annoying to go through too many fields on a page during a job application process or when signing up for a service only for an error message such as invalid email address field to display when you click next.

Then the worst happens when you reload the page. All the data you typed is erased. A user consumes more time typing the same data yet the problem could have been avoided if only the programmer had made sure inline authentication exists facilitating validation of input before you submit it.

The post Developers silly ideas appeared first on Just4Programmers.

from Just4Programmers http://www.just4programmers.com/developers-silly-ideas/