View large/preview should more clearly identify independent time context

[davetsay]

Summary

If an object has an independent time context, and a user navigates to a view large of that object, the independent time context is correct, but is it not clear that the view is a time context that is different than the current time conductor's.

Expected vs Current Behavior

View large should indicate more clearly if it is displaying an independent time context.

Steps to Reproduce

1. Start in realtime mode in the time conductor
2. Create a plot and add telemetry
3. set an independent time context on the plot
4. set the independent time context to fixed time
5. go to edit mode on a different object
6. Click on the plot object with the independent time context, to view large
7. observe the display range is correct, but it isn't easily known this display range comes from an independent time context

Environment

• Open MCT Version:
• Deployment Type:
• OS:
• Browser:

Impact Check List

• [ ] Data loss or misrepresented data?
• [ ] Regression? Did this used to work or has it always been broken?
• [ ] Is there a workaround available?
• [x] Does this impact a critical component?
• [ ] Is this just a visual bug with no functional impact?
• [ ] Does this block the execution of e2e tests?
• [ ] Does this have an impact on Performance?

Additional Information

[davetsay]

@charlesh88 , please have a look and let me know if you need more clarification on what the issue is. Reported by peter, who was reported to by real users.

[mudinthewater]

@charlesh88 There's also a design issue here, more so than just the above. If a user changes an independent time conductor time range, it makes a persistence storage change to reflect that change. This means the following scenario is likely to occur (frequently, depending on the size of the team):

1. User1 will change the independent time conductor range on a view in a display layout (or elsewhere).
2. User2 will load a different display layout without knowing that the change occurred.
3. User2 will notice something isn't right and will:
   • Change the time back/turn it off
   • Send an email/write an ISA that something is wrong
4. User3 might then get the new time that user2 changed it to.
5. Meanwhile user 1 sent a link out to 50 people to the view they made with the independent time conductor change, without knowing that user2 or 3 or someone else already changed it.

Now there are links with multiple users all assuming they're looking at the right time when in reality they've all be wiping each other's changes in the persistence storage.

This scenario is the exact reason I disable filtering via the inspection window in all IEMS deployments.

I believe that instead all independent time conductor values should be ephemeral, and labeled as such. There's no confusion that way any more, and one user using it will not affect every other user.

[davetsay]

@akhenry , @shefalijoshi , @charlesh88 , please see above comment. We should discuss this.

[akhenry]

@mudinthewater The scenario you're describing sounds really frustrating, and we need to address it.

The existing behavior is designed to meet use cases where users specifically want persistent, independent control of time bounds for certain components within a layout for data that changes infrequently, such as images, for which users always want to see more history than the rest of the display.

Perhaps if the persistence of the independent time conductor was more context-sensitive? eg. what if when you applied ITC settings to a plot they only applied to that plot within that layout? Anywhere else that you use the plot will default to the relevant parent time context. Would that help in this situation?

[akhenry]

The current behavior of displaying the independent time conductor when the user is navigated to a single plot is extremely confusing. Users may be rightly confused about which conductor settings are in effect, and it could cause a serious situational awareness problem. Making the ITC context-sensitive would at least remove this particular problem as it would no longer apply to a single plot in isolation.

[mudinthewater]

Perhaps if the persistence of the independent time conductor was more context-sensitive? eg. what if when you applied ITC settings to a plot they only applied to that plot within that layout? Anywhere else that you use the plot will default to the relevant parent time context. Would that help in this situation?

@akhenry That would break the project use-case as well. The projects create links to specific views and time ranges (and sessions and hosts etc) throughout pre-launch and operations; these links are expected to always produce the data that was linked. Any ITC settings being persisted break the links that the project has been creating for 4+ years now - we can no longer trust the shift logs. This is especially problematic when comparing pre-launch tests to launch data. Any scenario where a previously-generated link can be invalidated by a TBD user's future action creates an operational risk, because the projects expect the links to be deterministic.

[charlesh88]

Some initial design thoughts: we should carry through the Independent Time Conductor and the main Time Conductor when in Large View. Changes to both elements should persist when exiting Large View.

[akhenry]

Any scenario where a previously-generated link can be invalidated by a TBD user's future action creates an operational risk, because the projects expect the links to be deterministic.

I understand now, thanks for the feedback.

@charlesh88 We need to reconcile these requirements somehow. VIPER users want a longer look-back for some display layout elements (eg. images) than the main time conductor bounds by default, which requires persistence to be useful. In its current implementation though this breaks the determinism of time settings in URLs.