Design Pattern Library - Drag and Drop elements
Problem
(What’s the problem that this pattern solves? Why is it worth solving?)
Solution
(What’s the solution? Why is it like that? What are the benefits?)
Example(s)
(One or more images showing the UX pattern. They don’t have to be in GitLab.)
Usage
Drag and drop with sorting and filtering
[…] sorting by column and filtering through the data grid should be disabled if drag and drop is enabled, because the logic for either contradicts the other (ex: you can’t drag rows around if they are sorted by date). — https://medium.com/@gracesnoh/hi-tom-i-agree-with-you-drag-and-drop-is-not-meant-for-data-grids-with-large-data-sets-74be92502c80
Sorting data grids with large datasets
Drag and drop is not meant for data grids with large datasets. The main use case we had in mind for draggable rows in a data grid was setting some sort of order or priority — for example, reordering your WiFi network preferences […] Use cases like this shouldn’t support large data sets — otherwise, users would spend hours or even days going through and prioritizing and reordering hundreds of rows. — https://medium.com/@gracesnoh/hi-tom-i-agree-with-you-drag-and-drop-is-not-meant-for-data-grids-with-large-data-sets-74be92502c80
Showing drag handle icon
Ultimately, from a systems point of view, we decided that we couldn’t enforce everyone to either always show drag handles or never show them at all. While showing the icon makes drag and drop intuitive, it can add a lot of visual noise when applied exponentially. For instance, in a draggable tree view, having drag handles for each tree node adds significant visual overhead and may even hinder other interactions. — https://medium.com/@gracesnoh/hi-marshall-thanks-for-your-response-33f1fb2679b7
Traditionally, tree nodes in VMware interfaces are always draggable. So when this pattern is applied to VMware interfaces, drag and drop should be an expected behavior. However, this may not be the case for other situations. Ultimately, we favored reducing visual noise over standardizing on handle vs no handle because our users are often already staring at busy screens, and we didn’t want to make it even busier. — https://medium.com/@gracesnoh/hi-tom-these-are-valid-points-and-were-brought-up-by-people-on-our-team-too-6303431fa414
Dos and dont's
(Use this table to add images and text describing what’s ok and not ok.)
|
|
---|---|
Related patterns
(List any related or similar solutions. If none, write: No related patterns)
Links / references
- https://uxdesign.cc/drag-and-drop-for-design-systems-8d40502eb26d
- https://medium.com/@alexandereardon/rethinking-drag-and-drop-d9f5770b4e6b
- https://github.com/vmware/clarity/issues/1771
- https://salesforce-ux.github.io/dnd-a11y-patterns/#/canvas?_k=6ikxim
Pattern checklist
Make sure these are completed before closing the issue, with a link to the relevant commit, if applicable.
-
Ensure that you have broken things down into atoms, molecules, and organisms. -
Check that you have not created a duplicate of an existing pattern. -
Ensure that you have used the proper method for creating the pattern depending on the complexity. Atoms and molecules are symbols, organisms are groups. -
Make sure that text is created using text styles. When applicable used shared styles for colors. -
QA check by another UX'r (create and reference a file in this issue which includes the changes as you would like to add them to the gitlab-elements file) -
Added to gitlab-elements.sketch -
Add to the UX Guide and/or add to the GitLab Design Library -
Add an agenda item to the next UX weekly call to inform everyone (if new pattern, not yet used in the application)