12

We are developing a date ranger picker and are in doubt how to present preset time periods. The scenario is this: EITHER the user utilizes a preset period, e.g.

  • Next 7 days
  • Next 3 months
  • Latest 7 days
  • Latest 3 months

OR s/he specifies a From and a To date. My question is this:

  • How is the OR functionality best represented in the user interface?

Three of our multiple design alternatives are:

enter image description here

In the picture above the "Setting alpha" etc. are just there to show the date ranger picker in context of other controls.

On our team we are most kean on alternative (C) since it explicates the OR relation in a standard way using radio buttons. However, one might object that it's too explicated, and that e.g. alternative (B) is more terse. But, if alternative (C) is the way to go, how should that behave in more detail, e.g.:

  • Should choosing a date preset automatically fill in the From and To fields below the preset dropdown?
    • And if not: How do you convey to the user what e.g. "latest 3 months" means in terms of exact start date?
  • Should the non-selected option be greyed out and reset?
    • And if so, should the non-selected field become active when clicking on not only the corresponding radio button but also the input fields, e.g. the dropdown or the date fields?

What is your take on this? Which alternative do you prefer - or do you have any better suggestions? Do you have any good examples of how to present presets to users?

Improve this question

6 Answers 6

Reset to default
7

In that order: B (with the handling detailed below), A (spelled it out), C.

C is for me the "typical techie solution": you first decide how to specify the duration, then you specify the data required for that algorithm. However, it's just two additional controls to manage, and the users don't know the options ahead. That said, if your users are techies / analytical thinkers, and it's easiest to implement, go for it.

B would be preferrable:

enter image description here

Minimum requirements:

  • Both "preselect" and date/time controls are always available (never disabled)
  • changing the preselection changes the time displayed in the range controls
  • changing the range controls changes the preselection to "other"

Almost Perfect:

  • compare manual selection to your presets, and show "other" only if there is no match
  • when the user select "other" manually, show a hint like "slelect start and end date here"

Advantages:

  • Users with a vague idea of your app have a set of typical options
  • Users get immediate, concrete feedback for their choices
  • Choice can be refined, e.g. "next 3 weeks" can be refined to "4 weeks" easily

Variants:

  • Instead of "other", generate suitable textual representations (e.g. "next 17 days").
  • If the app is used mostly by regular frequent users (few casuals), consider a free text input like Hisham suggested: clicking around to enter three timespans in a given day is fine, for entering 30 in an hour is a pain, and free text wins.
    (I can't think of a simple combined interface that doesn't somehow penalize novice users, but if you expect a wide range of users, you might need to conside some solutions for that)

Layout notes:

  • I'd omit the "from" purely for clean look, but there's a tradeoff. I generally try to give controls an equal size, and line them up on few lines to avoid a "restless form" look.
  • Group preset and date picker together (i.e. give them some distance from the other selections)
  • "Duration" is of course a stupid label, sorry ;)

(side note: Instinctively I'd assume an interval of seven days to go "from Feb 17, 0:00 to Feb 23, 23:59:59.9999..", but I'm not sure if this universal.)

Improve this answer
1

I would go with option C, but with a few changes. As I see it, the design is straightjacketed because of the fixed-options preset periods:

  • Replace the presets popup menu with a simple edit field that lets users type, e.g. "7 days" or "7d". This is a little bit more work because you need to allow users to abbreviate and yet parse intelligently, but it's worthwhile the effort, I think.

  • Drop the radio buttons; it's no longer an "either or" proposition.

  • Have the edit field update automatically when the user makes a selection on the date pickers. And vice versa: update the date pickers' values automatically when the user enters a new value in the edit field.

  • Change the label "Time period" to "Duration".

  • Add a couple of extra labels here in there (From, To, etc).

Can't think of anything else. :-)

Modified date picker

Improve this answer
1

Have you considered doing it the way 37 Signals solve it in their applications? Single select field with options being "Next 3 days", "Next 7 days" and so on and then last option being "Custom range" (microcopy is not my strong side here, I admit, sounds a bit too technical) - checking the last option would show the datepicker fields.

Improve this answer
1
  • No, we haven't considered that. Actually, a rather clean approach. It is, however, not without trade-offs. If the user is looking for a custom date, then your suggestion introduces an extra step of interaction compared to e.g. design alternative B in my initial question. Also, since "Latest 3 months" is an imprecise period, it would be useful to be able to see the date pickers with the exact start and end dates (it could be written in a label, though). Furthermore, this interface doesn't support a scenario where the user utilizes a preset as a starting point for further fine-tuning.
    – agib
    Jun 1, 2011 at 7:37
1

Dropdown with following options:

  • Next 7 days
  • Next 3 months
  • Latest 7 days
  • Latest 3 months
  • Custom

And when they select custom the datepickers appear.

Improve this answer
1
  • Seems you suggest exactly the same as Mariusz :)
    – agib
    Jun 1, 2011 at 7:37
0

I would go with the B version because the time period and selectable from - to dates are connected, e.g. if you change the time period, the from and to dates will be updated, and vice versa - if you change the the from - to dates the time period will be updated.

Version A seems odd since the time period and from to dates are the same, so an "or" between breaks logic.

Version C has an unnecessary selector since you don't have to choose in what manner you will enter the time span, both will update both.

Improve this answer
3
  • 1
    The main problem with alternative B, as I see it, is the risk of sending the message: You need to fill out the suggestions in order to input the time period. Placing the suggestions to the right of the From and To boxes perhaps sends a message, that is more: "this is optional". However, with a placement on the right suggestions might get overlooked and so loose their raison d'être as shortcuts.
    – agib
    Feb 16, 2011 at 16:04
  • In B if the user first selects one of the time period suggestions and then alters the From and To boxes the suggestions dropdown box should default to "(time period suggestions)" as is your point, if I understand you correctly. With regards to alternative C then, yes, an extra click is required if the user cannot alter the radio button setting by choosing e.g. the suggestions dropdown or the From or To boxes directly.
    – agib
    Feb 16, 2011 at 16:06
  • @agib Yep, I'd go with C as well provided entering a value in either the suggestions or one of the time period fields will make the radio button "follow" the input (switch automatically to where you are typing).
    – Marjan Venema
    Feb 16, 2011 at 17:10
0

I don't like the idea of having two different kinds of input fields to manipulate the same data. I think that would be confusing. Do I need to select something in the range selector AND both date fields? What happens if I set the date in the date fields manually and the check out the range selector out of curiosity? Does it still work if I select a range first and than change one of the dates? Is the other one changed to fit the range? All of that is not really obvious from any of the UI ideas.

Maybe this is purely cosmetic, but imho the range selector shouldn't be a form field, but rather some kind of helper for the two date fields. Something like that:

date range selector helper

And once the user has changed one of the dates himself, you can change the helper to work only on the other field:

date range selector helper 2

Having the ranges as links instead of a form field at least makes it clear, which of the entered data counts in the end.

(sorry, no reputation, so i can't include images yet)

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.