Создание идеального аккордеона

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

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

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

Основы аккордеона

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

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

Теперь, если мы немного повнимательнее посмотрим на костяк аккордеона , нетрудно будет увидеть все его атомарные элементы. Аккордеон всегда содержит заголовок категории, развернутое и свернутое состояние, значок, указывающий на расширение, и расстояние между ними. После расширения категории значок должен измениться, указывая на свертывание. Однако что, если пользователь нажмет на свернутую карточку, в то время как открыта другая карточка? Должна ли расширенная карта закрываться автоматически или нет? Что делать, если не все элементы могут быть отображены — должен ли пользователь автоматически прокручиваться вверх? Давайте подробнее рассмотрим эти и связанные с ними вопросы, один за другим.

Выбор значка для обозначения расширения

Теперь давайте начнем. Что мы знаем? Что ж, очевидно, что в большинстве интерфейсов с направлением слева направо название категории также будет выровнено по левому краю. Предполагая, что, как и во многих аккордеонах, подэлементы будут скользить между двумя разделами, какой значок вы бы выбрали для обозначения этого поведения? Стрелка, указывающая вниз, стрелка, указывающая направо, шеврон, указывающий вниз, плюс, плюс в кружке — может быть, что-то совсем другое?

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

Например, Slack использует стрелку, указывающую вправо, хотя элементы аккордеона скользят вертикально между заголовками категорий, а не справа от них. Теперь, в этот момент стоит спросить, какую цель должно иметь направление значка? Вероятно, он должен служить индикатором направления движения или, точнее, куда будет перемещаться взгляд пользователя после того, как значок будет нажат или нажат. Например, в Apple Mail на iOS шеврон, указывающий вправо, соответствует движению взгляда пользователя слева направо.

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

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

Тогда все проясняется? Ну не совсем.

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

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

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

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

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

Выбор положения значка

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

Должность имеет значение? На самом деле это так. Согласно статье Вигета «Тестирование дизайна и иконографии аккордеонного меню», некоторые пользователи склонны сосредотачиваться на том, чтобы нажать конкретно на иконку, а не на всю панель навигации. Это происходит по простой причине: в прошлом некоторые пользователи могли «обжечься» альтернативными реализациями аккордеона. На некоторых веб-сайтах название категории не приводит к расширению, а вместо этого идет прямо к категории. В других реализациях нажатие на навигационную панель не приводит ни к раскрытию, ни к переходу в категорию — оно абсолютно ничего не делает.

Хотя мы, конечно, спроектируем всю область так, чтобы она была целью попадания, поскольку не каждая навигация имеет такое поведение, некоторые пользователи не узнают, является ли ваша навигация одной из «плохих» или «хороших», пока они на самом деле не нажмут на нем (или наведите на него курсор). Поскольку наведение не всегда доступно, щелчок по значку кажется более безопасным — щелчок по значку почти всегда вызывает ожидаемое поведение. Это важная деталь, которую нужно знать при проектировании аккордеона.

В различных интерфейсах и реализациях казалось, что при размещении значка справа от названия категории пользователи предпочитают фокусироваться на значке чаще, чем при размещении значка слева (где пользователи нажимают на заголовок категории или пустое поле). бар). Тем не менее, некоторые пользователи по- прежнему склонны выбирать значок. Следовательно, неплохо было бы сделать иконку достаточно крупной для комфортного тапа, на всякий случай — размером не менее 44х44 пикселей .

Выровнено по левому краю, по правому краю или по правому краю? Кажется, это не имеет большого значения. Но если у вас есть группа аккордеонов (возможно, живущих в навигационном меню) с сильно различающейся длиной заголовков категорий, переключение состояний аккордеона во многих разделах потребует немного больше внимания, чем просто бег по навигационной панели сверху вниз. . Просто указатель мыши или палец должны постоянно перемещаться, чтобы попасть в этот причудливый значок! Кроме того, если значок встроен вправо, на узком экране палец должен будет перемещаться по области навигации, запутывая представление. Если бы значок располагался на правом краю панели, эта проблема была бы решена.

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

Проектирование взаимодействия для аккордеона

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

Что ж, мы можем быть совершенно уверены в одном: когда пользователь нажимает на значок, он, вероятно, ожидает какого-то расширения, поэтому нажатие на значок, безусловно, должно вызвать расширение. Однако заголовок категории можно было щелкнуть с намерением перейти прямо к категории или с намерением расширить ее.

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

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

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

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

Достаточно хорошо? Ну, мы еще не совсем там. Что делать, если пользователь нажимает на значок для расширения, но на экране недостаточно места для отображения всех подэлементов? Кто-то из вашей команды может предложить автоматически прокручивать страницу вверх , чтобы расширенная область отображалась в самом верху экрана. Это хорошая идея?

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

И тогда возникает другой вопрос: если один раздел уже развернут, а пользователь нажимает на другой раздел, должен ли первый свернуть или остаться как есть? Если первый раздел сворачивается автоматически, но это не совсем то, на что рассчитывал пользователь, он всегда может открыть его снова, но не сможет сканировать или сравнивать обе категории одновременно. Если раздел останется расширенным, им придется активно закрывать ненужную им категорию. Оба варианта имеют разумные варианты использования.

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

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

Подведение итогов

Уф, это было длинное исследование, казалось бы, очевидного шаблона проектирования. Итак, как создать идеальный аккордеон? Мы выбираем значок, указывающий на расширение (шеврон, указывающий вниз, или значок плюса), делаем его достаточно большим, чтобы было удобно нажимать, и располагаем его по правому краю панели. Вся панель навигации вызывает расширение — с достаточным отступом вокруг панели для переключения состояний и ссылкой на главную страницу категории в категории аккордеона.

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

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

Контрольный список дизайна аккордеона

1. Какой значок вы выберете для обозначения расширения?
2. Какой значок вы выберете, чтобы обозначить крах?
3. Где именно вы поместите икону?
4. Как вы разрабатываете название категории?
5. Как вы указываете свернутое и расширенное состояния (за значком)?
6. Что произойдет, если пользователь нажмет на категорию?
7. Должен ли аккордеон содержать ссылку на главную страницу категории?
8. Что произойдет, если пользователь нажмет на пустое место?
9. Должен ли расширенный раздел автоматически сворачиваться при выборе другого раздела?
10. Что делать, если недостаточно места для отображения всех элементов?
11. Должны ли у вас быть ссылка или кнопка «свернуть все/открыть все»?

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

Возможно, у вас был совсем другой опыт, чем упомянутый в статье? Дайте нам знать в комментариях к этой статье! Кроме того, если у вас есть другой компонент, который вы хотели бы охватить, сообщите нам об этом — мы посмотрим, что мы можем сделать!

Следите за обновлениями!

Эта статья является частью новой продолжающейся серии статей об адаптивных шаблонах дизайна в вашем действительно Smashing Magazine. Мы будем публиковать статью из этой серии каждые две недели. Не пропустите следующий — на причудливых (или не очень) средствах выбора даты ! Ах, заинтересованы в (печатной) книге, охватывающей все шаблоны , включая приведенный выше? Дайте нам знать в комментариях — возможно, мы сможем объединить все эти паттерны в одну книгу и опубликовать ее в Smashing Magazine. Продолжай качаться!