75статья

Мы отказались от выпадающих списков

Опубликовал Александр Иваничкин, 7 августа 2014

Как большое количество позиций в выпадающих списках заставило нас полностью изменить интерфейс.

Все видели и знают, что это такое:

Это выпадающий список HTML, который изобрели еще в 1995 году и описали в спецификации HTML 2.0. Большинство из нас не представляет без них интерфейсов, но иногда работать с выпадающими списками тяжело. Давайте рассмотрим причины.

Вначале все хорошо

Если пользователю необходимо что-то выбрать из нескольких вариантов, простым и недорогим решением был бы выпадающий список. Его поддерживают новые и старые браузеры, он содержит много полезных возможностей: таких, как группировка, навигация с помощью клавиатуры, возможность выбора одной или нескольких позиций, надежная кросс-платформенная визуализация, не требующая мозговых усилий. Это просто работает!

Почему же это не использовать?

В Tradeshift мы несколько месяцев работали над обновлением для интерфейса, который позволял устанавливать расценки, оформлять заказы на покупку и выставлять счета. Чаще всего это деловая документация, создание которой требует концентрации и работы со значительным объемом данных. К счастью, у пользователей есть доступ к уже существующим различным источникам, что потенциально делает генерацию документов быстрее. Все данные представлены как списки, и, независимо от устройства, интерфейс должен помогать пользователю выбирать необходимое быстро и результативно.

Внедрять возможность выбора проще с помощью чекбоксов, радиобаттонов или выпадающих списков. Тем не менее, у этих элементов есть ограничения, которые выявила наша команда дизайнеров. Рассмотрим несколько основных недостатков выпадающего списка, которые в определенной мере можно отнести к чекбоксам и радиобаттонам:

  • Часто количество вариантов выбора измеряется сотнями, поэтому в стандартном выпадающем списке трудно ориентироваться.
    Пример: перечень единиц измерения в счёте может содержать множество различных наименований. Это не только часы, метры, литры, килограммы, фунты и штуки, а также такие необычные, как бочки, сифоны, «абстрактные тонны» и «мешки для сыпучих продуктов». Tradeshift занимается международной торговлей и соответствующие стандарты должны быть учтены. Нам необходимо было предоставить пользователям выбор из множества вариантов и стандартные выпадающие списки явно не подходили.Более общий пример — выбор страны. Мне, допустим, часто неудобно искать Соединённые Штаты в большинстве выпадающих списков, как бы толково не были отсортированы страны. Из-за «популярности» Соединенные Штаты часто размещают сверху. В других случаях Афганистан стоит выше всех — по алфавиту. Иногда Соединённые Штаты (US) находятся далеко внизу, после Объединенных Арабских Эмиратов (UAE). Эх! Более того, фильтрация по мере ввода на большинстве мобильных устройств недоступна и пользователи должны листать до подходящей позиции вручную. На ПК поиск осуществлять немного проще, но он тоже ограничен необходимостью начинать ввод с первой буквы: если будете вводить Эмираты, вам не выдаст Объединенные Арабские Эмираты. Ну, вы поняли… А мы даже не начинали обсуждать, как быть с синонимами.
  • Пользователю необходимо исправить позиции в выпадающих списках.
    Пример: мы предлагаем пользователям выбирать из ряда налогов по умолчанию, которые применяются к каждой единице товара в счёте. Однако, законодательство и налоги часто меняются, и мы вынуждены обеспечивать гибкость, чтобы пользователь мог добавлять и изменять параметры по умолчанию. Мы не хотим, чтобы он сам заходил в «машинный зал» (в настройки) при создании счёта. Пользователи должны иметь возможность обновлять параметры в контексте, иначе продукт станет тяжелее для восприятия. К сожалению, выпадающий список технически не может быть расширен встроенным интерфейсом. Конечно, мы можем использовать модальное окно для внесения изменений. Затем (после правки налогов) пользователь видел бы обновлённый выпадающий список. Это подходит для решения проблемы, но выглядит как «крушение» UX и вызовет путаницу у менее опытных пользователей.
  • Одни и те же данные необходимо вводить по-разному.
    Пример: сроки оплаты можно выразить относительной (30 календарных дней) или абсолютной (10 декабря 2013 года) величиной. Существует множество вариантов, как предоставить такой выбор: радиобаттоны, календари, выпадающие списки. Однако, ни один из вариантов не сможет обеспечить необходимую простоту. Нам не нужно два различных приема выбора для одной строки счёта.
  • Выпадающие списки занимают много места на экранах мобильных устройств.
    Пример: на iPhone 4 выпадающий список занимает 54% экрана (520 из 960 точек по вертикали), куда поместятся от силы 5 видимых позиций. Это в то же время ограничивает рабочую область половиной экрана (54%). Стоит признать, Android больше преуспел в этом аспекте.

    Большую часть экрана занимают лишь 5 позиций выпадающего списка. Листать через множество опций проблематично
  • Данные иерархической структуры сложно представить в виде выпадающего списка.
    Группировку позиций в выпадающем списке лучше не использовать для сложных иерархически структурированных данных. Выбор страны с последующим выбором штата — очевидный пример. Стандартное решение предполагает создание нескольких выпадающих списков. При этом взаимодействие пользователя с интерфейсом происходит так: сначала он выбирает одну позицию в выпадающем списке, закрывает его, переходит к следующему, на который надо кликать и тд. Это нетрудно сделать на ПК, но задача значительно усложняется на мобильном устройстве, ведь связь визуального с контекстным легко нарушить. Недавно Джош Брюэр, бывший главный дизайнер Твиттера, сказал:

    Мобильное устройство — это увеличительное стекло, которое раскрывает все проблемы интерфейса

    Так и есть на самом деле, и это применимо для случая с Tradeshift.

  • Выпадающие списки трудно стилизировать.
    Исторически так сложилось, что на стилизацию выпадающих списков накладывается множество ограничений, а для их преодоления написано множество скриптов-костылей. Если вы хотите, чтобы выпадающие списки хорошо сочетались с дизайном, добро пожаловать в Костыльландию! Даже если воспользоваться одним из чудесных скриптов, описанные выше проблемы не исчезнут — может вылезти еще парочка, если скрипт изменил механику колеса прокрутки, поведение сенсора или стёр стандартную «функцию поиска».

