In a reporting client I'm working on now, there is a need to filter data by different conditions, among which are conditions based on date/time. Decided, that user first selects a predicate from a drop-down menu, then enters an absolute or relative date/time value in a textbox.

My issue concerns relative date/time values. Suggestion is to use shortcuts (d, h, m) for value and sign (- or +) to indicate in which direction it should be shifted from now.

For example, if now is 15:45,

  • [earlier than] [ -3h] -- means "up to 12:45"
  • [ later than] [ -2h] -- means "starting from 13:45"
  • [earlier than] [ +2h] -- means "up to 17:45"
  • [ later than] [ +1h] -- means "starting from 16:45"

Is my approach obvious and easy to understand? Are there some other common ways to solve this issue?

If user enters a value without sign, how it should be treated?

The main use-case is the following: first a user sets up all conditions, then saves the whole filter for further usage. Filters are created once after installing and sometimes when a user needs some specific report. Saved filters can be modified, but this won't happen often--maybe once a day or a week. Users are enterprise, not wide audience, so some sort of training/tutorial will be provided.

  • how often will this widget be used by users? 1, 10, or 100 times a day? are the users consumers, or will they be trained to use the tool? – tohster Aug 14 '15 at 16:54
  • @tohster a) rarely, user sets up conditions once, then saves the filter for further usage (and can sometimes modify conditions, maybe once a day or week); b) they are enterprise users, not wide audience, so some sort of training/tutorial will be provided – Alex Salauyou Aug 14 '15 at 17:05
  • Sasha, thanks. Can you add these details to your question please? Also, what is the time range here? Your examples only show hours, but you seem to be making provisions for days, hours and minutes. Can the user select 1d 23h 43m (i.e. combined/composited)? Or only 1d or 10h or 15m? – tohster Aug 14 '15 at 17:12
  • @tohster sure, I suggest to parse combined offsets like -3h20m as well as simple -110m. In Russia, this cannot be treated as absolute time, which is always written with numbers only, like 15:20 – Alex Salauyou Aug 14 '15 at 17:27

Personally, I have to say I find the plus and minus symbols somewhat unintuitive... to me, "earlier than minus 2 hours" is a double negative that combines to mean "later than 2 hours", or something :)

Are you restricted to two fields? With a second dropdown at the end, you could be more explicit, e.g.:

[up to ]      [ 3h] [ago]      -- means "up to 12:45"
[up to ]      [ 2h] [from now] -- means "up to 17:45"
[later than ] [ 2h] [ago]      -- means "starting from 13:45"
[later than ] [ 1h] [from now] -- means "starting from 16:45"

Be aware however that all UIs like this can raise localisation difficulties due to different word ordering and the nuances of describing time periods in different languages, if that's an issue for this particular application.

  • That's nice. Assuming that report filters will be created rarely, then saved for further usage, I think one more dropdown for date/time won't be an issue. What about localization--though this app is supposed to be used only in Russia, it's not an issue. – Alex Salauyou Aug 14 '15 at 16:24
  • Yes, localisation is a potential issue. However, many email applications and file managers use a similar UI for searching for files and emails, and are available in many different languages. So I presume they've managed to overcome those issues somehow... – calum_b Aug 14 '15 at 16:27

For controls used rarely, explicit is better than implicit

  • If this widget were being used 100x a day, the answer might be an expert interface where the user can enter values like 10h8m, 1d23h5m etc.

  • But, this is not your use case. You have stated that this widget will be used very rarely. In this case, it's much more important to make the interface clear than to make it fast.

  • Here's an approach which uses a combination of explicit controls, labels, instructions, default values, and confirmation to ensure that users understand how to use the widget and what the result is:

enter image description here

  • what about direction of shift (+/-) and entering absolute date/time? If it was a textbox, it could be applied for both absolute or relative value. – Alex Salauyou Aug 14 '15 at 17:56
  • anyway, I agree that explanation message is important. – Alex Salauyou Aug 14 '15 at 17:57
  • Hi Sasha. There are much faster ways to do this than drop downs... For example you could bind ctrl-h, ctrl-d and ctrl-m. But, like using the shift key, these are all not clear to the user so I think this would be sacrificing true usability for a control that is used rarely – tohster Aug 14 '15 at 18:09
  • Tohster’s answer is excellent and points in the exact right direction. Yes, if it was a textbox, it would be more compact and, maybe, flexible – but it also would be much harder to figure out what settings are available, and how to input them. You’d need a help syntax. Which means it’s for power users. Which means it suits use cases where it is constantly used. Which is not the case. If you want a great solution to your case, follow tohster’s advice. If you want to build the most flexible input feel free to do that – but be aware that it very likely will not be the best solution for your case. – Christian Aug 17 '15 at 12:15

