Визначення UX шаблонів для перетягування компонентів
Напевно ви використовуєте перетягування (Drag and Drop) у своїх повсякденних інтерфейсах – перетягуючи ланцюжки листів Gmail у папки, переміщаючи картки Trello або переставляючи місцями вкладки у Chrome. Ці взаємодії набагато складніші, ніж ви думаєте. Це починаєш розуміти при розробці шаблонів перетягування в VMware.
Такі взаємодії, як перетягування, часто залишаються непоміченими. Іноді вони відбуваються настільки природно, що ви навіть цього не усвідомлюєте. Але, якщо ви уважно подивитеся і порівняйте ці три приклади, кожен із них демонструє дуже різні UX стандарти перетягування.
Немає нічого поганого в тому, що ці інтерфейси мають різні UX стандарти перетягування. Кожен інтерфейс, напевно, вибрав певні патерни з якоїсь причини. Наприклад, Trello, можливо, вибрали нахилення карток при перетягуванні, тому що ця поведінка відповідає їх дружній мові дизайну.
Але проблема полягає в тому, що немає чітких UX стандартів для перетягування в інтерфейсі. Ви можете зіткнутися з прикладами, коли перетягування чогось в одній частині інтерфейсу є зовсім іншим досвідом в іншій його частині.
Щоб проілюструвати це, давайте подивимося на доступну бібліотеку перетягування Salesforce. Вона демонструє п’ять паттернів перетягування, кожен з яких представляє собою зовсім інший досвід.
В той час, як було зроблено багато зауважень щодо доступності (дивіться цікаву статтю на цю тему), на жаль, в цих п’яти моделях мало узгодженості дизайну. У кожному із п’яти шаблонів використовується різний курсор, а в якості інструментів перетягування використовуються три різні іконки:
Хіба іконка з трьома лініями вказує на елемент, що перетягується? Або іконка з трьома крапками? Який із п’яти курсорів показує, що я можу перетягувати елементи? Це збиває з пантелику, адже всі п’ять шаблонів застосовуються в одному інтерфейсі!
У дизайн-системі компоненти повинні виглядати і відчуватися як єдине ціле. Подібним чином, взаємодія з перетягуванням має виглядати і відчуватися узгодженою між компонентами в інтерфейсі.
Системи дизайну не просто створюють узгодженість між компонентами інтерфейсу – вони також повинні виступати за послідовний досвід.
Аналіз прикладів
Це UX кейс-стаді, присвячене шаблонам перетягування (Drag and Drop), на прикладі роботи в VMware для їх системи дизайну Clarity. Clarity використовує відкритий вихідний код, тому їх користувачі – це не тільки співробітники VMware, але і всі, хто хоче використовувати їх бібліотеки на основі Angular або посібники з дизайну.
Ці користувачі просили додати можливість перетягувати деякі компоненти інтерфейсу: ієрархічна (деревоподібна) структура, datagrid (таблиця даних) і картки. Задача полягала в тому, щоб уніфікувати призначений для користувача досвід у всіх наступних випадках використання, пов’язаних з перетягуванням:
Випадки використання
- Зміна порядку і вкладення вузлів у ієрархічній структурі
- Упорядкування стовпців у datagrid
- Упорядкування рядків у datagrid
- Перетягування між ієрархічною структурою і datagrid
- Реорганізація і злиття карт
У перевантажених даними інтерфейсах, таких як у VMware, перетягування має вирішальне значення для того, щоб користувачі могли організувати складні і великі обсяги даних.
Створення бібліотеки
Починати довелося зі створення невеликої бібліотеки простих, але ефективних дизайнерських можливостей, які представляють перетягування і пов’язують воєдино окремі приклади перетягування. Таким чином, доступність може бути застосована до нових варіантів використання, які не перераховані вище.
Якщо ви працюєте в команді системи дизайну, це може допомогти вам почати думати про те, як поводитися з шаблонами перетягування для вашої власної системи дизайну.
1. Фіолетовий колір
Вибирайте колір, який не часто використовується у вашій дизайн-системі для визначення взаємодії перетягування. Уникайте кольорів, які вже мають значення у вашому інтерфейсі (наприклад, червоний для деструктивних дій).
Для перетягування був обраний фіолетовий колір. Фіолетовий не є основним кольором, що використовується в Clarity, тому, коли користувачі стикаються з ним, вони можуть очікувати перетягування. Навмисне уникання використання синього (який є загальноприйнятим кольором для перетягування) було зроблено тому, що в Clarity він зарезервований для кнопок дій та інших клікабельних елементів.
2. Стилі стану
Встановіть стилі для різних станів елемента, який перетягується. Вкажіть, який саме візуальний вплив отримає елемент під час його перетягування, після його перетягування і т.д.
У Clarity, коли елемент перетягується, він буде мати наступні стилі:
Додавання тонкої тіні створює враження, що елемент фактично знімається зі сторінки.
Інший стан, який було додано, був вихідною позицією елемента під час його перетягування, що називається попереднім станом.
Це діє як невелике нагадування користувачам, де елемент був раніше. Зверніть увагу, що цей стан не буде застосовуватися для природного перетягування, при якому інші елементи природним чином змінюють своє місце розташування через елемент, що перетягується.
3. Системні курсори
Використовуйте системні курсори, щоб вказати, коли елемент перетягується. Це здається незначним, але це поліпшить можливість виявлення елементів, які можна перетягнути.
Для Mac у VMware використовується grab (розкрита долоня Міккі Мауса) і grabbing (закрита долоня Міккі Мауса) курсори. Grab курсор відображається при наведенні, коли елемент можна перетягувати. Якщо почати його перетягувати, курсор переключиться на grabbing курсор. Для областей, де елемент не можна перетягувати, використовується unavailable курсор.
Для Windows використовується move курсор (схрещені стрілки). Курсор залишиться таким же при переміщенні елемента. Знову ж таки, для областей, де елемент не можна перетягувати, використовується unavailable курсор.
4. Цільові пункти переміщення
Встановіть шаблони для цільових пунктів переміщення – областей, куди можна перетягувати елементи. Подібно стилям стану, згаданим вище, явно виписуйте, які стилі є у цільових пунктів переміщення.
Оскільки перевпорядкування є ключовою взаємодією перетягування, було вказано позицію цільового пункту переміщення, яка вказує куди елемент буде перенесений.
З лівого боку цільової позиції VMware додали коло, щоб ще більше відрізнити цільовий пункт переміщення від звичайної лінії або кордону. Це важливе доповнення, особливо для користувачів, які страждають від колірної сліпоти та можуть не помітити зміни кольору.
Маркери
Чи потрібно додавати маркери перетягування, залежить від кожного конкретного випадку. Маркери перетягування – маленькі значки, які вказують, що елемент можна перетягувати. Gmail вибрав значок з 12 крапками для такого маркера, в той час, як VMware обрали значок з шістьма крапками:
Наявність маркерів перетягування багато в чому залежить від контексту. Для компонентів, які зазвичай не пов’язані з перетягуванням, маркер перетягування допомагає користувачам виявляти перетягування як доступну дію. Але в тих випадках, коли перетягування завжди є очікуваною поведінкою, в маркерах немає потреби.
Наприклад, не треба додавати маркери в деревоподібній структурі, якщо переміщення по вузлах дерева здається очевидним. Однак, можна додати маркери для карток, якщо не всі картки можна перетягувати.
Існує багато різних значків, що використовуються для подання маркерів перетягування, але вибирайте тільки один і дотримуйтеся його.
На закінчення
Ці стандарти допоможуть створити основу для додавання перетягування для вашого інтерфейсу, але є також багато інших способів стандартизації перетягування компонентів.
Налаштування будь-якого стандарту UX допоможе перетворити перетягування у звичну взаємодію. Подивіться, як поєднуються всі варіанти використання перетягування після застосування бібліотеки можливостей: Invision.
