18

I have a form. My JS confirms the field values are valid before the form can be submitted. If invalid, it is highlighted red, focused, and given a tooltip with the reason.

Moreover, the Javascript will only submit the AJAX request if the entire form is valid; if any field is invalid, it won't submit the form (and submission is handled by the Javascript, so if Javascript is disabled, the form can't be submitted at all). Therefore, no legitimate user will ever submit an erroneous form: the only way to submit an invalid form is for the user to send their own AJAX request or tamper with the Javascript. In other words, theoretically, no user should ever submit an invalid form.

Of course, I do verify and sanitize data server-side. If this validation fails, the client is given a generic error, which is shown to the end user.

My question is as follows: Should I make the generic error more specific?

Improve this question
7
  • Leaving errors vague will definitely confuse a user.
    – UXerUIer
    Apr 28, 2015 at 13:39
  • If a user enters an invalid input, and the highlight and tooltip shows up.....can the user still be cheeky and submit the form? Or is the submit disabled if the form is invalid (according to client-side JS)?
    – tohster
    Apr 28, 2015 at 13:43
  • 1
    @tohster No. The form must validate before the JS will send the ajax request. The only chance here for a user to see an error from the server-side validation is if they create their own ajax request.
    – Mooseman
    Apr 28, 2015 at 13:46
  • 2
    If a user must go out of his way so as to pass client-side validation but fail server side (as a result of putting js in a field then we're truly talking about an edge case.
    – Mayo
    Apr 28, 2015 at 13:57
  • @Mayo We are. And that's why I'm asking if it's really necessary to provide detailed errors in such a scenario.
    – Mooseman
    Apr 28, 2015 at 14:23

8 Answers 8

Reset to default
28

This is a very common situation with client-side validation

In a world with no budget or time constraints, yes...of course users would be better off with more information.

In the real world, you probably have far better priorities. The only time when users would see a server-generated form error is:

(a) if your client-side JS is broken (in which case, you're better off spending time improving client-side JS rather than creating customized server-side error messages)

(b) Malicious / tampering ajax calls. For these, you don't want to be courteous to hackers anyway, and providing different messages for different server-side validation failures actually presents a security risk because the information can help hackers narrow the set of vulnerabilities to focus on.

Improve this answer
5
  • 6
    Another use case is the client has their javascript disabled. While this is becoming more and more uncommon it does still exist in the corporate world. Eventually it will be phased out entirely but i'm not sure we're at the point. You have to consider your audience and whether it's worth coding for the minority.
    – Howdy_McGee
    Apr 28, 2015 at 21:54
  • 4
    Agreed. However in this case if javascript is disabled, the ajax calls shouldn't work to begin with!
    – tohster
    Apr 28, 2015 at 22:01
  • Also if the service is ever used by another client, such as an app or other service then having error messages can be important.
    – Daniel Little
    Apr 29, 2015 at 1:00
  • 1
    To add on to (a): If your client-side JS is broken like this, your user doesn't care about the issue your server is seeing - it's likely to have nothing to do with what they put in the form, valid or not. So displaying an error message saying "field Y is wrong because it's written in klingon" is only going to confuse.
    – rickcnagy
    Apr 29, 2015 at 2:56
  • Agreed. Given the opportunity cost of time, if the JS is broken I'd rather focus energy on trapping and reporting the error so that it can be fixed quickly, rather than providing elegant rendering to a user but not solving the root problem as quickly.
    – tohster
    Apr 29, 2015 at 5:07
12

Yes, you should provide server-side validation along with client-side validation

Client-side validation allows you to provide feedback as quickly as possible. Immediate feedback allows users to identify and fix common errors without having to submit the form to see the errors.

Server-side validation messages provide a backup communication tool. There are a few cases where this backup is necessary, the most common would be those without Javascript enabled. Without Javascript, users only feedback is the server-side validation.

Server-side validation itself is a requirement for preventing malicious behavior and saving clean data.

Yes, your client-side validation should be specific

Any feedback given to users should be:

  • timely
  • specific
  • actionable

If you believe a user could possibly see the message, then it should provide specific feedback.

A generic message, such as "unhanded exception" is not a helpful message to your users, and without more details or a log file reference, it is not helpful to your developers either.

Improve this answer
7
  • 1
    Not worried about users with JS disabled; required for the rest of the app.
    – Mooseman
    Apr 28, 2015 at 13:44
  • This was the first reason that came to mind. Another reason js validation could fail would be js errors coming from: your application, 3rd party plugins, or a user's browser plugins. Again, if the possibility exists that a person will see the error, then the error should be written to be read by a person.
    – Benjamin S
    Apr 28, 2015 at 13:53
  • 10
    @BenjaminS +1 The only disagreement I have with this answer is the talk about server-side validation being a backup. As far as I'm concerned it's the client-side validation that's the backup. Server-side validation is a requirement.
    – MiniRagnarok
    Apr 28, 2015 at 17:33
  • @MiniRagnarok Good point about which is backup. I was thinking from the perspective of backup for communication to user. As far as error handling and saving clean data, you are absolutely right. The client-side is a weak first defense with server-side being mandatory. Suppose we were thinking about error handling from 2 different perspectives.
    – Benjamin S
    Apr 28, 2015 at 18:55
  • 2
    IMHO the server-side validation is absolutely required. You don't want people with malicious intent to bypass client-side validation and feed your DB with crap. Client-side validation is just a convenience; you don't want to waste your user's time with pointless roundtrips. Not if the client could already tell them what's wrong several seconds before the server answers.
    – Nolonar
    Apr 28, 2015 at 19:34
5

From comment and reply above:

If a user must go out of his way so as to pass client-side validation but fails server-side validation as a result of putting javascript in a field then we're truly talking about an edge case. – Mayo

@Mayo We are. And that's why I'm asking if it's really necessary to provide detailed errors in such a scenario. – Mooseman

There are two main scenarios:

  1. If the form does not work in the case that javascript is turned off then the only use cases involved are hackers and script kiddies having fun. You needn't be polite and friendly in those cases.

  2. If (as should most often be the case) the user can submit a form without javascript then a user friendly reply is best but it needn't be unique. A simple remark saying that "as javascript is not active the site is unable to give the best experience." At this point listing all the requirements per field may be an all-purpose response.

EDIT: This assumes that the client-side validation is done properly and anticipates all potential use cases. Meaning that the developers have considered internationalization, abbreviation (i18n) and other issues.

See the following great examples:

Improve this answer
2
  • You assume no bugs in the form in saying this. I've had to muck about with client-side JS to get a form to submit with a UK postcode because the (.co.uk site's) client-side validation was expecting a US zip code. It took me a lot longer than it should have done (I don't do JS or web programming) but even I could do it.
    – Chris H
    Apr 29, 2015 at 15:57
  • that's correct :-)
    – Mayo
    Apr 29, 2015 at 16:00
2

Simply, yes.

Why wouldn't you provide the user with as much information to rectify the problem, that they need?

Improve this answer
2
  • Why not? Because it costs developer time; if it is unnecessary and offers no value, then that alone is an understandable reason not to do it. In general, good answers should be detailed and provide evidence or reasoning to support their argument. A short remark like this would perhaps be better as a comment rather than an answer.
    – D.W.
    Apr 28, 2015 at 23:37
  • The server-generated message may be short and easy-to-implement. Sometimes overriding JS and crafting a query is the only way to answer "Why this button is disabled? There is no tooltip with explanation. Is this object read-only? Or is this not allowed for current user?". Sometimes JS check may be not in sync with the actual policy about acceptable data.
    – Vi.
    Apr 28, 2015 at 23:58
2

Yes, you should give specific error messages!

In a perfect world, errors would never happen. Unfortunately, we do not live in a perfect world. Errors can happen, and let me tell you that by far, the most irritating thing to come out of an error is a generic message such as "An error has occurred!"

The one product that I've seen this happen the most in is Microsoft Windows. I could go on for days about how bad Windows is, but it's just the worst when something crashes and gives an error code like 0x56DEADBEEF78, which you have to google to figure out what the actual error is.

If there's an error detected, my policy is to always make it clear to the user what's happening and announce that the input is unacceptable, why it cannot be accepted, and how to correct it. Take, for example, a case in which your Javascript code has a bug in it that will allow certain invalid inputs. Or, maybe your policies have changed and the Javascript is out of sync. Imagine being that user and being presented with the message "Invalid input." You would have no clue what's wrong and no clue how to fix it, correct? Now, imagine being presented with "Your username cannot contain the '[' symbol." Even if it's not caught by the JavaScript, the user instantly knows what's wrong with their username and how to fix it.

Additionally, these error messages would not create any security concerns, as the requirements should already be available to the user, which means that any error messages would not be providing otherwise unobtainable information.

I believe that software should always tell me exactly what's wrong and it's a bonus if it can tell me how to fix it. There is nothing good to come of hiding the error messages, so don't do it!

Improve this answer
1
  • I don't agree that OP should write server code to address the case where his/her client-side cod breaks. Instead, he/she should focus make client-side more resilient. If nothing else, it's really hard to write code that understands when other code has made an error of this nature, I think.
    – rickcnagy
    Apr 29, 2015 at 2:57
1

No (but...)

The critical points are that the app requires JavaScript to function and you're not intending to support a non-JS fallback mode of operation.

Having said that, you may need to consider accessability issues for users using screen-readers, etc, and may need to revisit the decision regarding non-JS support, in which case you'll need to supply a non-generic error, so it'd be worth seeing if there's something that could be done on the server-side that's not too much effort but would return a minimal set of information that would help such a user work out where the issue is.

Improve this answer
0

Don not worry about users who disable javascript in the browsers.

It depends on the back-end framework and API you follow.

Will anyone else use your API?

If yes : Answer will be Yes you need to make the error message more specific.

If NO : Answer will be NO since your UI is the sole user of the back-end and your your UI has got all the validations done properly for sending only valid data to the server.

But in future some some one will come and try to give another UI for the backend and if the back-end doesn't have any specific error messages then it will be tough for the new one to develop the UI

Improve this answer
0

Not providing specific error messages can come to bite you in the end, when some bug in your JavaScript code causes an invalid submit and the only diagnostic you have is an e-mail from a user saying it said ‘Generic error.’

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.