[Windowing] Evaluate and design for multi-window usage

VWoeltjen commented 8 years ago

Design for usage of Open MCT (or WARP) in a multi-window configuration, intermixed with other operational tools on a densely-packed large desktop display typical to the mission control environment.

Areas of specific concern here include object synchronization between windows, removal of browser chrome, and time conductor behavior across windows. There will be technical constraints here, but also need to understand what users would want independent of those constraints.

Road map item; check with @RCarvalhoNASA and @Costigan for more specific use cases to be satisfied here.

charlesh88 commented 8 years ago

Notes from Hangout discussion 11/08/16 Mark, Robert, Andrew, Victor, Charles

Current Use Cases

Robert:

IRIS, 4 screens with 5 alternate views (toggle between desktops) all have telem displays. Goes back and forth between all of those. All ITOS windows.
Each monitor and each desktop on each monitor is thought of as a "display".
Plots only show history while running, so they needed to be up and running. If WARP can backfill with historic data (which it will) then this would be solved.

Mark:

LADEE is the same. 4 screens, 5 workspaces. Mixture of tools. Left logged in. Switch between workspaces to go to "offscreen" displays/other pages - fastest way to get to other pages without having to wait for slower "repaint".
There was a Linux util to reconstitute window layouts, but LADEE didn't use it. Goddard use this.
Most other workstations had 2 monitors, some 1.

Options:

Not an option for WARP to be everything.
2 monitors setup is planned
- WARP could be one monitor, other stuff in other monitor.
- Or, intersperse WARP with other apps in windows.

Object sync: yes, edit an object in one window

Time Sync Across Windows

Mark:

TC syncs across multiple windows.
- Victor: doable, but there might be latency, like a second or so before you'd even see the wait spinner.
- Andrew: we should be able to implement an event-based system.
Mark: RT ops is the highest performance requirement case, going back to RT from historic manipulations is important that that is fast. Historic syncing doesn't need to be as performant.
Possible to create one or more temporary plot/views that is disconnected from the TC.
All layouts sync to TC, but have a gesture to display a plot or view that is disconnected.
TC needs to be able to be collapsed by default when launching a view in a new window.

Charles: do we want sync for historic queries too? Mark and Robert:

Same as RT would be Ok, sync 'em up in v1.
Want to create a new TC-disconnected view and persist the TC and its timeframe, zoom, etc.

Mark: I feel strongly that we should look hard at WARP as an application in Electron or something. Andrew: what questions would need to be answered here? Mark: what would be different if WARP were in an app instead of the browser?

If Electron, may not need to implement multi-window time sync in Chrome, there isn't a requirement.
Launch external apps.
Should be a high degree of code sharing with web-based version.
Look at closing the view area to have just tree or just TC.

Next Steps

Charles to sketch multi-window UI, creating temp popup TC-disconnected views and closing the view area to have just tree or just TC.
Andrew: dive into Electron evaluation.

akhenry commented 7 years ago

Notes from hangout 11/30

Results of Electron prototyping and investigation shared with group. Summarized in google doc with link distributed to group.

Next Steps

Evaluate how WARP can best meet user needs, whether that's a multi-window approach that intersperses WARP windows with other tools, or a dedicated WARP screen with other tools in other windows, etc.

Mark and Robert to take a look at tools needed alongside WARP, and how they might be configured and used by users.
Get some users at a terminal, and find out what tools they need, how they would use them, and how WARP fits together with other tools.

RCarvalhoNASA commented 7 years ago

Here are some thoughts on what other tools users will be running alongside WARP, who might use them, and how much space they might take. My unit of measure for space (lm) is a large monitor, 20-25" and high resolution. Keep in mind that the WARP and other windows can be spread across virtual monitors, not just physical ones.

All Procedure tool 0.5lm All chat tools 0.25lm All shift log tool 0.25lm Drivers VERVE 1lm Any Science LabView 1lm Planners Planning Tool 1-1.5lm RTSci & Planners (perhaps others) Map tool 1lm

Note that some of the above may be in WARP from an application, but are broken out for particular note. Similarly, interested users would use on the order of 0.5lm for the timeline, and then anywhere from 1-12lm for telemetry plots and displays within WARP.

Costigan commented 7 years ago

All have Email (let’s be real … or they have room at their console for their personal laptop)

Many have Verve light (web 3D client) Map (I think most users will have this, not just RTSCI, Planners and a few others)

Some have Jira (or some other issue tracker, not usually for software issues but for ops issues)

Command also has ITOS Ground station schedule & contact info

Keep in mind that some of the functionality in warp could potentially benefit from being windowed.

From: RCarvalhoNASA [mailto:notifications@github.com] Sent: Wednesday, December 07, 2016 1:16 PM To: nasa/openmct Cc: Shirley, Mark H. (ARC-TI); Mention Subject: Re: [nasa/openmct] [Windowing] Evaluate and design for multi-window usage (#1289)

Here are some thoughts on what other tools users will be running alongside WARP, who might use them, and how much space they might take. My unit of measure for space (lm) is a large monitor, 20-25" and high resolution. Keep in mind that the WARP and other windows can be spread across virtual monitors, not just physical ones.

All Procedure tool 0.5lm All chat tools 0.25lm All shift log tool 0.25lm Drivers VERVE 1lm Any Science LabView 1lm Planners Planning Tool 1-1.5lm RTSci & Planners (perhaps others) Map tool 1lm

Note that some of the above may be in WARP from an application, but are broken out for particular note. Similarly, interested users would use on the order of 0.5lm for the timeline, and then anywhere from 1-12lm for telemetry plots and displays within WARP.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/nasa/openmct/issues/1289#issuecomment-265575728, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AH0ZVmQaM57mDog3SBnXX9oSFRGRwRgwks5rFyIagaJpZM4KgibE.

nasa / openmct