[Lens] Drag from one dimension group to another to swap or suggest

[wylieconlon]

Remaining work

Designs here: #51739 (comment)

• Drag to replace
• Drag to swap
• Drag to suggest field

Previous notes

Previous work on this was abandoned: #46178

That change implemented:

This is a move operation. If you drag a dimension panel and drop it onto a different dimension panel, the dragged item should be removed from its origin and should replace its destination.

@AlonaNadler Can you clarify the expected behavior?

it's not quite clear whether we want to move, swap, or reorder when dragging

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[AlonaNadler]

After getting some more feedback about this missing functionality.

I suggest the following:

When a user selects a new field from the left side field lists and drops it in the configurator which is already populated by a field:

• if the input area is a single input area for example x-axis, override the existing fields.
• If it's an area for multiple fields, for example, y-axis or table column. Add the new fields in addition to the fields already exists there.

When users select a fields from the configurator and move it to a different input in the configurator, for example, select an existing field from the x-axis and drop it in the y-axis. Lens should switch between these fields, moving the y-axis to the x-axis as well. Similarly, in a table, users can switch the order of existing fields in the configurator.

[wylieconlon]

The main non-technical reason this is tricky is because the XY configuration doesn't accurately represent the aggregations that are happening: the thing we currently call "Break down by" has 2 different meanings. The linked issue describes a proposal to solve this issue, which I see as requirement for doing more work on drag&drop in general.

[mbondyra]

Hi @wylieconlon but how is the above reason related with drag between dimensions task? I see the value in the related issue but why do you think it stops us from implementing the above? Isn't dragging between dimensions to 'break by' here the same as moving it from the individual fields panel? 🤔

[wylieconlon]

@mbondyra The main reason these are related is that there are two different meanings of "break down by", but only one drop target. To take the simplest example, the user is trying to visualize two keyword fields in a nested way. Imagining that the two fields are geoip.region_name and products.product_name.keyword, Lens today supports two queries and two ways of assigning the queries, creating a list of 4 options. The proposal linked would still support two queries, but only one way of assigning each query, for a total of 2 options. Because there would be fewer options, the drag interaction between dimensions would always do what the user expects.

[cchaos]

Moving some comments from Slack

@wylieconlon:

The first video is about the “replace” type of drag + drop, which might make sense for the XY charts but not the other charts.

Replacing compatible functions

There are a few other types of drag + drop that we could support:

• Drag to swap
• Drag to suggest, which is like “copying” a field from one dimension to another
• Drag to reorder
  Here’s “drag to suggest”

Here’s drag to swap, showing a lot of the edge cases:

Breaking down the decisions that I think need to be made, they are:

• Do users intend to drag the exact operation or do they intend to drag the field the operation is using internally?
• What’s the simplest interaction to explain and build, and is there part of this which is too confusing?

[cchaos]

Moving some comments from Slack

@flash1293:

When dragging to another dimension group, try to swap the exact operations. If that doesn't work because the operation is incompatible, fall back to replacing by just using the dragged field (not 100% sure about just replacing here, maybe swapping is better because it's more consistent). If swapping is not possible because the drop target is empty, try to move the exact operation to the drop target, if the operation is incompatible, just use the dragged field

Pie chart: It's possible to replace the sizing metric with the field of a slice bucket. If the sizing metric is used to replace a slice bucket or to add a new slice bucket, a new sizing metric has to be picked (no chart shown till this is done).
XY chart: X axis and break down by can be swapped (or moved if there is just a single operation in those two dimensions). X axis and break down by can be turned into a metric. In this case a chart would still render because #70703 will render xy charts without configured x axis. Field of a metric can be used on x axis and break down by (if it's the only metric, a new one has to be picked afterwards)

I think some of these operations will be much more common than others and we should focus mostly on getting the common cases as easy to understand as possible:

• XY chart: Swap x axis and break down by
  Other operations that might become common in the future when we add more features:
• Swap metrics on different dimensions (y axis / color by gradient / dot size)
• Swap buckets on "split chart in rows/columns" together with x axis and break down by dimensions
• Heatmap: Swap buckets on X and Y (and maybe "split chart in rows/columns")

Moving from a metric to a bucket and vice versa seems like an edge case to me (that's why I think we shouldn't attempt to swap here because it will rarely be what the user expects and would result in weird charts rendered confusing the user before they remove the swapped operation they wanted to be gone).

