Kibana: Layout Phase 2

[timductive]

This phase of the layout engine will add some key features and update/fix some previous issues.

Layout Engine

Layers

Next generation tools like Maps and Lens utilize the concept of layers and Canvas should as well. This will help with finding/selecting elements, grouping, manipulating, etc...

• [ ] Layer selector #25505
  
  
  
  • This could be broken into multiple phases, back-end work to prepare layout engine layers, then layer selector UI
  
  
  • Should include ability to select elements within layer
  
  
• [ ] Lock an element (or layer) #23226

Fine-tuned controls

Canvas would benefit from more explicit and fine-tuned controls for how users can layout the page.

• [ ] Snap to pixel on axis-aligned elements #23171 [bug]
• [ ] Suggest equal distribution #23161

Layout UI

Layers

• [ ] Layer selector UI #25505
• [ ] Background elements manipulated ? #34880 [bug]

Fine-tuned controls

• [ ] UI-based element manipulation ? #23056
• [ ] Adjustable pixels (like #23056 but simpler) #52647

Right-click menu

• [ ] UI-based page manipulation ? #23060
  
  
  
  • Need to standardize API and UI
  
  

Performance

I've taken a best-guess at performance work that is related to the layout engine.

• [ ] Undo performance ? #23041
• [ ] Workpad fails too many undo requests ? #32523
• [ ] Workpad is reloaded with every undo request ? #32521
• [ ] Copy/paste takes 2-3 seconds ? #28536
• [ ] Page duplication can take 10 seconds ? #30095

[elasticmachine]

Pinging @elastic/kibana-canvas (Team:Canvas)

[clintandrewhall]

Some suggested additions:

• Right-click menu as a standalone issue. We need to standardize the UI and API.
• Work on Layer Selector should include/consider Element selection, as well, (e.g. selecting elements from a menu/list rather than on the page).

[ryankeairns]

Design tools, such as Sketch, are a good reference point for how the UI could work:

[timductive]

Updated the issue to reflect @clintandrewhall's suggestions

[shaunmcgough]

++ @ryankeairns screenshot. We could have a greyed out lock that you just click when the element is highlight, and then in an accordion view be able to select multiple elements. Also, editing a single element in a group of selected or custom elements would be possible here.

[monfera]

Thanks @timductive, great collection!

These, on an initial look, don't seem directly related to the layout engine, ie. fixing or providing them don't appear to need (or solvable by) an aeroelastic code change, glad to discuss them one by one next week:

34880

23056

23060

23041

32523

32521

28536

30095

Maybe there are just varying definitions of the LE boundary, still it'd be useful to keep the placement and direct manipulation calculations (what I understand under LE - it's just calcs; no DOM involvement) separate from other UI affordances such as menus, context menus, DOM element capture, actual element insertion and update by React etc. (Having said this, it might make sense to have the concept of a "Layout UI" abstraction, because, if such drag&drop is needed elsewhere, it's nice to have a React component encapsulation for all the context menus, future layer/element manipulation side panels, keyboard shortcuts etc.- but currently, these things are not cleanly separated from unrelated menu, button etc. UI, not sure if @cqliu1 thinks it's even feasible to separate though)

For clarity, I'm adding a question mark in the original post, and also for these:

23602 should be triaged as the issue isn't clear from the gif (which I filed :🦆🦆🦆:)

33011 should also be triaged to see if there's still an issue; if so, glad to check if it comes from the layout engine

[timductive]

Hey @monfera thanks for taking a look. I agree, what I will do is edit this issue to clearly indicate things that are the Layout Engine and things that are Layout UI and then we can discuss what the right abstractions are. I'll also take a look and re-triage the issues that you mentioned.