Time travel redesign

[fbarl]

Resolves #2608 and also fixes #2653 and #2658.

Major changes

• Moved Time Travel component to the top of the screen
• Three modes of controlling the time - slider, buttons and text field
• Made pausing part of the time control logic again.
• Got rid of buffering when paused (instead of running a series of nodes delta patches, resuming jumps directly to the most recent state) - fixes Resuming from pause is slower than it needs to be #2653
• Time is always stopped when time travelling, in which case the nodes are fetched through a direct API request instead of websockets.
• Stops polling topologies and node details when paused (websocket connection is still active for the nodes but it's being ignored) - fixes Clicking pause doesn't freeze Node Details data #2658

Pain points

• The API logic is currently very fragile (especially websockets & polling) and it would be nice to do some refactoring there, especially since a couple of PRs require changing some logic there - maybe try using https://github.com/redux-saga/redux-saga.
• Nodes graph layout sometimes gives weird results with caching being on after travelling in time a lot. Caching there actually comes as very useful as it enables us to compare states better, but there should be a certain set of conditions under which that cache should be invalidated, so that we don't have to hit the refresh button every time.

[pidster]

@fbarl Please could you add the final screenshot/mockup of the parts you're implementing in this phase?

[fbarl]

@pidster @rade I'm using this mockup as my main reference for this PR, but I think there will be some tiny changes to the wording and spacing.

FYI @bia is already sketching a new version that we might want to switch to when we add some metadata (thus transforming slider into a real timeline).

[rade]

Here's a particular use case I'd like us to be able to support: "binary search" to pinpoint when the system transitioned from a "good" state to a "bad" state, for example as a result of me discovering some hitherto hidden anomaly now, and suspecting that it may well have been around for a very long time.

I should be able to do that only using the controls, without having to do mental time arithmetic.

Here' roughly how I would envisage that to work...

1. on a coarse-grain view of the timeline, e.g. covering the past 12 months, click on the left most point to get a view of the system at that stage. Let's assume it is in a "good" state.
2. click on a point roughly half-way.
   a. if the system is in a good state at that point, then select the region between that point and the right-most point
   b. if the system is in a bad state at that point, then select the region between that point and the left-most point
3. making the selection in the previous step, changes the timeline to be zoomed into exactly the window selected.
4. go back to step 2; repeat until the resolution of the window is fine enough for me to claim to have pin-pointed the good->bad transition with sufficient accuracy

There are obviously other ways of doing this. The two crucial underlying capabilities are:

• dynamically changing the duration covered by the displayed timeline - i.e. zoom
• dynamically changing the "position" of the timeline, i.e. pan

It's not obvious to me that the new controls support that; do they?

[fbarl]

It's not obvious to me that the new controls support that; do they?

I would say that purely visual binary searching will be very simple to do with the slider I'm implementing in this PR - up to a certain precision. Pinpointing the exact timestamp on a slider will be hard because there won't be any zooming functionality in this version.

Obviously zooming and panning through the timeline/slider will become even more important once we start adding metadata and that's why we're already planning to include it in the UI next iteration. @bia just started working on it, but you can see her initial prototype here. The idea would be that the timeline would replace the current slider and create a space inside it for the metadata. The timeline would be both zoomable and pannable.

[bia]

@rade @fbarl One of the main themes for us to tackle is to make visible 'interesting' moments in someone's history. These can be things like downtime in the system, or anything else that we'd eventually like to display as metadata. But before we get to that point and before we are able to zoom into the timeline to get more granularity, we could address this issue using the metaphor of a 'scan' button on a car radio.

Say that your timeline ranges from 1t - 10t. Maybe interesting things have happened at 1.22t, 1.73t, 3.01t, and 4.00t. In that case, the slider could automatically snap to those timestamps instead of any arbitrary subdivision of your history.

[rade]

Making interesting moments visible in the timeline is no substitute for exploration. There can be all kinds of interesting events/conditions a user may be looking for that Weave Cloud hasn't captured explicitly.

So, make exploration work well first, then add interesting events.

[pidster]

Another way to think about this is the "video editing" metaphor, where a "visible window" can pan and zoom over a line, and the focus can be positioned within it.

-----------[-----o-----]-----------
-----------[----------o-----------]
----------------[-----o-----]------
----------------------------[--o--]
----------------------------[----o]

[foot]

Looks slick! Simple a and clean, nicely done.

Niggles:

• I tried to toggle the timetravel button: after it slides open the panel I assumed I could click it again to slide it away. I had to think about how I could make it disappear again.
• I got stressed by the "busy" cursor that appeared as soon as I started dragging. Maybe show that onMouseUp when stuff starts happening.
• Not a biggie but I'd prefer a "Go!" button next to the textfield, if I'm using it I'm probably making a couple of changes and it feels a bit hectic things changing around as you're trying to enter a value.
• timestamp is truncated a tiny bit for me :).
• Not sure about "live", but can't think of anything else right now.

Future designs?

• Show the date next to the mouse pointer when dragging? Bit of eye flicking there.

[fbarl]

@foot I addressed only your first comment, the rest will be considered in #2677, so I'll move the discussion there.