[Lens] Add new drag and drop capabilities

[mbondyra]

Created interactions

Fixes #79266
Solves Partially #51739

1. Field keyboard interactions ( drop to workspace, existing field and empty field)
   Select a field with enter and then move between groups with arrows left/right.
   

2. Inside group interactions (reorder and duplicate)
   Reorder stays as before - use arrows down/up to move element.
   Duplicate - choose the new dimension button as a target to duplicate element. (navigate with arrows left/right)
   

3. Between compatible group interactions (move and replace) (navigate with arrows left/right)
   

4. Between incompatible groups (convert & replace and convert & move) (navigate with arrows left/right)
   

Summary

• created announcement system

• added order and dropsByTarget that are registering when dragging element changes

• replaced canHandleDrop to getDropTypes that gives more information and will be useful when we have multiple drops

• types

• styles for datapanel source were changed

• extending value to also hold humanData needed for accessibility

• along with getClassesOnEnter added getClassesOnDropable that is run when element is droppable for the current drag

• documentation

• tests

• functional tests

• destructuring props

• documentation in README.md

[mbondyra]

@elasticmachine merge upstream

[mbondyra]

@elasticmachine merge upstream

[myasonik]

Overall: this is awesome! 🎉 This is probably one of our most complicated intersections of accessibility and functionality and y'all are just nailing it.

Before I dive in, I just want to give some background on how I'm testing right now:

• I started in Safari+VoiceOver (most common browser combination with VO) but there were some bugs with it and moved to Chrome+VO. We should prefer the Safari experience if at all possible when resolving bugs.
• Not looking at the code yet, just running through the UI

Disclaimer before I jump in: this is a super complicated series of interaction. If you're at all unsure about what I mean, disagree, have a better idea, etc PLEASE PLEASE PLEASE reach out and let's talk about it. A lot of these are rough suggestions to move things in the right direction, and nothing here is final or cut-and-dry.

A few early thoughts:

