12

I'm trying to figure out what would be the fastest and most convenient way to select a departure date and return date for a flight searching form.

The standard for the travel industry is to have one calendar for departure and one for return but since around 70% of our users search trips that have a duration of 2 weeks it seems to be a slow approach for selecting "date 1 + duration".

In our language, at least in Sweden, we don't phrase durations the way many systems do. One don't say or think "I'll depart 10th of october and return 24th of october". One say "I'll depart 10th of october and be gone for 2 weeks".

So wouldn't it be faster and better to use one datepicker + duration instead of the standard double datepickers that most travel sites use? Also it would be much faster on devices without mice input (phone/tablet/future unknown device).

Images

Click the images for larger sized versions.

.

Standard 2x datepickers

Standard 2x datepickers

1x datepicker + range select

enter image description here

Description of the above (note the "...or use calendar")

enter image description here

Update 23 may 2014

Updated example/test with inspiration from Izhaki's reply

enter image description here

Update 28 may 2014

iPhone 4 example. The iP4-version was created to check how well the ideas can fit within smaller viewports. Not sure about the "Back"-button stuff. It may be better to leave the date range selection outside the calendar view instead of incorporating it within the same view.

enter image description here

Improve this question
1
  • 5
    I've recently had to design a date picker, the UX way. I feel that if I documented the research and showed the conceptual designs and their analysis it would easily fill 50 pages. I can't express the delight I experienced when I read that in Sweden the metal model is start+duration. Amazing example of cultural context.
    – Izhaki
    Commented May 21, 2014 at 23:11

3 Answers 3

Reset to default
7

The reason why the two calendar approach has been adopted so widely and is so convenient to use is because it is in sync with the users' thinking process i.e. when people go for booking a ticket, they know the dates for departure and return of their travel but are not often consciously aware of the duration of their stay. Making them state the duration (and hence, mentally calculate it first) increases the short-term cognition load. Also, say I'm departing on the 10th and returning on the 17th, I'm going to pause for a moment and think whether I type in 7 days or 8 days as the duration^

If you're still insistent on changing the interface (yes, the current version is boring) you may want to go with the approach which @user43251 stated but by giving it a more intuitive feel by implementing the below detailed approach

departure picker

It is clearly stated which date (departure or return) the user is choosing. While selecting the departure date, the return button is disabled. After selecting a date, the user proceeds to selecting the return date

enter image description here

I have specifically selected this approach because there is no confusion as to what a click will do (after selecting both dates once). In this approach one can easily edit the return date easily if there was a mistake in initially selecting it*. Also, there is a field at the bottom indicating the duration where the user can also manually enter the duration (if you feel so, you can highlight this area more using colours and type)

To make the UI more interesting / visually appealing, you can implement the bold/large text details and mess around with the typography as you've done in your mockup. Something like this probably:

enter image description here

^you may say "I'll depart 10th of october and be gone for 2 weeks" but that is not very specific since it usually implies a tolerance of 1-2 days

*unlike the one at http://jsfiddle.net/IrvinDominin/LALED/ where the journey period is the one between the last two clicks (discards previous clicks and thus punishes a user for entering the wrong information by making him enter it again. And even worse, this is not obviously apparent and can be gleaned only after a few clicks)

edit after OP's comment

in that case, the duration field can be highlighted more (colour, typography etc.) so that they fill that in first. the layout can also be slightly changed.

the objective of reducing the short-term cognitive load remains the same. knowing the users' mental process and designing a solution for it changes with the user base you take into account. in case you are sure about your user research, the solution suggested by @Izhaki is a pretty good one. i have done slight modifications to it according to what i personally think would be most effective.

enter image description here

Obviously the visual design has to be improved, but the pros of this interface vs Izhaki's one are that a user can enter much a larger or smaller number without having to scroll a lot. Also the when the number of days are listed in a row they might be confusing with the numbers of the calender. (note that i've reduced the number of dates listed in the calender so that the week before departure is not shown and the next two weeks after departure are only shown. this compresses the size of the interaction element so the user does not feel overwhelmed by an unnecessarily large interface)

p.s. this interface is for the booking return part. for booking the departure part, the earlier design stands. thus, the entire flow is like: user clicks on field -> calender pops out for booking departure date -> user clicks on departure date -> same calender transitions to now indicate return booking and accommodate the field for number of days

