> 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:
> 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
--
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/kiali-dev/CAGUuq3WTgw-hC2m25uATr3Po6UBmAjEEe9xqZN3h_k1OQ32fAQ%40mail.gmail.com.