[UnifiedFieldList] Add a drag handle to field list items

[jughosta]

• Addresses [UnifiedFieldList] Use drag icon #168856

Summary

This PR adds a drag icon next to field list items on hover.

Preview

[andreadelrio]

Hi @jughosta ! Thanks for working on this. I've put together a comparison of the current state of this PR vs the mockups. Not entirely sure why but the icon doesn't seem to be centered, there appears to be more space on the right than on the left. I've included some specifications in regards to spacing between items. Also, with the inclusion of the grabOmnidirectional icon I think we should be able to remove the translateX defined in @mixin mixinDomDragDropHover.

[jughosta]

Thanks, @andreadelrio! I will look into it.

[jughosta]

Hi @andreadelrio,

I updated the styles, please have a look in Discover and Lens when you get a chance.

[andreadelrio]

Hi @andreadelrio,

I updated the styles, please have a look in Discover and Lens when you get a chance.

Hi @jughosta thanks for the updates. This is looking much better. The Lens version doesn't feel as good to me as the Discover one. In particular, this bit (see video below). I will check with @MichaelMarcialis to see what he thinks.

Screen.Recording.2023-12-04.at.4.13.21.PM.mov

[andreadelrio]

@jughosta do you still need this line? I'm seeing this in the browser.

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: b0c5ac3

Failed CI Steps

• FTR Configs #15

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
discover	707	709	+2
eventAnnotationListing	460	462	+2
lens	1147	1149	+2
logExplorer	644	646	+2
total			+8

Async chunks

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

id	before	after	diff
cloudSecurityPosture	443.9KB	444.0KB	+144.0B
dataVisualizer	614.6KB	614.8KB	+144.0B
discover	589.6KB	591.4KB	+1.8KB
enterpriseSearch	2.7MB	2.7MB	+144.0B
eventAnnotationListing	197.0KB	197.1KB	+144.0B
graph	388.2KB	388.3KB	+144.0B
indexManagement	585.2KB	585.3KB	+144.0B
lens	1.4MB	1.4MB	+1.7KB
maps	2.9MB	2.9MB	+144.0B
ml	3.6MB	3.6MB	+144.0B
presentationUtil	82.5KB	82.6KB	+144.0B
securitySolution	12.9MB	12.9MB	+144.0B
stackAlerts	203.0KB	203.2KB	+144.0B
unifiedDocViewer	58.5KB	58.6KB	+144.0B
unifiedSearch	216.0KB	216.1KB	+144.0B
total			+5.3KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
osquery	51.3KB	51.4KB	+144.0B

History

• 💚 Build #181363 succeeded b0f09eb
• 💔 Build #181292 failed c3724ae
• 💛 Build #177058 was flaky 4b31f91

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

cc @jughosta

[MichaelMarcialis]

Hi @andreadelrio,
I updated the styles, please have a look in Discover and Lens when you get a chance.

Hi @jughosta thanks for the updates. This is looking much better. The Lens version doesn't feel as good to me as the Discover one. In particular, this bit (see video below). I will check with @MichaelMarcialis to see what he thinks.

Thanks for putting this together, @jughosta! It looks amazing. @andreadelrio and I discussed her concerns above in Slack. I'm personally not a fan of the fact that the appearance of the drag handle on hover/focus means the height of the field list item may increase due to additional line breaks appearing. This increased-height-on-hover possibility is an issue that will exist in both the Discover and Lens field list versions, and it's something I didn't anticipate during the design phase.

As a simple way to mitigate this issue, what if we changed it so that on hover/focus of a field list item we fade-out the token and fade-in the drag handle to replace the token (in the same position)? In doing so, we could also keep the old translate x-axis transition (where the field list item slides a few pixels to the right) to emphasize that it's draggable. That little bit of extra movement might be good, if the appearance of the drag handle is no longer pushing the text (given the above suggestion). Thoughts? I'd be happy to discuss further or make mockups if needed.

---

While I'm here, I also wanted to ask whether we should continue to style the field lists uniquely for Discover and Lens (as you have here), or if now would be a good time to proceed with a consistent field list styling for both applications. For example, is there a compelling reason for us not to remove the background color, shadows, border radii, and reduce the font size for the field list items in Lens (at least until a field list item is being dragged, in which case the background color, shadows, and border radii appear on the drag clone)? If there's not a compelling reason, I'd personally love to have the two field lists appear as similar as possible, if not altogether identical. Thoughts? CCing @ninoslavmiskovic, in case he has any concerns with such a recommendation.

---

Finally, I know there has been some friendly disagreement on this between @timductive and me in the Figma comments, but the original designs had each field list item as 32px tall with no margin in between siblings (versus the current 24px tall with 2px margin between). Doing so provided what I would consider to be minimal safe real estate with which users could grab and drag an item (though others tend to suggest even larger, ~38–40px minimum). While I understand there is a desire for high density in the field list, I think this needs to be balanced against usability. Would ya'll be open to increasing the height of each field list item to better match the designs?

The end result of this suggested change also isn't very dramatic on the field density topic. For example, in a 1440x1024 viewport, the current field height and margining shows 27.5 fields. Updating height and removing margins to match the designs shows 23 fields. I'm personally OK having 4.5 fields falling below the fold for the sake of a better experience.

[ninoslavmiskovic]

++ On keep moving towards aligning Lens and Discover on field list UI. Like we did with features in the field list.

We should also "dry-run" the new design as a unified component that is embedded across solution.

Regarding the pixel height I also think it is important to test in other contexts.

[jughosta]

Hi @MichaelMarcialis and @andreadelrio,

Sorry for the delay. I've implemented your suggestion for showing the drag icon in place of the field type icon. Here is a new PR for it: #173673

[jughosta]

Closing in favor of #173673

@MichaelMarcialis For the changes in field item's height/margin would be great to have a separate Github issue. I also agree that it would be better to have the same styles on both Lens and Discover pages.