Improve this answer
2
  • 1
    ...when people go for booking a ticket, they know the dates for departure and return of their travel... That simply isn't true for my target audience in Sweden. It's the other way around -- they know when they can go but with the two calendar view they need to calculate date 1 + X days/weeks. Do note that we're talking about leisure travel and not business oriented trips. The largest travel sites in Sweden actually uses the duration approach instead of double calendars. However one doesn't need to have one or the other; note the ...or use calendar that toggles another calendar.
    – Tommie
    Commented May 22, 2014 at 13:13
  • edited my answer to reflect your observations
    – BatlaDanny
    Commented May 22, 2014 at 14:28
5

I think you've pretty much sold the duration idea, but I'm not sure how it would be quicker on touch devices?

Also, I'm not sure why there's a combobox for duration. It's an extra click and I'm not sure what's inside.

Perhaps you may wish to borrow some ideas from this design:

A date picker with cal and days selection

Notes:

  • I'm sure you can do a better job on the colours.
  • On the calendar, you may also wish to signify the return date somehow.
  • You can add 'show calendar' next to the How many days? heading to toggle days/calendar selection.
  • If you do show some marks for days away, you'll run into usability trouble if the return is beyond the view (so for instance, someone on this calendar picks 30th of Mar, with 14 days - the away dates will end on the 4th of Apr, which could be confusing. With a month view, any trip that is longer than 35 days will surely have this issue.
  • It's pretty much a common knowledge now that the real-world metaphor of one-month-per-page reduces usability. Very few calendar widgets catch up with how calendars should be - just continually scrollable years (like on the iPhone). So you can really go to town if you implement things that way, which will solve the return-date-out-of-range issue in the bullet above.
Improve this answer
4
  • Thanks for the great answer and example, where did you find that example? The reason for combobox is that comboboxes works great on touch devices and it's very easy to select things within a combobox (once tapped). The ´How many days´ in your example requires the user to tap ´<´ and ´>´ -buttons (or slide) and makes mixed input harder. If i want mixed input like ´2-5 days, 1 week, 2 weeks, 3 weeks, 1 month, 2 months, 3 months...´ and apply that to that sidescrolling thing i would also have a problem with space since 5+ mixed choices requires more space (can't leave out the word ´days´).
    – Tommie
    Commented May 22, 2014 at 11:34
  • 1
    I produced this wireframe for this post; it's just a modification of a wireframe I already had. Obviously, it is just a conceptual design that still need work. But it is clearly in appropriate given the mixed input requirement, which I wasn't aware of before posting this answer. But I hope it helped anyhow, if not other people reading this post.
    – Izhaki
    Commented May 22, 2014 at 22:20
  • Oh -- ok. :) The reason i asked was because it would be interesting to see how the author had solved misc challenges around the one we're talking about. I've updated my initial post with an adaption to the duration selection and added mixed inputs. It isn't quite there yet and i'm not sure that a sidescrolling area in this context would work that great on touch devices since the arrows suggest that one should tap those areas in order to scroll (tapping small areas isn't great). Also the Summary need work since touch devices @ portrait doesn't offer the space needed for a two column layout.
    – Tommie
    Commented May 23, 2014 at 11:13
  • Updated example with iPhone 4 example. The transition to a smaller screen may make it easier to have the scrolling calendar view in a separate overlay.
    – Tommie
    Commented May 28, 2014 at 8:54
1

How about 1 datepicker that lets you select the departure date and the return date (the range)?

enter image description here

Here is a working example:

http://jsfiddle.net/IrvinDominin/LALED/

Improve this answer
3
  • Thanks for your quick response. However i don't find the double click/tap action to be clear enough and such date range selection just is too alien for people searching on travel websites. It doesn't follow the "as one speak or speak" either since it's still a "dehumanized" way of thinking about date range selection (date1 - date2).
    – Tommie
    Commented May 21, 2014 at 15:14
  • FWIW, I would go with the 2 datepickers but also add the duration for confirmation (as in your last example) - so a combination of your two ideas.
    – user43251
    Commented May 21, 2014 at 15:44
  • +1 I actually like this, but I agree with Tommie that the fiddle lacks affordance for two clicks. It would need some instructional text to make it work for "novice" users (novice meaning never having encountered this implementation before).
    – Marjan Venema
    Commented May 21, 2014 at 17:46

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.