界面上，你应该常使用到可拖曳元件(drag and drop)，例如拖拉Gmail 的信件到资料夹中、移动Trello 的卡片或是把Chrome 浏览器上的分页重新排列等。虽然操作很简单，但这些互动的设计复杂度超过你的想像。本文就来分享在VMware 中设计“可拖曳的元件” 的经验。
可拖曳元件的互动细节往往会被使用者忽视，有时自然到你根本没意识到。但如果你仔细观察比较下述三个例子，它们皆有非常不同的UX 标准。
这些元件有不同的操作定义，但这没有对错，因为每个产品都可能因为某些原因而选择不同的模式。例如，Trello 在拖拉卡片时，卡片会呈现倾斜状，可能是因为符合他们表示对使用者友善的设计语言。
不过最大的问题在于是否套用一致及清晰的UX 设计标准，否则你有可能在不同页面使用可拖曳元件的体验都不一样。例如 Salesforce 所设计的可拖曳元件库，里头有五种模式，每种操作方式差异都相当大。
虽然都可以运作，但不幸的，在这五种操作模式中存在着不一致，利如使用不同的游标样式，及三种不同的拖曳处样式（drag and drop handle），如下：
猜猜看，那个是可拖曳时的游标状态？答案：全部都是
三条线的icon 能代表可拖曳？或是三个点的才能？究竟那五种哪个才能代表可拖拉呢？想像一下，如果介面上出现五种表示方式，使用者会有多困惑！在设计系统中，元件彼此间应该看起来或感觉上是一体的，而元件间可拖曳的互动方式也应具一致性。
Design systems 不仅仅要让UI 元件一致性，最重要的是提供一致的体验
可拖曳元件的案例
我们的使用者需要透过拖曳来操作一些元件，如树状视图（tree view）、资料表格及卡片，而我的任务即是统一使用者在操作这类功能时的体验。
*重新排列与叠组树状结点
*重新排列表格的资料栏（columns）
*重新排列表格的资料列（rows）
*在树状结构与表格之间拖曳
*重新排列与合并卡片
创造一个可被理解使用的元件库
1. 适当的颜色
使用可区别且不是设计系统中常出现的颜色来表示可拖曳的互动，且避免使用已经在介面中定义代表某些意义的颜色（如红色表示不可逆的行为）。
我们选择了非系统主要色彩的紫色应用于拖曳的行为上，所以使用者一看到紫色，就会产生可拖曳的期待与体验。我们避免使用蓝色（常用于表示拖曳功能），因为在Clarity 中，它代表着可互动的按钮或可点击的元素。
2. 拖曳状态的样式
设计元件被拖曳时的各种状态，以视觉的方式非常具体的表现“可被拖曳”、“拖曳后”等的样式。
当元件可被拖曳，它应该有以下的样式：
另外我们也替“被移动元件”的初始位置加入一个状态（ Previous state）。
这个初始状态可以提醒使用者元件之前的位置，但要注意的是，这个状态并不适用于要表达“自然拖曳”行为的动作（如拖移图形化菜单）。
3. 系统原生游标
使用系统原生游标来告知这个元件可被拖曳，这似乎只是小改变，但会大大的提升这些元件的可发现性。
在Mac 上，我们使用“要抓”（打开Mickey Mouse 的手） 及“抓住”（Mickey Mouse 的手握紧) 的游标来表示“可被抓”与“已被抓”的状态。如果那个元件不能被抓，则显示无效的游标（unavailable cursor）。
在Windows 上，我们使用“移动”游标（十字双箭头）来表示可被拖曳，另也有显示无效的游标。
4. 放置目标区
应该要设计预计放置位置的模式，让使用者可看出这个区域是可放置已拖曳元件的。如同上述提到的状态样式，放置目标区也应该订出规范。
既然重新安排元件是一个拖拉过程的关键互动，我们应该具体的规划元件将被放下的位置。
我们在目标区的左边加个小圆，做出与普通的线或外框的区隔。这是一个非常重要的设计细节，对色盲用户来说，更能提供一个除了颜色外可辨识的管道。
5. 视情况使用的案例（ affordances）
其中一个视情况使用的案例就是拖曳把手（drag handles）。拖曳手把是透过小icon 来表示元件可被拖曳。Gmail 选择了12个小点的icon，而我们选择了6 个小点的icon来表示拖曳手把：
需不需要放置拖曳手把很大程度依赖于使用者心中的模型，如果这组元件通常不会有拖曳功能，这时候放置手把将具有提示效果；但这组元件本来就被预计有这样的功能，就不需要放上手把了。
例如，我们并没有在树状结构的元件中加入手把，因为树状结构本身在使用者心中就有预期是可被移动的。相反的，我们在可拖曳的卡片上加了手把，因为并非所有的卡片都可被拖曳。
整合
本文提到的可协助大家建立可拖曳元件的基础，但还有更多方法来建构这个准则。无论如何，建立可拖曳元件的UX准则后，将可以与其他互动的体验一致，不会觉得突兀。而最后的成品，我放到inVision上供大家参考。
参考文章
Rethingking drag and drop
Salesforce UX's accessible drag and drop patterns
原文：Drag and Drop for Design Systems
拖移信件进入资料夹
移动Trello 的卡片
重新排列Chrome 上的分页tab
可拖曳元件的互动细节往往会被使用者忽视，有时自然到你根本没意识到。但如果你仔细观察比较下述三个例子，它们皆有非常不同的UX 标准。
这些元件有不同的操作定义，但这没有对错，因为每个产品都可能因为某些原因而选择不同的模式。例如，Trello 在拖拉卡片时，卡片会呈现倾斜状，可能是因为符合他们表示对使用者友善的设计语言。
不过最大的问题在于是否套用一致及清晰的UX 设计标准，否则你有可能在不同页面使用可拖曳元件的体验都不一样。例如 Salesforce 所设计的可拖曳元件库，里头有五种模式，每种操作方式差异都相当大。
Salesforce 的拖拉元件
虽然都可以运作，但不幸的，在这五种操作模式中存在着不一致，利如使用不同的游标样式，及三种不同的拖曳处样式（drag and drop handle），如下：
猜猜看，那个是可拖曳时的游标状态？答案：全部都是
三条线的icon 能代表可拖曳？或是三个点的才能？究竟那五种哪个才能代表可拖拉呢？想像一下，如果介面上出现五种表示方式，使用者会有多困惑！在设计系统中，元件彼此间应该看起来或感觉上是一体的，而元件间可拖曳的互动方式也应具一致性。
Design systems 不仅仅要让UI 元件一致性，最重要的是提供一致的体验
可拖曳元件的案例
以下是我在研究与设计Clarity（VMware 的设计系统）中“ 可拖曳元件”的案例，Clarity 是一个开放源，所以不只是内部员工可使用，外部想利用的人也能使用。
我们的使用者需要透过拖曳来操作一些元件，如树状视图（tree view）、资料表格及卡片，而我的任务即是统一使用者在操作这类功能时的体验。
*重新排列与叠组树状结点
*重新排列表格的资料栏（columns）
*重新排列表格的资料列（rows）
*在树状结构与表格之间拖曳
*重新排列与合并卡片
创造一个可被理解使用的元件库
1. 适当的颜色
使用可区别且不是设计系统中常出现的颜色来表示可拖曳的互动，且避免使用已经在介面中定义代表某些意义的颜色（如红色表示不可逆的行为）。
重新排列卡片
我们选择了非系统主要色彩的紫色应用于拖曳的行为上，所以使用者一看到紫色，就会产生可拖曳的期待与体验。我们避免使用蓝色（常用于表示拖曳功能），因为在Clarity 中，它代表着可互动的按钮或可点击的元素。
2. 拖曳状态的样式
设计元件被拖曳时的各种状态，以视觉的方式非常具体的表现“可被拖曳”、“拖曳后”等的样式。
当元件可被拖曳，它应该有以下的样式：
重新调整树状结构上的节点
另外我们也替“被移动元件”的初始位置加入一个状态（ Previous state）。
将树状结构上的节点堆叠
这个初始状态可以提醒使用者元件之前的位置，但要注意的是，这个状态并不适用于要表达“自然拖曳”行为的动作（如拖移图形化菜单）。
3. 系统原生游标
使用系统原生游标来告知这个元件可被拖曳，这似乎只是小改变，但会大大的提升这些元件的可发现性。
在Mac 上，我们使用“要抓”（打开Mickey Mouse 的手） 及“抓住”（Mickey Mouse 的手握紧) 的游标来表示“可被抓”与“已被抓”的状态。如果那个元件不能被抓，则显示无效的游标（unavailable cursor）。
在Windows 上，我们使用“移动”游标（十字双箭头）来表示可被拖曳，另也有显示无效的游标。
4. 放置目标区
应该要设计预计放置位置的模式，让使用者可看出这个区域是可放置已拖曳元件的。如同上述提到的状态样式，放置目标区也应该订出规范。
既然重新安排元件是一个拖拉过程的关键互动，我们应该具体的规划元件将被放下的位置。
重新安排在资料列上的位置
我们在目标区的左边加个小圆，做出与普通的线或外框的区隔。这是一个非常重要的设计细节，对色盲用户来说，更能提供一个除了颜色外可辨识的管道。
5. 视情况使用的案例（ affordances）
其中一个视情况使用的案例就是拖曳把手（drag handles）。拖曳手把是透过小icon 来表示元件可被拖曳。Gmail 选择了12个小点的icon，而我们选择了6 个小点的icon来表示拖曳手把：
需不需要放置拖曳手把很大程度依赖于使用者心中的模型，如果这组元件通常不会有拖曳功能，这时候放置手把将具有提示效果；但这组元件本来就被预计有这样的功能，就不需要放上手把了。
例如，我们并没有在树状结构的元件中加入手把，因为树状结构本身在使用者心中就有预期是可被移动的。相反的，我们在可拖曳的卡片上加了手把，因为并非所有的卡片都可被拖曳。
最后有个重点，虽然有许多icon 皆能表示元件可被拖曳，但我们应该选择与使用其中一款就好。
整合
本文提到的可协助大家建立可拖曳元件的基础，但还有更多方法来建构这个准则。无论如何，建立可拖曳元件的UX准则后，将可以与其他互动的体验一致，不会觉得突兀。而最后的成品，我放到inVision上供大家参考。
参考文章
Rethingking drag and drop
Salesforce UX's accessible drag and drop patterns
原文：Drag and Drop for Design Systems
翻译：WILSON
发表评论 取消回复