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

拖移信件進入資料夾

移動 Trello 的卡片

重新排列 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 上供大家參考。

參考文章
Rethingking drag and drop
Salesforce UX’s accessible drag and drop patterns

文章出處/ 設計大舌頭

誠摯邀請你成為好朋友-->
        

About The Author

設計大舌頭

設計大舌頭是一個長期關注各項 UX 相關議題的平台,包含 UI 設計、互動設計、app UI、設計趨勢、智慧財產以及服務設計等。我們試圖讓更多讀者了解設計師們的巧思,並推廣 Design Thinking 的思維,歡迎大家加入這個討論園地。

Related Posts

留下你的看法: