如何設計 “可拖曳元件“(Drag and Drop)?

介面上,你應該常使用到 可拖曳元件 (drag and drop),例如拖拉 Gmail 的信件到資料夾中、移動 Trello 的卡片或是把 Chrome 瀏覽器上的分頁重新排列等。雖然操作很簡單,但這些互動的設計複雜度超過你的想像。本文就來分享在 VMware 中設計 “可拖曳的元件” 的經驗。

可拖曳元件 UI

拖移信件進入資料夾

 

可拖曳元件 UI

移動 Trello 的卡片

 

可拖曳元件 UI

重新排列 Chrome 上的分頁 tab

 

可拖曳元件 的互動細節往往會被使用者忽視,有時自然到你根本沒意識到。但如果你仔細觀察比較下述三個例子,它們皆有非常不同的 UX 標準。

這些元件有不同的操作定義,但這沒有對錯,因為每個產品都可能因為某些原因而選擇不同的模式。例如,Trello 在拖拉卡片時,卡片會呈現傾斜狀,可能是因為符合他們表示對使用者友善的設計語言。

不過最大的問題在於是否套用一致及清晰的 UX 設計標準,否則你有可能在不同頁面使用可拖曳元件的體驗都不一樣。例如 Salesforce 所設計的可拖曳元件庫,裡頭有五種模式,每種操作方式差異都相當大。

Salesforce 的拖拉元件

 

雖然都可以運作,但不幸的,在這五種操作模式中存在著不一致,利如使用不同的游標樣式,及三種不同的拖曳處樣式(drag and drop handle),如下:

猜猜看,那個是可拖曳時的游標狀態?答案:全部都是

三條線的 icon 能代表可拖曳?或是三個點的才能?究竟那五種哪個才能代表可拖拉呢?想像一下,如果介面上出現五種表示方式,使用者會有多困惑!在設計系統中,元件彼此間應該看起來或感覺上是一體的,而元件間可拖曳的互動方式也應具一致性。

Design systems 不僅僅要讓 UI 元件一致性,最重要的是提供一致的體驗

 

可拖曳元件 的案例

以下是我在研究與設計 Clarity(VMware 的設計系統)中“ 可拖曳元件 ”的案例,Clarity 是一個開放源,所以不只是內部員工可使用,外部想利用的人也能使用。

我們的使用者需要透過拖曳來操作一些元件,如樹狀視圖(tree view)、資料表格及卡片,而我的任務即是統一使用者在操作這類功能時的體驗。

  • 重新排列與疊組樹狀結點
  • 重新排列表格的資料欄(columns)
  • 重新排列表格的資料列(rows)
  • 在樹狀結構與表格之間拖曳
  • 重新排列與合併卡片

對於如 VMware 有著大量數據(data heavy)的企業, 拖曳能讓我們的用戶組織複雜且大量數據的關鍵功能。

 

創造一個可被理解使用的元件庫

首先,我建了一個簡單且小型的元件庫,讓拖曳功能可有效的被理解感知如何使用,並能應用於不同的專案中。如果你正打造設計系統,以下也許可以幫助你開始思考如何傳達可拖曳元件的模式。

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 上供大家參考。

 

參考文章

 

本文經作者 Grace Noh 授權翻譯,原文:Drag and Drop for Design Systems

 

 

本文章所屬設計大舌頭與作者所有,未經授權,不得轉載!如需轉載,煩請通知

分享此文: