Let the date control swap between text and selector modes?
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	epriestley
	May 4 2015, 5:03 PM

Description

Not sure if this is a good idea or not, but we have have two different type of date selection controls right now. Some look like this (for example, in Maniphest task queries):

Created Before: [_______]

Some look like this (for example, in Calendar queries):

Starts After: [√] (1 v) (May v) (2015 v) # [1:12 PM]

The major advantage of the first control is that you can use relative dates, like these:

30 days ago
now
last week

In particular, you can save a query like "30 days ago .. now" and always see the last 30 days of activity. You can turn this into a dashboard panel, etc. Effectively, this is typeahead functions for date selection

However, the second control is better in many cases and probably better for new users.

It would potentially be nice to combine these controls into a single control with a mode selector:

Starts After: [√] (1 v) (May v) (2015 v) # [1:12 PM] [>_]

                                                      ^
                                                      |
                                       Switch Modes --+
                                                      |
                                                      V

Starts After: [30 days ago_________________________] [##]

Maybe reasonable?

Does this seem good/useful/desirable?
Is this unreasonably complicated?
Is there a better way to present this control without making it fully modal?
Is there a better way to give users access to the relative times / time functions without swapping the control mode?

Revisions and Commits

rP Phabricator
	D13018	rPc2351208c0e5 String inputs should be validated and replaced by "today" values.
	D13010	rPe8dbdedbd490 Convert date control dropdowns to an input for date

Related Objects

Mentioned In: rP9d6911866432: Add a discovery format hint for date fields in SearchEngine UIs
D18942: Add a discovery format hint for date fields in SearchEngine UIs
T5296: Allow user-defined date format
D12673: Manage date control enabled state as part of DateControlValue
Mentioned Here: T1562: Build "Facts", an ETL pipeline and charting application

Event Timeline

epriestley created this task.May 4 2015, 5:03 PM

epriestley raised the priority of this task from to Normal.

epriestley updated the task description. (Show Details)

epriestley added a project: Calendar.

epriestley moved this task to Future Work (v2+) on the Calendar board.

epriestley added subscribers: epriestley, chad, btrahan, lpriestley.

epriestley mentioned this in D12673: Manage date control enabled state as part of DateControlValue.May 4 2015, 5:08 PM

A third possible mode, which only makes sense on some controls, would be a "duration" mode. So you'd have:

Start Time: 1 May 2015 3:00 PM
  Duration: 1 Hour

You could swap the second control into "selector", "text" or "duration" modes.

Maybe "duration mode" should be a dropdown, and we should parse durations out of "text" mode.

So you could either swap to "Duration Mode" and select from something like:

15 minutes
30 minutes
45 minutes
1 hour
1 hour 30 minutes
2 hours
3 hours
4 hours
6 hours

..or type "4 hours" into the text mode?

Kinda complicated.

After some discussion, the problems we want to solve are:

Retain present number and preferably fewer date controls on advanced search forms.
Retain capability to set relative time and make that available anywhere we have date controls.
Set a default duration of 1 hour on all new events.

One possible set of solutions is:

Actually enforce a 1 hour default duration when creating a new event.
Merge the "relative time" and current date control into one control with two states, toggled by a button (most useful when building saved queries when control awkwardness is a one-time inconvenience).
Time element of the date control can be a typeahead, where the "ends" time defaults to 1 hour after "starts" time. Changes to the "starts" time will update the "ends" time control after any "starts" time changes except if the "ends" time has been touched, in which case we could do something fancy like try to guess what the user is doing, or we can just assume that something complicated is happening and let the user enter "ends" time manually.

Alternatively or possibly in addition to the last point, have a duration dropdown that has a separate "active/not active" state which, when active, auto-updates the "ends" time. This control can default to an inactive state. This way we default event to 1 hour, but if some more complicated time selection is about to happen, activating the duration control can be deliberate and can simplify some cases. When this control is active, changing either the "starts" or "ends" time should probably update the other control to fit what the "duration" control is dictating.

So the chain of authority would be: duration -> start time -> end time.
(Active duration state will dictate what the "starts" and "ends" time will be if one or the other is updated, "starts" time will update "ends" time if duration is active or if the default 1 hour duration is still in force)

You could swap the second control into "selector", "text" or "duration" modes.

@epriestley is it important that all three modes are represented in this control? Currently, when tabbing to a month or day or year dropdown in the date controls, typing "J" will select "June", so there is a pseudo-text mode. Or am I misunderstanding what you're saying?

Here's a more concrete description of the problem. Overall, there are several use cases for these controls:

Select a Specific Date: The user wants to select a specific date they have in mind. For example, they want to schedule a lunch on Friday at 1PM. I think this is the primary (and overwhelmingly most common) use case for fields like "Start Date" in Calendar → Create Event, or "End Date" in Countdown → Create Countdown. I think this is a relatively common use case in all places where these controls appear.
Select a Relative Date: The user wants to select a relative date like "1 week ago", usually for reporting purposes to answer a question like "What did my team complete in the last week?". This is a secondary use case in query controls like Maniphest → Advanced Search, but I believe it is an important one. In the future, as we improve reporting and charting capabilities in Projects and Facts (T1562), I anticipate the importance of this use case increasing. For example, users are likely to want to be able to create charts which show the last week of activity, and have the charts automatically update over time so they can view the page every day and see recent activity. I think this use case is not important in many places where date controls appear, although I don't think it would be harmful to support it anywhere (for example, setting a Countdown to "20 minutes from now" is probably very rare, but could occasionally be useful).
Select a Duration: The user wants to select a duration. I think this is the primary (and overwhelmingly most common) use case for "End Date" in Calendar → Create Event: when using this control, the user very often wants to select a specific duration relative to the "Start Date". This use case is not important in many places where date controls appear, and meaningless or irrelevant in some cases.
Select a Specific Date by Pasting: The user has a specific date on their clipboard. I think this use case is very rare.

I think the hard requirements are:

Report-related date controls (Maniphest, Facts) must allow the user to set a relative date ("1 week ago") or a specific date ("2015-01-05 12:34 PM"). Particularly, I think "show a chart of the previous week's activity" is too important a use case to discard, and will be the primary use case for date ranges on charts. I think it is a secondary but important use case in Maniphest today.
All other controls must allow the user to set a specific date (this is sufficient to accomplish everything else, and necessary in major use cases for all other controls).

These product design constraints aren't hard requirements, but I think they are important to good product design:

It should always be obvious what the state of a UI means by looking at it, without specialized knowledge of how the controls work. For example, we should never show (or allow the user to select) two conflicting values for a single date, such that they need to know the secret rules for which one we'll actually use.
All else being equal, having fewer types of controls is usually better than more types of controls, so users have less to learn. This is an issue of balancing consistency (fewer new things to learn) vs specialization (in some cases, a different control may be much better at a given task).

The current solution satisfies all these requirements. It is:

Date controls which don't need to be able to specify relative dates use the multi-input date control.
Date controls which do need to be able to specify relative dates use a text field.

However, it has some drawbacks:

The text field control isn't very user-friendly, and is much worse than the multi-input control for selecting a specific date. This is the primary issue I'd like to improve.
You can only select a duration by selecting a specific date, which often requires a lot of inputs. This is a minor issue and specific to Calendar, but it would be nice to improve it.
You can't select a specific date by pasting in most controls. I think this doesn't matter, but a solution which supports it would be slightly better than a solution which doesn't.

It would be nice to find an approach which satisfies the hard requirements while reducing the drawbacks. Modal date controls might be one such approach, but they might also not really be a very good solution to the problem.

@epriestley is it important that all three modes are represented in this control? Currently, when tabbing to a month or day or year dropdown in the date controls, typing "J" will select "June", so there is a pseudo-text mode. Or am I misunderstanding what you're saying?

It is not important that all three modes be represented. I think the only hard requirement is that the user must be able to select a specific date (this is sometimes required, and being able to do this is sufficient to select a duration). The current approach is sufficient to address this requirement.

Because I believe that this control is very often used to select a duration, I suspect we can improve the experience by finding an approach which makes duration selection easier, while retaining the ability to select a specific date. Some examples might be:

Changing the control itself or the control behavior in some way (like making it update automatically, or making it modal) -- I think many calendars do this.
Reducing how often the user ends up here with the wrong date (for example, by making most event creation happen through other UIs where the start time and end time are implicit, e.g. dragging on a visual UI) -- it looks like Google Calendar does this.
Removing the field entirely when the user is first creating an event, and just automatically setting end date to start date + 1 hour and letting them update it later -- it looks like Facebook does this.
Other approaches I haven't considered.

Among these approaches, one possible approach is a modal control with a "duration" mode, a "selector" mode (like the current specific-date input), and possibly a "text" mode (like the current relative-date input).

If we did go down this path, and the control had "duration" and "selector" modes already, the value of having a consistent control might be high enough that it would make sense to let it swap into "text" mode too, and let the user enter "3 months ago" or paste a date. These use cases are silly, not important, and very rare, but they don't seem actively harmful, so I can imagine a solution where we let the user swap to a text mode primarily to keep the control consistent across applications. Allowing a text entry mode for "End Date" might be more confusing than I think, and the control might actually be easier to use with fewer modes. Or we might not use a modal control at all, and then it would be irrelevant. Or the best UI for choosing a duration might be significantly different than the best UI for other use cases, such that the user clearly needs to learn two different (good) control instead of just one (consistent, but not-so-good) control. Any of that is fine and would lead to an "End Date" control with no text selection.

epriestley mentioned this in T5296: Allow user-defined date format.May 22 2015, 3:36 PM

Possible way forward is reducing the number of controls in the date selector to three.

date input (possibly customizable format) that allows user to type in a relative date such as "30 days ago" or "tomorrow"
calendar button that allows for click selecting a date
time input (also possibly customizable format) that allows user to type in a relative time such as "3 hours" for duration

This will address the use cases of creating an event and setting a relative time on a search query. Still need to think through some of the interactions and the javascript involvement, but mostly this seems to reduce the number of controls we need.

lpriestley moved this task from Future Work (v2+) to Runners Up on the Calendar board.May 22 2015, 4:56 PM

lpriestley moved this task from Runners Up to Unprototype (v1) on the Calendar board.May 25 2015, 6:32 PM

lpriestley added a revision: D13010: Convert date control dropdowns to an input for date.May 25 2015, 8:49 PM

lpriestley added a commit: rPe8dbdedbd490: Convert date control dropdowns to an input for date.May 25 2015, 9:02 PM