Несмотря на изначально описанные преимущества выпадающего списка, для сложных сценариев мы выявили множество минусов, что заставило нас переосмыслить необходимость использования этого стандартного элемента выбора.

Что же делать, если общепринятое решение не работает?

Мы проанализировали все существующие варианты, а также скрипты для ре-стилизации выпадающего списка и поняли, что нужно копать глубже. Обратите внимание: я не утверждаю, что мы открыли нечто потрясающее или что мы сами изобрели итоговое решение. Его вариации можно встретить повсеместно. Также у него есть свои минусы, над устранением которых мы работаем. Но самое главное, что это решение позволило пользователям вводить позиции в выпадающий список, и что оно совместимо с многими сценариями и платформами. Мы критически оценили наиболее очевидные варианты, пришли к выводу, что они нам не подходят, и разработали решение в процессе быстрого итеративного тестирования. Мы занимались описанием наших требований (некоторые упомянуты выше), генерировали идеи, делали прототипы и тестировали конечный продукт снова и снова. Мы хотели получить такой элемент интерфейса, который предоставлял бы более широкие возможности взаимодействия с пользователями, но не был бы выпадающим списком. Мы хотели унифицировать все списки в интерфейсе, чтобы пользователь знал, чего ожидать при нажатии на индикатор выбора.

Решение

Я пропущу описание самого процесса и перейду непосредственно к тому, что мы решили. Я буду использовать скриншоты, но имейте в виду, что они еще сырые. Чтобы было наглядней, я приведу несколько простых примеров создания счёта, где требуется делать выбор из множества вариантов.

Суть заключается в том, чтобы состыковать слои с необходимыми опциями, предоставляя более широкое пространство для взаимодействия:

Создание счёта на мобильном устройстве: стыковка богатых на контент слоёв даёт нам больше свободы в дизайне.

Стрелка указывает на то, что для данного поля есть варианты на выбор (конечно, навигация с помощью клавиатуры полностью поддерживается):

Стрелка на поле «Дата оплаты» (“Due”) говорит пользователю о том, что это поле можно заполнить вручную.

При нажатии на поле со стрелкой, плавно (в большинстве браузеров) выезжает панель и чтобы сконцентрировать на ней внимание, страница затемняется. Мы называем это опциональной панелью. В этом примере пользователь кликает на поле «Дата оплаты» (Due) и видит список стандартных сроков платежа:

Пользователь кликнул на поле «Дата оплаты» (“Due”) и появились опции на выбор по умолчанию, среди которых текущая подсвечена.

Если ни одна из стандартных опций не подходит, есть возможность выбрать абсолютную величину, нажимая на «Указать дату» (“Specify date”):

Второй слой предоставляет возможность указать точную дату оплаты.

Второй слой визуально расположен над первым, находясь в контексте пользователя, сохраняя положение курсора и взгляда на той же позиции. Кроме этого присутствует обратная навигация (закрыть опциональную панель можно нажатием клавиши ESC или кликом на крестик). Можно сказать, что визуальное наслоение дает чувство навигационной глубины, схожее со стилем «хлебных крошек». К сожалению, на скриншотах не покажешь плавные горизонтальные анимации, которые усиливают чувство контекста.

Выбор даты закрывает все слои панели, фокусирует внимание на изначально активном поле «Дата оплаты» (“Due”), и пользователь может двигаться дальше:

Мы вернулись на изначальную страницу, пользователь может двигаться дальше…

