Time controls refactoring, keep several states or not?
Joel Takvorian
> I think the current changes, that put the time controls look more global than how it was before, should involve some changes in behaviours too. I've always been advocating decoupling time between graph and metrics because the use cases are different and I still think it is better in terms of page context, however now, it is harder to advocate because the time controls looks unique.
> Hence I'm wondering if we could imagine a solution to make it visible, somehow, that the time controls are referring two different settings, one being for historical data sets and one for "snapshot-like" data sets. Not sure yet how we could do that.
- Jay:
> Today: Overview, Graph, Detail-Overview, and Detail-Traffic are tied to timeRange-1 and the other Detail-* tabs are tied to timeRange-2.
> timeRange-1 has a default of 1m and does not allow custom ranges.
> timeRange-2 has a default of 10m and allows custom ranges.
> It's confusing but it makes some sense as typically Overview and Graph are looking for near-term issues and Metrics are interested in longer, trend-oriented views. Logs could go either way but get tied to metrics because, I think. locality and the need for a custom range.
> To be perfectly honest, I'm not sure users have noticed very much and may simply change it for the page/tab they are on based on need. As suchm I'm not really advocating a change. But if we were to make a change I's suggest maybe doing the following:
- Give Overview its own time range (maybe change default to 5m).
- Give Graph its own time range (keep default at 1m).
- Give Detail its own time range, allowing custom, and apply it to every tab (keep default of 10m).
- Fix the tooltips for each to indicate more specifically its scope.
> If nothing else, I think with the current time controls we could update the tooltips to be more specific to the current scopes. This could/should be done in this PR.
- Lucas:
> About this discussion, as I commented in previous issues, I don't like and I don't see that user needs to keep two different states.
> Sorry, but not, if there is a common component, the main reasoning is to keep that state in all possible scenarios.
> But, we have two different controls here, one that admits custom time ranges, and other that only support duration.
> So, it's logical that custom time ranges can be propagated.
> In any case, we are discussing if the user needs to perform one extra click or not (i.e. I select 5 minutes in the graph, I move to a metrics page and I need to change to 10 minutes).
> I don't see a good reason why duration can't be shared here.
> Yes, semantically perhaps in that tab I want to see a long duration (or not).
PS: We can also talk more about this in today's watercooler
Joel Takvorian
To recap the problem, short durations are generally a good fit for pages like Graph, because the shorter it is, the most accurate it is to show the current health of the applications. On the other hand, long durations are a better fit for pages like Metrics because they represent data over time. If we take the example of a 1-minute duration, it is a good default duration for graph but a terrible default duration for metrics because you would see perhaps 3 datapoints only, more or less.
That's why we have those two states.
I believe that presenting good default values is an important part of having a user-friendly tool, as well as avoiding having the user reconfiguring the settings every time he/she switches from a page to another, so I think it's preferable to keep having these two states. However it is clear that it can look confusing / buggy if we have this time component looking unique but switching for a state to another while the user navigates in Kiali. So we should consider the options that we have.
What was suggested at this point:
1. As Jay suggested, keep the states (two states? or even more? that's another question) and use tooltips on the time controls to differentiate them
2. Keep the states and use something more visual to differentiate them (a small icon? some light background color? a label?)
3. Keep the states without any differentiation (ie. do nothing)
4. Forget about the states, to have just a really unique component.
Personally I would like to explore option "2." and see if we can have something easily understandable in that way. I think option "4." would damage the user experience in the end.
Edgar Hernández
I don't think a refactor is a good reason for a change in behavior.
--
You received this message because you are subscribed to the Google Groups "kiali-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kiali-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kiali-dev/CAJo5TFnU6ZMff6aCGOZks7EsYfkqurPDWopkwyz3MvDvzB5a2A%40mail.gmail.com.
Lucas Ponce
IMO, I think we should keep the states.
I don't think a refactor is a good reason for a change in behavior.
To view this discussion on the web visit https://groups.google.com/d/msgid/kiali-dev/bebe5098-9b8d-9b6f-fc91-1b5e608f88aa%40redhat.com.
Jay Shaughnessy
I also think we need the two states, if not three (overview, graph, metrics/logs). I have suggested new text for the tooltips in Lucas' PR that I think can help the situation. A visual difference could be useful and one possibility would be to change the custom time range to be consistent with the look used in graph replay.
To view this discussion on the web visit https://groups.google.com/d/msgid/kiali-dev/CAGUuq3WTgw-hC2m25uATr3Po6UBmAjEEe9xqZN3h_k1OQ32fAQ%40mail.gmail.com.