I think its a hard question to form one answer to.

Pure theoretically, I'd suggest not to rely on the user to know these abbreviatons like h,d,s,... or at least try to lower some cognitive load by explaining the use cleary (as Don Norman likes to call it, put the knowledge in the world instead of in the head). From the moment you introduce a syntax (like +/-/d/h/m/s/...) you should be very aware of the caveats this brings.

If you'd ask me, i'd add a range slider instead, so it behaves something like this crude example:

enter image description here

Perhaps its best to A/B test this with a few people and watch whatever comes more naturally. Also interesting to know the whys and whats:

  • why do you want to use the "now" as your base, as the future is unknown at that point?
  • What happens when you want to select a range of dates?
  • Why do they want to set a range in such a fine granularity?
  • What is the exact problem that needs to be solved?

Answering these questions first could perhaps help you discover a better answer :-)

Kind regards

  • Thanks. 1) I thought about slider, but it's not an option because in common use case there will be many conditions in report filter, and I need to show them in a very compact way. 2) Very often user would need to see events happened in last X minutes or last Y days, so choosing "now" as starting point is very natural. 3) absolute date/time values would be input as is, i. e. later than: 15:45, there is no problem with that – Alex Salauyou Aug 12 '15 at 17:18
  • What about this syntax--the tool I'm working on is not for wide range of users, it is for enterprise system (users will be teached). Anyway, I'd like to introduce as natural UI as possible. That's why I'm asking this question to you, UX experts: do you see such syntax enough obvious and easy to understand? Or you feel confusing and I need to think about another option? – Alex Salauyou Aug 12 '15 at 17:28
  • Hi, personally I don't really belief in the "enterprise user" as the is still a human being you should still try to accomodate to help the user out as much as possible. To me a syntax asks a serious learning curve, so I would avoid it and try to replace it with some fixed input fields like selection boxes (kinda like access does to help you form a query on a table). – Xabre Aug 14 '15 at 10:57
  • 1
    I agree with Xabre's solution. If the feature is rarely used, you could hide the entire slide in a drop-down or accordion panel. Either end of the slider could be set to Now, though not both at the same time. For power users, the range indicators, (i.e. " from 13h15") could be input boxes, so the user could slide or type. The advantages are that the user sees the time span duration change in real-time, and gets feedback about both absolute AND relative times simultaneously. – Phillip Quintero Aug 17 '15 at 17:12

I suggest abandon using +/- way of doing this, but try to use start date and end date approach, but with relative dates:

[start date][2d ago][end date][now] --> means "analyse last 2 days"
[start date][undefined][end date][3h ago] --> means "analyse all data that arrived not later than 3 hours ago"
[start date][2d ago][end date][3h ago] --> means "analyse data that arrived later than 2 days ago but not later than 3 hours ago"
[start date][2d ago][end date][5h from now] --> means "analyse data that arrived later than 2 days ago but will not arrive later than 5 hours from now"
[start date][2h from now][end date][undefined] --> means "start report 2h from now and keep getting data (?)" 

Are you sure user needs this future relative time? Maybe you could abandon this to make the whole thing more clear?

  • Your idea to use range instead of ≥ and ≤ is very good. – Alex Salauyou Aug 15 '15 at 14:42

I think your current approach carries a hefty cognitive load. You're anticipating the user being able to understand:

  • That the scale is relative to the time right now
  • That using a + or - alters the start or stop based on the time right now
  • That they can specify time in days, hours and minutes with d/h/m

Using your system, if I wanted a report that ended yesterday at 03:00 and right now it's 11:40 I would say: [Earlier Than] [-1d8h40m]. And that took me half a minute to calculate in my head.

People using your system might need very precise control, but humans are not very good at calculating differences in their brain. For example, telling you I need a project completed in 18 hours requires more cognitive load on your part to figure out exactly when I need it done. It would be easier for me to just tell you I need a project done at 06:40 tomorrow.

So for your system, let the user pick the day, hour and minute a report needs to start or end. It could be as simple as 3 dropdowns, one for each category (with minutes broken into 10 or 15 minute increments), and then an option to toggle whether it's when a report starts or ends. And you could further simplify by having the 'day' field default to the current date or even text that says 'today.'

  • "if I wanted a report that ended yesterday at 03:00 and right now"-- you just enter [earlier than: ][ 2015-08-12 3:00]. As I mentioned, my issue is about representing relative time only. – Alex Salauyou Aug 14 '15 at 16:10

Your Answer