Другой пример — это выбор единицы измерения товара (поле, которое содержит штуки (PCS) в скриншоте выше). Текущее значение подсвечено в панели выбора:

В списке представлены лишь четыре из сотен возможных позиций. В ином случае, поиск позволяет пользователю выбрать необходимое.

Как упоминалось вначале, полный список единиц измерения насчитывает сотни значений. Небольшие компании пользуются определенными позициями всё время, поэтому вместо того, чтобы предоставлять весь список, мы показываем только недавно использованные варианты, а также поле поиска (search all unit types). В данном случае, видим поиск по слову киловатт:

Поиск быстро предоставляет варианты из обширного списка.

Выбор значения, здесь киловатт-час (KWH), закрывает панель и возвращает фокус на целевое поле:

Пользователь выбрал значение и вернулся назад.

Если нажать на поле «Единица измерение товара» (“Unit type”), киловатт-час (KWH) будет доступен как недавно использованная опция. Те, кто однажды выберут определенную единицу измерения, скорее всего используют ее снова. Таким образом, этот подход позволяет создавать индивидуальные списки без необходимости лезть в настройки:

Если заново открыть панель выбора единиц измерения, предыдущая будет доступна как опция в сокращённом списке.

Существует множество других более сложных примеров (выбор налогов), которые не отсылают пользователя к непонятно-каким-и-где-находящимся настройкам. Наше исследование показало, что если всё происходит в одном контексте, пользователи не теряются.

Такие панели впервые были предложены в ходе дискуссий о невозможности организовать комплексный выбор на небольших устройствах (источник teehanlax.com).

Идея опциональной панели появилась, когда мы разрабатывали дизайн нового Tradeshift для мобильных устройств. То есть, мы не пытались сжать настольный интрефейс до размера мобильного, а скорее наоборот. Все строки в счёте на мобильном устройстве у нас представлены в виде индикаторов выбора, а на планшете только некоторые.

Да, это требует дополнительных слоёв опциональной панели. Мы пришли к выводу, что создание даже трёх слоев позволяет пользователю не терять нить событий. Например, такой сценарий: Строка в счёте (индикатор выбора на мобильном) > Список применяемых налогов > Добавить налог.


Очевидно, без тестирования мы не применяли бы это решение для ПК. Но из всех вариантов организации множественного выбора, которые у нас были, этот оказался наиболее подходящим. Мы узнали, что по сравнению с выпадающими списками и модальными окнами, это решение значительно уменьшает когнитивную нагрузку на пользователя. Мне вспоминается комментарий Ребекки Кокс (дизайнера Quora): «Дизайн — это то, что мы не просим делать пользователей». Я полностью согласен. Пользователи должны заниматься своими делами, а не пытаться заставить работать ваше приложение.

Это не значит, что вам некуда расти. Например, мы поняли, что нужно найти способ располагать на больших разрешениях опциональную панель не строго справа, а ближе к полю.

Широкое использование

Немного позже в процессе редизайна мы поместили опциональные панели в основу навигации:

Здесь счёт лежит в основе навигации и взаимодействия.

Это позволяет использовать уже знакомый людям дизайн и не нужно отводить под опции отдельную страницу.

В заключение

Мы полюбили опциональные панели и используем их всегда, когда нужно выбрать из нескольких вариантов. Мы провели достаточно тестирований и уверены, что наши пользователи понимают и предпочитают опциональные панели сложным комбинациям выпадающих списков.

Использование этих панелей в основе навигации позволит её упростить и представить опции в контексте, не отводя под это отдельные страницы и не превращая интерфейс в неразбериху. Стало легче расставлять приоритеты над страницами для конечных пользователей, а схожесть интерфейсов для ПК и мобильных устройств упрощает взаимодействие с продуктом. Другим преимуществом стало то, что технически необходимо меньше различных элементов интерфейса.


Если вам нужно начинать с нуля и нет готовых шаблонов, стали бы вы разрабатывать «выпадающий список с большим количеством вариантов под все платформы», как этого требует нынешняя ситуация? Скорее всего нет, поэтому мы и решили задуматься.

Это перевод статьи под названием “Responsive Design: Why and how we ditched the good old select element” от Mikkel Bo Schmidt. Перевели в компании UXDepot с одобрением автора.

PS от переводчиков: Надеюсь, вам понравилась статья. Мы будем рады, если вы укажете нам на ошибки в переводе, чтобы мы могли их оперативно исправить. Пишите нам по адресу editor@uxfox.ru, пожалуйста 🙂

VK.init({apiId: 2745953, onlyWidgets: true}); VK.Widgets.Like(‘vk_like_7699’, {type: ‘button’, pageTitle: ‘Мы отказались от выпадающих списков’, pageUrl:’/responsive-design-why-and-how-we-ditched-the-good-old-select-element/’, verb: ‘0’}, 7699);

Все комментарии:

    Нет комментариев.


    Оставьте комментарий: