Entering a relative date range (in a report writer)

Question

Our company's B2B web app includes a simple report writer where advanced users can save simple reports that other users can run. Currently, every report includes a date range that users must fill in when running the report.

Our report-saving users would like the ability to define reports that pre-define a relative date range, to enable reports like "Sales for the previous month" or "Transactions in the last 30 days" where users who run reports won't have to enter the date range every time.

I've found good ideas (on UX.SE and elsewhere) for entering relative dates, but I'm stumped about UX for entering relative date ranges.

Some example date ranges I'd like to enable:

• Today (0:00 today through now)
• Yesterday (0:00 - 23:59:59 yesterday)
• In the last 90 minutes (relative to now)
• In the last 7 days (relative to now)
• In the last 7 days (meaning full days: 0:00 8 days ago through 23:59:59 yesterday, but not including today since it's not done yet)
• The 4th quarter of last year
• Last week (Sunday through Saturday)
• 4 weeks ago (Sunday through Saturday)
• Jan 1 2016 through Jan 15 2016 (even though our advanced users want relative date ranges, absolute date ranges are still the most common use-case!)

My initial idea is to use a dropdown box to choose various date range options, including:

• Range - absolute range would still be the default since it's the most common case
• Choices for each of the top 4-6 most common relative cases e.g. Yesterday, Today, Last Week, Last Month, etc.
• A "Relative Range" option to handle less common cases like "the last 30 minutes" or "4th quarter of last year".

But I'm stumped on what that "Relative Range" UX could be. Got suggestions?

I'm particularly struggling with the fact that ranges can either be aligned on boundaries (e.g. last month meaning the 1st through the last day of the month) or not aligned on boundaries (e.g. 90 minutes ago relative to now). How to help the user express which option is desired? And in the bounded case, how can the user declare what the boundary is (e.g. hour, day, etc.)?

The users who are saving reports in our system are smart but often very non-technical. Many don't even have good Excel skills. They are certainly not programmers. UX simplicity will be important for success here.

Answer 1

Circling back after 18 months (!!!), we finally have a design we're going to implement, so sharing it back here to close the loop.

@Monomeeth had a great answer. We didn't have the real estate for the graphical calendar icons, but I really liked his idea of a flat list of pre-set options and a "Custom" where harder UI could be hidden. I also liked the general idea of progressive discovery here, with simpler date ranges requiring simpler UX to pick them. We extended this in the final design to have several levels of progressive discovery.

We admittedly got stuck for over a year on what UI should be behind "Custom...". Every idea we came up with seemed too complicated. Finally we decided to scope back the functional requirements slightly in order to simplify the "Custom" UX a lot.

Here's the final solution:

• Users can flip from an absolute to a relative date range, and back again, making discoverability easy (and more obviously undo-able than a button or link).

• Users can pick from a list of predefined options for relative ranges.

• The most common non-predefined ranges have simple customization.

• For truly custom cases, we admitted failure in trying to accommodate our original requirements in an easy-to-understand and easy-to-build solution. So we went back and decided to relax a few functional requirements to permit a more usable UX. The main use-case we removed was being able to pick a specific starting or ending point e.g. February 15th of last year, or 12:30PM on the first Monday of last month. This relaxation of requirements let us simplify the UI considerably so that users only need to input three things:
  • the "Unit" e.g. week, day, hour, etc.
  • the "Start Ago" (in units) e.g. 2 hours ago
  • the "Duration" (also in units) e.g. 3 months

• Users can move down and up the progressive disclosure chain (Absolute -> Relative Predefined -> Relative ___ Ago -> Relative Custom) without losing data.
  • Absolute date ranges will be automatically converted to the simplest relative date range.
  • Relative date ranges will automatically fill in a (grayed-out) absolute date range so users can verify with an example and easily switch back to absolute.
  • Switching from a predefined range will automatically populate the Custom fields.

The most important lessons lessons our team learned through this process:

• Progressive disclosure is preferable to big jumps in complexity between simple and more complex use-cases. Design a gradual on-ramp to complexity to satisfy middling-difficulty use-cases which abound in business software.
• Don't assume you always have to design a solution to the original requirements. Sometimes it's better to build a really easy-to-use solution to the 98% use-case than a so-so usability solution that covers 100% of requirements.

Apologies for the blurry screenshots above (retina screen downscaling gone awry!). Also CSS is more polished in the final version-- these are old screenshots.

Answer 2

If it was me I would design the interface so that the most common (or useful) choices can be selected with the simple click (or tap) of a button/icon and the less common choices would be accessible from a "More" button (or something similar). See a quick mock-up below of what I mean:

Selecting the "More" option would bring up a sub-menu with some more common choices and the option of setting a custom filter, such as:

And, if the user selects custom, that's when you provide a pop up page/form from where they select the boundary (eg mins, hrs, days, weeks, months, etc) and the value(s) and/or ranges.

Hope this is useful. Obviously the options you provide may differ from my mockups, but you get the idea.