An important aspect IMHO is to avoid losing configuration when dragging things around, but with the logic listed out here I think we are in a good spot because it's either swapping (which means no lost data) or there is a place to "park" an operation when trying to swap metric and bucket (e.g. for swapping the x axis field with the y axis field, drag the x axis to a new y axis dimension, then drag the first y axis dimension to the x axis)

[cchaos]

Here's what I'm thinking when it comes to DnD across like dimensions (meaning it the move can keep both field and function). My main goal is to use known paradigms of similar behaviors like copy/paste. I think the most obvious outcome for the user when simply dragging a config is that it is moving.

If they simply want to use the same field in a different config, they should be dragging from the fields list. But using the "copy" style of DnD as indicated below (with cmd/ctrl), this allows them to easily retain the current config while just duplicating the same function in a new dimension. They can then alter the function if they mainly just wanted to reuse the field.

I don't think "swapping" is the expected behavior at least without any indicator.

Note: I am explicitly not commenting on dragging to a non-like dimension.

[AlonaNadler]

Moving from a metric to a bucket and vice versa seems like an edge case to me (that's why I think we shouldn't attempt to swap here because it will rarely be what the user expects and would result in weird charts rendered confusing the user before they remove the swapped operation they wanted to be gone)

When you drag a numerical field into the preview it adds it to the y-axis/ metric
It would be good to allow users to change it to from the metric to the dimension.
I will take the zipcode example :

• xy chart: dropped in the preview, zipcode is added to y-axis, if user wants to move it to the x-axis they need to find it in the field list and drop it on the x-axis. Instead, it will be good to allow to drag and drop the field zipcode (not the entire operation) and apply the default operation once on x-axis.

The same situation can happen when dropping the IP field as default to the x-axis and users want to see the unique count and need to move it to the y-axis.

The XY example applies to pie, donut and treemap as well

[flash1293]

Discussed offline:

• There is no merged reorder/replace/swap behavior - within a dimension group, it's always reordering, cross dimension groups, it's always replace/swap
• Allow swap and replace (different drop target for swap) - the user decides whether they want to replace or swap
• When swapping, change the aggregation order in some cases, but not in all of them (e.g. swap for terms, but not for date histogram. Iterate on a ready PR on details)
• Best effort of keeping configuration - if dimension groups are compatible (e.g. x axis and break down by), the whole operation is copied. If they are not (e.g. x axis and y axis), only the field is used as if dropped from the data panel
• This will be implemented before reordering, as it's easier to achieve

[cchaos]

I have updated the above mocks on how we can indicate cross-dimensional dragging when the dimensions aren't compatible.

[wylieconlon]

I've looked into the feasibility of the mocks above, and everything is technically feasible except the positioning of the "swap" operation shown above. The main reason is that all drop interactions require the mouse cursor to be inside the drop target, but the mouse cursor is also showing the semi-transparent element being dragged. The mock above is not showing the mouse cursor inside the drop target because it would obscure the whole element, and be hard to use accurately.

There are several possible solutions to this problem, and maybe @cchaos can come up with one I haven't considered:

• Provide two side-by-side drop targets of similar widths
• Provide two drop targets stacked vertically
• Provide a separate drag handle for the "swap" operation
• Use a keyboard input to indicate swapping
• Attach the corner of the dragged item to the mouse cursor so that the drop target is not obscured
• Use a different image for the dragged item, such as an icon

My preference is to increase the size of the "swap" drop target and potentially to change the thing that is being dragged.

[cchaos]

Here's the latest idea for swapping/extra drop zones per droppable area. Essentially showing these additional zones when the user hovers over the default one. They can then move to the swap or duplicate zone to perform that kind of action on drop. We could further introduce modifier keys, but these are less discoverable.

In addition, and this was brought up by some other designers, we could introduce a bottom bar with text that helps describe to the user what the action will be when they drop that item.

Interactive mock: https://www.figma.com/proto/CJfejj3KoCnJqx58wzfCvf/%E2%AD%90Flows?node-id=3097%3A151252&scaling=scale-down

Static screenshots:

[flash1293]

@cchaos I still have the impression the swap or copy drop zone will be hard to hit, because you can't see what you are doing while dragging the operation close to the target (which you have to do, otherwise how would you drop it?)

Like in this state, basically just moving the mouse a few pixels down from your last screenshot (sorry for my bad image editing skills) - will it copy or will it swap?

