[Time Conductor] Support durations in fixed mode

[akhenry]

Notes from discussion between @charlesh88 @larkin and @akhenry

Fixed and follow modes should both support specification of durations. This requires some additional design and support in the UI. A number of options were discussed including:

1. Supporting free-text input of durations such as "00:10:00", "ten minutes", "01:00:00", "one hour" etc.
2. A menu that is made available when the text input is focused that gives some default options such as "last five minutes", "last hour" etc.
3. A separate menu similar to the session selector menu in the design that allows specification of start and end deltas simultaneously.

This relates to #1182 (comment) . The approach taken to support deltas beyond 24 hours should be the same used to support durations in fixed mode.

[larkin]

Need to break apart into subtasks for and decide which portions to implement in Robinson.

[larkin]

Now need to break into subtasks and look for what to implement in Roddenberry.

[akhenry]

The first thing we need to do is improve duration support to allow for durations > 24 hours. This is achievable in Roddenberry. This will lead naturally into 2. as it will rapidly become frustrating specifying things like multi-day durations in text. I think we may need to do some design for specifying arbitrary relative time spans of days, months, years, etc.

[charlesh88]

Unpack this for some design evaluation and enhancement.

[charlesh88]

From chat with @akhenry and @larkin 1/18/17
Main idea here is to be able to lock the relative duration to the current zoom setting. So, if current zoom is 24 hours, changing either the Start or End datetime also changes the other end of the bounds to maintain a 24 hour duration. Include a toggle button with locked/unlocked icon to the right of the zoom slider that toggles this.

To support this well, the zoom slider should do the following:

• Display its zoom setting more granularly, like 24 HOURS, 36 HOURS, 48 HOURS, 1 DAY, 2 DAYS, etc. A dropdown menu adjacent to the value between the slider itself could be a great way to do this. Having snap-to values built into the slider may also be a good way to do this.
• A more advanced feature would be to let the user enter values directly into the current zoom value as an input field.

@charlesh88 to sketch UI for this.

[charlesh88]

Sketches uploaded to Drive at https://drive.google.com/a/nasa.gov/file/d/0B0v27OM1JkSedVQ2b1dFRHdWalU/view?usp=sharing page 65.

@akhenry Let's review together when you get to this. @larkin please also have a look.