• On the left hand side, the drag&drop instructions say that you can use up/down arrows to reorder but this group doesn't support reordering. Maybe we need separate instructions without this?
• Only when VO is on, if I select an item from the left and arrow right to the workspace, it works. But arrowing right again cancels the movement. (This is super weird because it seems to work fine in Safari without VO and in Chromium browsers with VO on. This probably is probably a browser/VO bug but worth investigating as it's basically a show stopper.)
• When using VO+Chrome, selecting a field from the left column, arrowing right to the workspace works as expected. Arrowing right again says "You have selected Empty dimension...". I would have expected something like "You have selected Horizontal axis..." When arrowing right to vertical axis or break down the text doesn't change and continues to say "empty dimension".
• Regardless of screen reader/browser, after picking up a field I would expect that only left/right arrows brought me between drop zones but I can use up/down arrow keys to take me between drop zones as well.
• Regardless of screen reader/browser, when cycling through drop zones there is some sort of hidden extra stop. Not sure what it is but it's confusing as to "where" I am.
• Using VO+Chrome, when dropping a field over another one, there is a visual indication that it will replace it (the strikethrough) but nothing seems to communicate that to a screen reader. As an example, what I get is: "You have selected Top values of currency..." I would have expected something closer to "You have selected Horizontal axis, replacing Top values of currency..."
• Regardless of screen reader/browser, after dropping a field focus either stays on the field or is lost and moves to the body. I would move focus to the workspace after every successful drop event because of how often how hard it is to say where a good place to move focus to is. (They key thing here would be to have easy/quick graspable rules on where focus will go every time.)
• Regardless of screen reader/browser, picking up a field on the right (from any list) if you first change its position, you cannot changes its zone. You have to move it back to its starting position and then you can change zones.

<At this point I stopped reviewing but will do more this week/as this PR progresses>

[mbondyra]

Hi @myasonik, thank you for your feedback! here's my responses:

• On the left hand side, the drag&drop instructions say that you can use up/down arrows to reorder but this group doesn't support reordering. Maybe we need separate instructions without this?
  ✅ That was a bug, I did create two copies for reorder case and no-reorder case but didn’t attach it properly. Fixed it!

• Only when VO is on, if I select an item from the left and arrow right to the workspace, it works. But arrowing right again cancels the movement. (This is super weird because it seems to work fine in Safari without VO and in Chromium browsers with VO on. This probably is probably a browser/VO bug but worth investigating as it's basically a show stopper.)
  ❓Not sure if it's my computer configuration, but for some reason I cannot use VO and arrows at all - I assigned WSAD keys and everything works great, but with arrows it just moves the focus. Do you know what I have configured wrong?

• Using VO+Chrome, when dropping a field over another one, there is a visual indication that it will replace it (the strikethrough) but nothing seems to communicate that to a screen reader. As an example, what I get is: "You have selected Top values of currency..." I would have expected something closer to "You have selected Horizontal axis, replacing Top values of currency..."
• When using VO+Chrome, selecting a field from the left column, arrowing right to the workspace works as expected. Arrowing right again says "You have selected Empty dimension...". I would have expected something like "You have selected Horizontal axis..." When arrowing right to vertical axis or break down the text doesn't change and continues to say "empty dimension".
  👀 We have a meeting about it on Friday, there’s a lot of information that potentially have to be communicated. For now I’ll just change the copy to You have selected Empty dimension in Vertical axis group in position 2. Press space or enter to drop category.keyword and for existing dimension You have selected Unique count of customer_full_name.keyword in Vertical axis group in position 1. Press space or enter to replace Unique count of customer_full_name.keyword with category.keyword.

• Regardless of screen reader/browser, after picking up a field I would expect that only left/right arrows brought me between drop zones but I can use up/down arrow keys to take me between drop zones as well.
  ✅ Another bug, fixed!

• Regardless of screen reader/browser, when cycling through drop zones there is some sort of hidden extra stop. Not sure what it is but it's confusing as to "where" I am.
  ❓ The hidden extra stop is deselected element - you start with no selection, then you go through all the targets and at the end you come back to no selection. There’s an announcement about it (copy to be discussed): “You have no target selected. Use arrow keys to select a target.” There's a reason behind it – thanks to that we know when to allow reordering (when there's no selection)

• Regardless of screen reader/browser, after dropping a field focus either stays on the field or is lost and moves to the body. I would move focus to the workspace after every successful drop event because of how often how hard it is to say where a good place to move focus to is. (They key thing here would be to have easy/quick graspable rules on where focus will go every time.)
  ❓Ahhh, I think this is more complicated that we think. I agree that when moving a field we should move the focus to the workspace, but should we do the same when moving inside of reordering group or inside of the layer? I am no so sure, let’s have a conversation about it.

• Regardless of screen reader/browser, picking up a field on the right (from any list) if you first change its position, you cannot changes its zone. You have to move it back to its starting position and then you can change zones.
  ❓Yeah, that's the limitation I built on purpose (there's a message that informs a user about it: You have started reordering and you cannot choose any external target now. Press escape to cancel and try again.. I am happy to discuss other options, but I think that allowing a user to reorder, then to choose another drop target would be too confusing.

[MichaelMarcialis]

@mbondyra: Wow, this is some really incredible work! Very well done! I've been playing around with it in Chrome for a bit and it's wonderful. I've got a handful of notes below regarding some aspects of the UI/UX. Please forgive any repetition with @myasonik's feedback.

1. If possible, I'd love to see the field or dimension item being acted upon following the user's drop zone focus during a keyboard drag event. I feel like seeing the field/item moving in close proximity to its final drop location provides some valuable visual context and validation. Below is a quick visual of what I'm talking about here.

2. When utilizing the left/right keys to move a keyboard-selected dimension item to a new dimension, the keyboard-selected dimension item continues to show in the origin dimension (ex. when moving a dimension item from "Vertical axis" to "Break down by"). I think it would be a helpful visual for users if the keyboard-selected dimension item followed the user's drop zone focus (as described in the previous comment) and a phantom space/blank was used in its original position in the origin dimension. I feel that doing would better indicate to users that this action will result in the dimension item being taken out of the originating dimension and taken elsewhere.

3. It appears that using the left/right keys to migrate a keyboard-selected dimension item is is disabled if a that item's order has been changed in its origin dimension. This confused me for a bit during testing, especially with other dimensions continuing to be styled as possible drop areas after reordering. To avoid this confusion, would it be possible to allow the usage of the left/right keys regardless if the user has changed the item's order in the origin dimension? Assuming this is possible, I imagine using the left/right keys would undo any temporarily made item order changes in the origin dimension, as it would no longer make sense to reflect that order change.

4. When other dimension drop areas are highlighted/styled during a drag action (both keyboard and mouse), I think we should have those drop areas feature a dashed border (as shown in @cchaos's original designs). Currently they only get the dashed border treatment on hover or keyboard-focus during a drag action. Below is an example of dashed border missing on "Break down by" drop target until hovered or keyboard-focused.

5. Some of the drop zone colors look off compared to @cchaos's original designs. Is the change intentional?

[wylieconlon]

I think this is very close to being ready! I tested as many of the interactions as I could in Firefox. I would be comfortable merging and iterating on this feature once the level of test coverage includes the new scenarios.

@MichaelMarcialis I agree that we should implement your feedback except the one about the ghost image. That's a feature of the web browser which we would need to reimplement.

[mbondyra]

@elasticmachine merge upstream

[mbondyra]

Thank you all for feedback and kind words! I've implemented all corrections from @MichaelMarcialis except for the ghost image – I'm all for doing it, but in the second iteration as it's a bigger effort and I would like to merge this PR in 7.12, if acceptable by everyone. Also, please check how not blocking the right/left arrows while reordering feels like right now.

Regarding the list from Michail, we spoke about it offline and the only thing I don't see ready yet in this PR is focus management – sometimes focus gets lost (when element is being moved to other dimension and removed from the old one) – I'll submit another PR for it next week!

[MichaelMarcialis]

Also leaving a few small CSS comments. Thanks!

[MichaelMarcialis]

I've implemented all corrections from @MichaelMarcialis except for the ghost image – I'm all for doing it, but in the second iteration as it's a bigger effort and I would like to merge this PR in 7.12, if acceptable by everyone.

Sounds good. Did you want me to open a new issue for that? Or have you already done so?

[mbondyra]

Yes, please @MichaelMarcialis , if you could open an issue that would be great 🙏

[myasonik]

Did some more testing of this both as a keyboard user and a screen reader user and this is working so nicely. Feels great to use, I love it.

The focus drop is the one thing that I could find and you already know about that. Otherwise, such a smooth experience.

Also, please check how not blocking the right/left arrows while reordering feels like right now.

I'm definitely a fan. Feels way more natural for me while exploring.

[MichaelMarcialis]

Thanks for making those changes, @mbondyra! LGTM!

Also, I've opened a separate issue for the request to have keyboard-selected items follow user traversal of drop zones (and accompanying phantom space request).

[flash1293]

Tested and didn't find any problems, this LGTM. There are a bunch of calls to getOperationSupportMatrix we cannmake less expensive because we only need the operations for a single field, but we are building the matrix for the whole index pattern. This will be especially relevant for index patterns with tons of fields.

What I had in mind is to pass in an optional field name and if that's set, the expensive code in getAvailableOperationsByMetadata doesn't iterate over all of the fields but just the required one to build the part of the matrix we actually require.

Not a blocker though

[flash1293]

Smart way of avoiding a call to getOperationSupportMatrix !

[flash1293]

Note: I'm working on this on the column transpose PR

[dej611]

nitpick: why the ternary here?

[dej611]

LGTM 👍
Tested on Chrome & Safari ✅

[ryankeairns]

Really great stuff @mbondyra , exceptional work!

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 387a1fe

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
lens	478	481	+3

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
lens	875.0KB	890.1KB	+15.2KB

History

• 💚 Build #104211 succeeded e2ba12a
• 💔 Build #104188 failed b4ad0a5
• 💛 Build #103898 was flaky 3ec424e
• 💔 Build #103880 failed 9799d57
• 💚 Build #103879 succeeded e6f5ec2

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream