What to do when the user selects an End date less than the Start date of an Event

Question

Here is how a few todo apps on iOS handle an End date less than the Start date of an Event:

• Apple calendar app crosses the end date to mark it as invalid:

---

• Red End date in Google calendar

---

• Red Start and End dates in Fantastical

---

• Outlook (which is based on Sunrise) takes a whole different approach. It doesn't use the default iOS Date Picker control. If the event is an ALL-DAY kind of event then the user is presented with this date picker:

If not, then this is how the user chooses the Start and End dates:

Other apps like Memorandum auto update the End to be bigger than the Start date.

Which approach is better? and is there a better one?

Answer 1

In general terms the solutions either:

• Let the user select an incompatible date
• Not let the user select an incompatible date

The first group could let the user know the problem:

• Mark the start date as wrong (I didn't see it in your screens)
• Mark the end date as wrong
• Mark both days as wrong

The second group doesn't have the first group's problems. However, the system needs to either:

• Not permit this kind of incompatibilities happen in the first place (this seems to be the Outlook example)
• Permit the incompatibility while the user is editing but not let the user submit it and alert him somehow

---

In my opinion, the "best approach" is the one that doesn't let the user commit the mistake/incompatibility in the first place because the system is designed in such a way that it is simply not possible. I guess different solutions are possible with those premises.

Answer 2

From the examples above the meaning of “strike through“ or “red” is not clear enough for everyone. The user needs time to figure out what is wrong with the dates. It is frustrating.

In the example with the connector it is uncomfortable to switch between daily and weekly-monthly views each time and difficult with big ranges.

Blocking of the selection in the past in the date picker seems to be a more logical way. Though in case of editing the incorrect date is cleared, it could be improved with some undo feature.

Answer 3

I agree with @Alvaro. Error prevention is even one of Jakob Nielsen's 10 usability heuristics

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.

This means, a date before the start date should not be available in the selector for the end date. This way you even fulfil another usability heuristic, recognition over recall:

The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

This means, preferably the user doesn't have to remember the first date in order to correctly select the second date.

Answer 4

I'd go with

• Changing start date / time moves the event forward / back in time
• Changing end date / time changes the length of the event

All UI implementations you showed can do this, with slider being the best - you intuitively can't shrink a rectangle to zero or negative length.

For me, it maps well onto how I reason about events in real life. Say, I want to add a 2-hour workout to my calendar. If I have to fit it before another event:

• "I have to start earlier to be on time for the next meeting" (move start with the whole event)
• "I have to cut it short to be on time" (move end, decreasing event length)

And if I don't have meetings afterwards, only before, the start time becomes most important, then length. End time is mostly irrelevant.