Better way for users to select a date range

  • In my application, users select a date range for which results are required. The UI looks something like this:

    Existing UI

    My users don't like this, because the date picker requires them to select a specific date. This is far more precise than they require - most of the results compiled by the system have results just monthly or quarterly. Some are only yearly.

    The two ideas I've come up with are these:

    alt text

    On the left, just use a combobox to select from valid dates. The problem with this approach is that sometime the results will be daily and the valid date range goes back to the 1860's. That adds up to far too many items to handle in a combobox.

    On the right, using a trio of comoboxes to select the date. This has some advantages. If the results are going to be monthly, I could disable the day combo; if the results are going to be quarterly, I could also restrict the items available in the month combo. But, it seems that this design requires a whole heap of clicks to use.

    What's an alternative design for the UX that allows users to select just "useful" dates more easily?

    My technology stack is C#, WinForms, .NET 3.5

    Update Oct 1

    • The date ranges selected by my users are typically long - several years to several decades - pulling back sparse results over a long period.
    • The only common defaults that have been identified are "As early as possible" for the start date, and "Until today" as the finish date.

    Lots of good ideas in the answers to date - thanks to all.

    Update Oct 2

    • Some of the answers below (and I assume many of the readers) are assuming I need the date range for report generation. Actually, this particular part of my application is more of a query engine. If this detail inspires any new ideas, please answer away.
  • In general users are pretty accurate and fast at entering dates as strings in a text box as long as your validation isn’t unnecessarily fussy and provides decent auto-correction and defaults for the sub-fields (e.g., accepting 2-9-04 as well as 02/09/2004). Calendar controls are great to provide as an option when the user isn’t certain of the date (e.g., for cases when the user is thinking “Wednesday next week”), but they shouldn’t be the only way to enter dates. Separate dropdowns for each subfield makes it slow for the user.

    If you have access to query logs, study them to get a better sense what kind of dates users are using. While you may need to support arbitrary dates back to 1860, you may only need to optimize the design for a small number of dates or date patterns.

    Here’re some possibilities:

    • Defaults. Possibly most of your queries are predictable just from the page the user is on (e.g., for last month or last quarter or last year depending on the page/window). Default your From-To range to these values for each page and users will hardly ever have to enter anything.

    • List of typical date ranges. If a few date ranges constitute the vast bulk of your queries (e.g., each month of last year), list them in a list box or radio button list. The last one would be “Custom” which enables a couple text boxes with calendar controls for user entry of specific dates.

    • Dropdown for common inputs. If there are a relatively small predictable list of From and To values, then provide From and To combo boxed that each accept any user-typed date but with a dropdown lists of the most From and To common dates (e.g., beginning of each quarter in the last year for the From field).

    • Single Text Box. If most date ranges are whole months, quarters, and years, then provide two methods of entering date ranges. The default has a single text box labeled “Month, Quarter, or Year;” which accepts input like “Sep” (defaults to most recent September), “6/09,” “3Q06”, and “1933.” Study user written materials to see what kinds of strings to anticipate. The non-default method provides separate From-To text boxes for arbitrary dates.

    • Micro-grammars. If it’s mostly your expert users that are complaining about date entry, then consider supporting micro-grammars for the From and To text boxes, where the user can enter an exact date or various other syntax shortcuts (e.g., “Last Quarter” or “LQ” in the Start box is interpreted as all from the most recently completed quarter). See Collecting data efficiently with text box micro-grammars

    Microgrammars. Love the term -- thanks for this tip that was a highlight of your comment for me. I think Apple's Data Detectors are pretty awesome at this in Mail for instance.

    Great ideas. Given the typical length of date ranges (see my update of the question, above) not all of these are appropriate. Allowing flexible entry through a text box and forgiving parsing, perhaps with a microgrammar, seems like a winner. I'll include a prototype of this in my user testing.

    the textual input may give you i18n issues, is 2-9-04 in September or February? of course this may or may not be an issue for you depending on where it has to work and if you can localize

    Well ... the application is used by a bunch of internal users (it's not outward facing), so it would seem defaulting to NZ regional settings D-M-Y would be safe ... except that many of my users pefer the american M-D-Y for some reason. Sigh.

    You could make D-M-Y the default interpretation of #-#-## input, but make M-D-Y a user option. In any case, you may want to accept #-#-## as input but on completion of entry automatically convert it to something unambiguous like dd Mmm yyyy or yyyy-mm-dd to provide feedback on how the input was interpreted.

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM

Tags used