2019-2-1 Meeting Notes

• Cadence of meetings
• Collaboration tools
• Github
• Confluence
• Email
• Others
• Procedures
• Handling of Minutes
• Contributions
• Proposed Charter (defines scope of WG)
• Hadouken Layouts delivers window management and layout user experience across the financial desktop.  The Hadouken Layouts Working Group provides a steering committee for stakeholders in the project to contribute to and influence behavior, scope, and technical design and architecture.

• Demo
• Planned work
• Known issues

As a first order of business, we think it would be useful to define some of the terms we use in layouts - these are both technical and UX terminology.  

These are suggested terms and definitions.  We’re looking for feedback from the group on the validity and utility before documenting for the working group.  We’re also looking for missing terminology and hope to use this to build ongoing documentation as one of the working group’s functions.

Desktop Service

A singleton process shared across any number of applications that provides some common functionality to the OpenFin environment.  Desktop Services typically provide an API over the OpenFin bus to consuming applications. The lifecycle of Desktop Services is managed by the RVM.  

Snapping

The behavior when the alignment between two windows is automatically completed at the end of a window drag operation.  This includes both moving the windows to be aligned on edges and well as potentially resizing to create edge alignment.

Docking

The behavior of sticking and locking windows together as a group.  

Undocking

Unsticking grouped windows.  Implicit behavior today is to also move windows away from the group when they are undocked - i.e. an “unsnapping” behavior.

Tabbing

Grouping windows as separate tab panels - where only one window is shown at a time. Tabbing behavior can have different:

• Triggers (in Layouts currently, this is dropping  a window into a specific zone applied to all participating windows
• Restrictions on which windows can tab with other windows
• Treatment of tabbed window Chrome,  sizing, and other behavior

Internal UI

UI elements and behavior that are applied from within a participating application, using APIs provided by a desktop service.

External UI

UI elements and behavior applied directly and automatically by a desktop service. (tab strip, preview windows, etc).

One of UX questions we have for the group is what should the approach be on default behavior for docking/undocking triggers.  This includes:

• What should the default behavior be
• How configurable should it be
• What behaviors are valid use cases

Dock on Snap

Windows automatically dock when snapped - current default behavior.  

Dock on Drag Modifier

Windows only stick together when they are dragged with a specific explicit cue from the end user.  For example, dragging while holding a modifier key, or dragging from a specific handle in the UI.

Dock on Region Drop

Dock happens when a window is dropped on another window.  An overlay gives the end user a set of choices (left, right, top, bottom, tab).  Placing a window adjacent to another window would snap it, but not dock.

Dock/Undock on Explicit Action

Adjacent windows are docked and undocked via an explicit user action such as click on buttons in the window titlebar - or specific key commands.  An API is exposed by the service to manage, and implementers wire up the UI.

Some questions to the group on how they plan to integrate layouts into their UI:

• Do you currently have - or plan to have - a custom titlebar that is applied to all windows?
• If so, is this applied to 3rd party application windows as well?
• How is the titlebar incorporated?  
• How do you plan to leverage this for layouts functionality?