filters should be associated with views rather than sub-views

[rade]

I was seeing too many / too few containers when switching between the three Container sub-views ("Container", "By DNS" and "By Image")... until I realised that my selection for "show system/application/both" and "show stopped/running/both" was being apparently being reset when switching sub-views... until I realised that it was in fact saved/restored per sub-view.

I suspect I am not the only user that finds this counter-intuitive. When I tell scope, say, to "show stopped containers", I expect it to apply that selection across all container views.

[davkal]

Let's hear some opinions. For me the current behaviour is normal. But I, too, found myself clicking the same options across sub topologies. So maybe that should change.

[peterbourgon]

Do we expect metrics-on-canvas selectors to persist across views? Given the metrics are different across views, I think the answer has to be "no". Since the UX for metrics-on-canvas widgets is roughly identical to the filters (same place on screen, same interaction model) I think they need to have the same behavior. So I'm with David, the current behavior is less surprising than the proposed alternative.

[davkal]

Do we expect metrics-on-canvas selectors to persist across views?

There is a notion of a metric type. If a metric of similar type is found in the new topo, it's being applied.

[rade]

Do we expect metrics-on-canvas selectors to persist across views?

Across sub-views, yes.

Given the metrics are different across views

They are the same across sub-views.

Since the UX for metrics-on-canvas widgets is roughly identical to the filters

That may not be true, despite...

(same place on screen, same interaction model)

[peterbourgon]

There is a notion of a metric type. If a metric of similar type is found in the new topo, it's being applied.

Interesting. OK. I'm for consistency, so if this is happening with MoC, then it should happen with the filters, too.