Windowing System(s) Master Ticket

[aeschylus]

We had a longer discussion today about some of the outstanding design, implementation, and sequencing concerns pertaining to the windowing system(s). We uncovered areas of remaining design and implementation fuzziness, as well as sequencing questions. Some aspects were clarified enough to conclude that we should continue with the "roll our own" spike in support of an overlapping windowing system, and leave the react-grid-layout PR open for consideration for now.

High-level Non-design-specific Requirements

This list represents tasks or scenarios that need to be addressed by the windowing system. They should be stated in such a way that, as far as possible, they make no reference to a particular system or implementation unless the user(s) specifically asked for them in interviews.

• (a.) Add windows to the workspace
• (b.) Compare window content to content of other windows
• (c.) Provide reasonable responsive behaviour ("mobile friendly")
• (d.) Remove Windows from the workspace
• (e.) Find a specific open window and focus it
• (f.) Full-screen a window
• (g.) Resize windows (note that this can happen in any of the different paradigms we've described, the difference being the behaviour of surrounding windows in response to resizing a window)
• (h.) Move windows in relation to each other
• (i.) Synchronize behaviour between selected windows
• others...

High-level prioritization

• Implementation scenario that handles an embedded view 1-up (relative full workspace "layout")
• Implementation scenario that handles an embedded two-up (relative full workspace "layout")

Existing Tickets and Resources

Areas of Clarity

Free-form Workspace

Spike PR (Demo)

• We want some mode that allows arbitrary dragging and resizing of windows
• In free-form, adding a window is well-specified
• Adding multiple windows is well-specified
• There is no change to the layout in response to viewport changes Adjust workspace layout when user's viewport changes (responsive behavior) #1706

React-grid-layout Affordances

Spike PR (Demo)

Areas Needing Further Design

"Mosaic" mode

Spike demo

Getting In and Out of Workspace Modes

Relationship between "Arrange in columns" free-form mode option and "Column grid" mode

Slot-based Comparison Builder (? is this just "Mosaic mode behaviour"?)

Implementable Plan

Explicitly Out of Scope (until further review)

Minimizing windows ProjectMirador/mirador-design#36

[jvine]

Proposed approach is to provide 3 user-selectable workspace modes:

1. free-form: elastic workspace beyond the Mirador viewport; windows can be overlapped
2. grid: workspace is horizontally constrained but scrolls vertically; windows can be positioned with some flexibility within a grid layout.
3. mosaic: workspace is constrained to the Mirador viewport; windows are tiled to fill the space completely.

Mockup

These frameworks will provide the default behaviour in each mode:

1. our own free-form implementation
2. react grid
3. react mosaic

Design tasks:

• Modify workspace tools menu to provide affordance to select modes and mode-specific features
• Determine default settings for grid mode
• Design transitions from one mode to another