An application that I'm working on allows users to submit object data in a blank row at the end of a table.

The problem with this is that some fields are cross-dependent. For example, an end date can't occur before the starting date; hence trying to fill the end date before the actual start date is entered, would raise a validation error.

What would be the best approach to do validation in this kind of scenario?

  • I don't really get the "submit object data in a blank row at the end of a table". Which table are we talking about and where exactly are the date fields with relation to it?
    – Izhaki
    Commented Aug 23, 2012 at 2:53
  • Also, your question implies you validate on blur. Is it of interest to you to hear the benefits of alternatives, or is blur-validation required in your system?
    – Izhaki
    Commented Aug 23, 2012 at 2:54
  • Hi Izhaki, I thought that the "submit object data in a blank row at the end of the table" would do for an explanation... I have a big table, where the very last row is empty so that it allows users to enter new data. And yes :) I'd like to hear about the benefits of blur-validation against submission-validation ones!
    – edgarator
    Commented Aug 23, 2012 at 4:40
  • I'm afraid that now the two other answers combined cover pretty much all I had to share.
    – Izhaki
    Commented Aug 23, 2012 at 11:34

3 Answers 3


The first thing to address in the words of Jakob Nielsen and one of his ten Heuristic User Interface Principles

Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

If form elements are placed in the right layout/structure some of your validation issues will solve themselves. Some overall positioning and layout guidance I have been given/used in web applications is too:

  • Arrange cross-dependent inputs in such a way users would not logically attempt to jump to the last input first. "One must start something before they can end it." so logically have start date before end date.

  • Place any cross-dependent input in tab order of each other. This way users are one "tab" key away from the next dependent field(s).

  • Make inputs labels/instructions as simple as possible.

  • Segment large amounts of cross-dependent inputs into smaller logical sections and place in a progress/wizard workflow if applicable.

As stated these are basic guidelines. Since its not possilbe to prevent users from every making errors validation logic is still going to need to be added to some level. In these cases focus on putting only the simplest set of validation in place at the beginning of an application and slowly increase the validation requirements as a user moves through the application for cross dependent inputs.


If your validation engine normally validates on blur, change it so the first inputs validation rules are much more lenient. I.E allow Start Date to be either no value/ has a value that is formatted correctly; and not in the past (if that is a requirement in the business logic). Then force the End Date validation to be much more strict to ensure both fields contain logical date values or nothing at all (if allowed based on business logic).


Related to inline vs submit validation... There is a great article by lukew http://www.alistapart.com/articles/inline-validation-in-web-forms/ presenting findings of submit vs inline validations. Overall, there are significant benefits of inline validation (success rate increase, satisfaction increase, error decrease, completion time decrease). Validating when user moves to the next field (on blur) outperformed validation displayed while the user is typing.


In the specific case you mention, you could constrain each field based on the other. So, if the user goes to the end field first, they can enter any valid date. But when they later visit the start field, it will either prevent them from choosing a date after the end date, or provide an error message if they do so (the latter would be preferable iff users might not realize why the date range was limited).

It might not be possible to do this elegantly in all cases -- for example, if field B is a selector that's populated with options based on field A. In that case you would want to provide that information before the user attempts to enter anything at all. For example, you could deactivate field B and include placeholder text saying to fill in field A, or you could provide that information in a "validation" message triggered as soon as field B is focused.

Your Answer

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

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