[Canvas] iterating on interaction design for content creation actions

[monfera]

Kibana version: Happened to use Kibana at e9fc5196ab060a8386da2bdef59e83fa08acada9 but present earlier too

Elasticsearch version: Corresponding Dev snapshot for commit

Server OS version: Local ES

Browser version: Chrome 94.0.4606.61 on OS X

Browser OS version:

Original install method (e.g. download page, yum, from source, etc.): Developer bootstrap

Describe the issue: Canvas now hides all of the editing interactions under a single "Edit" menu, which is tedious to use, I literally had to ask a Canvas developer about how to do a common interaction. Issues:

• by consolidating common interactions under "Edit", there's a discoverability issue
• one more click or keyboard selection to make
• the shifting in/out of menu layers has drawbacks, such as lack of constancy for the higher menu layer (it has benefits too, eg. constant menu width)
• the menu shift animation is time consuming, and it gets very annoying after approx. the first use
• there's no key shortcuts visible on the menu itself, so the user doesn't get to learn shortcuts while using the slow way
• the menu is a top menu rather than a context menu, so the added physical and mental distance from the element itself is extra impediment
• these all combine toward effectively demoting the interactions: "we support these, but best not to use them"
• such a demotion will lead to fewer users using them, in effect, hiding this set of functionality, and lower usage means, fewer bug reports if any action has a bug, which perpetuates the effective phasing out of these actions

Expected behavior: Let's do joint interaction design for content creation on this one. Proposed elements:

Rich facilities in the editing

Compare our vacant top bar, which only "serves" to remove already constrained and valuable vertical space from the content layer:

While Google Slides is earnestly about content creation:

Menu with keyboard shortcuts

It's immensely effective for smoothly growing a casual user of some functions toward a highly efficient user. A separate help menu is a vastly inferior way for learning, because it's way outside the natural interaction flow for users who initially use the menus. Here's a Google Slides multi-purpose menu:

View multiple layers of the menu

While the sliding menus are alluring in minimalism and constant vertical breadth occupancy, it also robs the user of the top layer, when in a lower layer. It also makes the menu slide from underneath the user's pointer, if the subsidiary menu is shorter. Or if it's not shorter, then there'll be a random item underneath the user's cursor. So the effect of an accidental secondary click yields a random action for the user. We don't even have a very nice undo to mitigate that

Reconsider menu animation

The animation gets old fast. It's nice in presentations, marcomm etc. but there are usability questions with the swift, slightly disorienting tweens. There might be an option for prefers-reduce-motion, which this microinteraction could adhere to

Screenshots (if relevant):

https://user-images.githubusercontent.com/1548516/136187416-4d028bad-e6ba-4715-a86e-b42d2c63f42c.mp4

Errors in browser console (if relevant):

Provide logs and/or server output (if relevant):

Any additional context:

[elasticmachine]

Pinging @elastic/kibana-presentation (Team:Presentation)

[monfera]

What's meant by compressed vertical space? On the right side of this slide, all the "sediment layers of UI" are sunk to the bottom, so that there's clear distinction between the contents part (top) and the noise/waste part (sediment layers). We'd do well by reducing the latter, especially that some of that is beyond our control

Here's an more loosely related doc on sometimes suboptimal, overframed, overboxed user interfaces

[cqliu1]

There are many good points on ways we could improve our editing experience in Canvas, but we are unable to prioritize this work. Closing this issue.