Revisit cards, lists, and data tables/grids
Problem
Reading through https://uxdesign.cc/drag-and-drop-for-design-systems-8d40502eb26d there are a couple of things that we can improve in how we have designed and apply cards, lists, and data tables/grids:
- Show a position drop target, keep the “ghost” item until it's moved. Essentially, show the previous state instead of having natural movement. See context below.
- Show a drag handle icon. See context below.
- Establish the difference between cards, lists, and data tables/grids.
- Allow list items to be draggable without looking like a card. When looking at this design, there's a lot of unnecessary space by having cards and the comparison between items is a bit more difficult, unnecessarily.
- Use or not to use data table headers?
Be sure to check the “Links / references” section below.
Show the previous state instead of natural movement
[…] we took into consideration that many of our users are dealing with enterprise interfaces, which often are UI-heavy and tolerate little room for error. We wanted to give our users the option to “undo” their drag if necessary. With natural movement, it’s difficult to remember where the element was previously since things automatically shift around as you drag. — https://medium.com/@PedroMScom/thanks-for-putting-this-together-grace-4cc0d7642113
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