It appears that when zooming out on the flashtimeline module in 4.x the timerange is anchored on the endtime and the zoom therefore only stretches the timeline into the past. On 3.x the zoom appeared to not be anchored so that the zoom (out) extended into the past and future equally.
It is not easy therefore to expand a window of interest into the future of the present time range.
This issue is compounded as the custom time selection in the timepicker is not prepopulated with the current start/end times in the flashtimeline. So to stretch the window out forward in time requires both the start and end times to be entered, which sometimes requires looking back at the flashtimeline.
On a related note: This also suggests a feature request whether there could be a custom time module that exposes the time above the flashtimeline so that it (the time) can be manipulated more directly (just like 3.x)? - and could be aligned timewise with the flashtimeline to avoid the issue mentioned above.
Im afraid it can not.
Frankly I agree, and I basically wrote the logic for both - The behavior in 3.X was better. For 4.0 users who dont know what we're talking about, in 3.X when you zoomed out it would not change the actual selection you had in most cases (if the timeline changed granularity it would change though). Bottom line was that you could zoom out once or twice and there was no big penalty - only the timeline would change and it would fill in the bars on the left and on the right. In 4.0 the zoom out code cuts corners here and it's a lot dumber and it automatically reselects the entire timeline. Given that more clunky behaviour, moving the right side of the timeline would cause an unwanted change in the events that you're looking at. Therefore the simpler 4.0 timeline generally leaves the right side anchored a lot more. (there are still cases where the right side will snap out but it's now only when the granularity changes)
This is one of those subtleties that got lost - We've realized in engineering lately that a lot of usability things and corners we cut a little, things that we said we'd circle back for once 4.X was out, never actually got circled back for. We're actually now (hopefully) trying to slow down the feature-driven work a little and go back and prioritize usability things like this. The endless pager (aka infinite scroller) is another good example of something in this area.
Thanks for bringing this one up in particular. Hopefully this is one of the things we'll get back in there.
It is still filed in the requirement queue (SPL-18125 for splunkers following along) but its pretty derelict and i think pretty forgotten. You'll appreciate that the first line I wrote in that requirement was "Depending on your perspective, this requirement might seem like a nice-to-have, or it might seem critical core functionality of the timeline."
hey thanks for such a frank response.
I cannot agree more with a move to push usability up in priority. I am finding that the users are very pleased with many of the new 4.x features and starting to get so much more out of Splunk because of them. But there are quite a few little things that have gone missing that really make a difference. If I bothered to write them down the list would be quite long. Unfortunately its the little usability things that get the most focus from the users, especially when they have been taken away.
As I mentioned there could be other ways to improve the situation.
You could expose a custom time picker as a UI module such that the start and end times were always visible.
Or you could prepopulate the custom time in the existing timerangepicker.
We could and maybe should make a little InlineTimePicker module and provide it as an alternate interface. Hey - send your list of usability things to support! or if you'd rather, send them to me and i'll distribute them.
This is something that we too would love to see implemented, or a nclarkau suggested a pre-populated timerangepicker. Thanks for the insight into why it is the way it is currently.