A suggestion: If you drag the operation and hover over another operation which is a valid target, the copy and swap drop zones will slide out of the drop target to the bottom, both of them having the same width as the original operation:

Like a context menu, but for dropping.

If you move the dragged item away from the drop target or the addition copy/swap ones for longer than 2 seconds or so, they will slide back.

[cchaos]

That's why there are other indicators to help the user. THe bottom bar tells them what is going to happen and the visibility of the dragged item's original position vs the cross-out of the dropped area should help in this regard. If you play with the prototype, I have also experimented with add buttons below. The problem is where these options display:

A. If they display inline, they will push all the other configurations around and this will be super jumpy as they drag from dimension to dimension.
B. If they display fixed position, they will overlap other dimensions making it hard to target the one they want which may be below the one they're hovering.

This is why I am suggesting going to the left because then we won't overlap or shift any content.

[wylieconlon]

Are you suggesting that we add a new "bottom bar" element with helper text to indicate what will happen on drop? I didn't realize that was part of your design, I thought it was help text for us to review the design.

[cchaos]

We could almost do both, where we fix position the options to the left of the config, make them bigger (not just icons), and stack them. I'd still give a small pause before showing these as the user rolls over the options.

@wylieconlon Yes. Only the pink marker style text is mock notes. The rest is real UI.

[wylieconlon]

I really like your latest suggestion. It solves the biggest issue I had with the previous suggestion, which was that all the drop targets were vertically aligned and would interfere with each other.

[flash1293]

+1 - the last screen is really cool, the best of all worlds 🙂

[wylieconlon]

I just realized that you are showing both "duplicate" and "swap", but we wouldn't support the "swap" action unless both dimensions have been configured already. How would you like to handle this case where the target dimension is empty? Should we show the drop target, but disable it?

[cchaos]

I was just testing what happens when both are available. Don't show a drop action target if it can't be done.

[wylieconlon]

Question about this proposed design: are these additional drop targets going to be shown when you start dragging, or is there some other interaction required to show them?

a. When you start dragging, all the possible drop targets become visible
b. The extra drop targets only become visible once you position the cursor over a certain dimension

We don't need an answer to this question right now, but it will need to be answered during implementation.

[mbondyra]

@wylieconlon I don't think the option a. is possible with the current designs. Imagine you have multiple columns in one dimension. When user starts dragging and all the drop targets appear, it will look clunky, the 'duplicate' and 'swap' drop targets would overlay with each other.

[wylieconlon]

@mbondyra I agree that option a would not work with the latest design, but I think option b is not going to be easy for users to discover. I do think that b is most likely what @cchaos intended with the previous design. There is also another option that @cchaos suggested earlier, and I'd like to introduce this as option c:

c. "Swap" is shown next to all swappable operations. A tooltip while dragging suggests that users use the "option" key to duplicate the field instead, and if the option key is held down we show "duplicate" instead.

[cchaos]

The original intent that I was trying to demonstrate is that these "extra" actions would only show a specific drop zone when hovering that item. I would not show ALL swap areas for all items at once. This would cause cognitive overload. What has been suggested as a tooltip is actually a bottom bar that would appear at the bottom of the page so that it's less likely to cover the place they want to drag too.

It will be slightly tricky because of what's mentioned the the last screenshot above where the "hovering" area has to be a triangle to encompass the possible drag path.

As a reminder the, prototype is here: https://www.figma.com/proto/CJfejj3KoCnJqx58wzfCvf/%E2%AD%90Flows?node-id=3143%3A2692&viewport=491%2C279%2C0.13001476228237152&scaling=scale-down

[flash1293]

Thanks for putting everything together @cchaos , that's very helpful. IMHO it solves all all the cases in an easy to use and discoverable way (even if it's a bit harder to implement, but I think it worth it for this important interaction)
cc @MichaelMarcialis

[mbondyra]

I agree, that looks really good. How are we going to handle accessible way though?

[flash1293]

I don't have a good answer to this, but If we find one, we can probably apply it to the "drag a field to a dimension" as well (that's also not accessible right now). Based on this I'm not sure whether we have to make this accessible from the start (as it's just a shortcut operation and not an additional feature) Edit: We decided to do this from the start.

My only idea would be something like a context menu opened on some keyboard combination listing all possible moves.

[flash1293]

Implementing all of this in 7.12 in an accessible way is probably not realistic, we will split it up into multiple phases and tackle a meaningful subset now. @mbondyra will look into this an come up with a plan til our next planning meeting.