Что означают галочки переключатели на экране прототипа

Ин­клю­зив­ные ком­по­нен­ты: меню и кноп­ки меню

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

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

Классический пример — термин «выпадающий список» (dropdown). В интерфейсах многие вещи «выпадают», включая в , и подменю навигации со списком ссылок, которое раскрывается с помощью JavaScript. Одинаковые названия — разные явления. Некоторые называют это «выпадающее меню» (pull-down menu), но давайте не вдаваться в подробности.

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

Давайте начнём с вопроса: является ли блок ссылок с картинки, выпадающий вниз из панели навигации, меню?

Правильный ответ: нет, это не настоящее меню.

То, что навигационная схема состоит из списков или ссылок — давнее соглашение. Оно почти так же давно предписывает, что дополнительная навигация (sub-navigation) должна быть вложенными списками со ссылками. Если бы я удалил стили для компонента, показанного выше, я бы увидел что-то вроде этого списка ссылок, только с Times New Roman и синего цвета.

• [Главная](#) • [О нас](#) • [Магазин](#) ◦ [Одежда для собак](#) ◦ [Вафельницы](#) ◦ [Магические шары](#) • [Контакты](#) 

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

В этом месте часто ошибаются и начинают добавлять семантику из WAI-ARIA: aria-haspopup=»true» , role=»menu» , role=»menuitem» и так далее. Их можно использовать, но в другом контексте. Вот две причины для этого:

1. ARIA-меню предназначены не для навигации, а для десктопных приложений. Представьте себе систему меню для любого из них.
2. Ссылка верхнего уровня должна быть ссылкой. То есть она не ведёт себя как кнопка меню.

Относительно второго пункта: при перемещении по области навигации в подменю ожидаешь, что каждое подменю будет появляться при наведении или при фокусе на ссылке верхнего уровня (например, «Магазин» из примера выше). Это одновременно показывает подменю и размещает ссылки в нём в порядке получения фокуса. С помощью JavaScript можно управлять событиями фокуса (focus) и его потери (blur) и сохранить внешний вид подменю пока это необходимо. При этом те, кто использует для навигации клавиатуру, должны иметь возможность переходить по очереди от одной ссылки каждого уровня к другой.

Кнопки меню, которым задан атрибут aria-haspopup=»true» , так себя не ведут. Они становятся активными по клику и у них нет другой цели кроме показа скрытого меню.

Как показано на картинке, вне зависимости от того раскрывается меню или скрывается, это будет объявлено благодаря атрибуту aria-expanded . Вам нужно только изменить это состояние при клике, а не при фокусе. Пользователи обычно не ожидают явного изменения состояния при простом событии фокуса. На самом деле в нашей системе навигации состояние не изменяется. Это просто трюк со стилизацией. С точки зрения поведения мы можем перемещаться с помощью клавиши Tab так, как если бы не было никакого трюка с показом и скрытием элемента.

Проблема с навигационными подменю Скопировать ссылку

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

Здесь есть два возможных варианта решения проблемы:

1. Избежать поведения по умолчанию ссылок верхнего уровня ( e.preventDefault() ) и написать скрипт для полной поддержки семантики и поведения меню WAI-ARIA.
2. Убедиться, что каждая страница, на которую ведёт ссылка верхнего уровня меню, имеет оглавление в качестве альтернативы подменю.

Первое решение не самое хорошее. Я ранее замечал, что этот тип семантики и поведения нежелателен в данном контексте, где ссылки — это управляемые контролы (subject controls). Кроме того пользователи больше не смогут переходить на страницу верхнего уровня, если она есть.

Какие устройства — сенсорные? Скопировать ссылку

Заманчиво думать: «Это не самое хорошее решение, но я применю его только для сенсорных интерфейсов». Проблема в том, как определить, есть ли у устройства сенсорный экран?

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

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

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

Похоже, получившая премию команда Government Digital Services с этим согласится. Вы также могли видеть такие оглавления в Wikipedia.

Оглавление Скопировать ссылку

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

Примечания Скопировать ссылку

• В этом примере мы представляем каждый раздел как отдельную страницу, как если бы это было в выпадающем подменю.
• Важно, чтобы каждая страница из «Магазин» имела одинаковую структуру. Поэтому оглавление «Продукты» находится в одном и том же месте. Консистентность улучшает понимание.
• Список группирует элементы, а вспомогательные технологии могут установить их количество и объявить о них, например, с помощью синтезированного голоса в скринридерах.
• Тегу заголовок задан с помощью атрибута aria-labelledby . Это означает, что большинство скринридеров объявит «Продукты, навигация» при попадании в область с помощью клавиши Tab . Также это приведёт к тому, что такая навигация будет разбита скринридерами на отдельные элементы, через которые пользователи смогут переходить к областям страницы напрямую.

Всё на одной странице Скопировать ссылку

Если вы можете поместить все разделы на одной странице, при этом не сделав её слишком длинной и избежав утомительной прокрутки, то так даже лучше. Просто задайте для каждого раздела якорную ссылку. Например, href=»#waffle-irons» должна вести к id=»waffle-irons» .

Примечание: в некоторых браузерах фокус плохо переносится на отдельные фрагменты страницы. Добавление tabindex=»-1″ к нужному фрагменту исправляет это.

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

На некоторых сайтах, включая правительственный цифровой сервис gov.uk, есть страницы с указателями (или «темами»), которые представляют собой просто оглавления. Это настолько мощная концепция, что популярный генератор статических сайтов Hugo создаёт такие страницы по умолчанию.

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

Кнопки навигационного меню Скопировать ссылку

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

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

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

1. Быть кнопкой, а не ссылкой.
2. Содержать информацию о развёрнутом или свёрнутом состоянии соответствующего меню (которое, строго говоря, представляет собой просто список ссылок).

Прогрессивное улучшение Скопировать ссылку

Давайте не будем забегать вперёд. Мы должны помнить о прогрессивном улучшении и подумать, как это будет работать без JavaScript.

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

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

Вы улучшите его, добавив кнопку, которая в исходном состоянии скрывает навигацию с помощью атрибута hidden :

Некоторые более старые браузеры, сами знаете какие, не поддерживают hidden , так что не забудьте учесть это в вашем CSS. Селектор ниже решит эту проблему, так как display: none делает то же самое, что и атрибут hidden : скрывает меню от вспомогательных технологий и удаляет ссылку из порядка получения фокуса.

[hidden]

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

Расположение Скопировать ссылку

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

Вот как мы можем переключить состояние:

var navButton = document.querySelector('nav button'); navButton.addEventListener('click', function() < let expanded = this.getAttribute('aria-expanded') === 'true' || false; this.setAttribute('aria-expanded', !expanded); let menu = this.nextElementSibling; menu.hidden = !menu.hidden; >); 

ARIA-controls Скопировать ссылку

Как я уже писал в «Aria-controls Is Poop», атрибут aria-controls , который помогает пользователям скринридеров при переходе от контролирующего элемента к контролируемому, поддерживается только в JAWS. Так что на него нельзя положиться.

Без хорошего метода перемещения между элементами, вам нужно убедиться в том, что одно из следующего верно:

1. Первая ссылка раскрывающегося списка — следующая в порядке фокуса после кнопки (как в предыдущем примере кода).
2. При раскрытии списка на первую ссылку сделан фокус.

В нашей ситуации я рекомендовал бы первый вариант. Это намного проще, так как не нужно беспокоиться о перемещении фокуса обратно на кнопку и о том, какие события для этого нужны. Кроме того, сейчас нет ничего, что могло бы предупредить пользователей о том, что фокус будет перемещён в другое место. В настоящих меню, которые мы вскоре обсудим, за это отвечает aria-haspopup=»true» .

Использование aria-controls на самом деле не приносит большого вреда, за исключением того, что делает объявления в скринридере более подробным. Однако некоторым пользователям JAWS это может быть нужно. Вот как будет использоваться атрибут вместе с id для списка:

Меню и роли menuitem Скопировать ссылку

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

Поскольку наше навигационное меню начинает вести себя как «настоящее» меню, не должно ли тут быть ролей menuitem ?

Краткий ответ — нет. Более подробный ответ: нет, потому что наши элементы списка содержат ссылки, а элементы menuitem не могут иметь интерактивных потомков. То есть они являются контролами в меню.

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

То, что у нас осталось, это своего рода гибридный компонент, который не совсем настоящее меню, но, по крайней мере, сообщает пользователям, открыт ли список ссылок, благодаря состоянию aria-expanded . Это подходящий паттерн для навигационных меню.

Примечание. Элемент Скопировать ссылку

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

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

Однако, так же как и с переключателем, основанном на чекбоксе, мы используем элемент, связанный со вводом данных, а не просто делаем выбор. Это может запутать многих пользователей, тем более, что этот шаблон использует JavaScript, чтобы выбранный элемент вёл себя как ссылка. Неожиданное изменение контекста, которое это вызывает, считается ошибкой согласно критерию 3.2.2 On Input (Level A).

Настоящие меню Скопировать ссылку

Теперь, когда мы обсудили ненастоящие меню и квази-меню, пришло время создать настоящее меню, которое открывается и закрывается настоящей кнопкой меню. С этого момента я буду называть вместе кнопку и меню — «кнопкой меню».

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

Как я уже упоминал, эти соглашения пришли из дизайна десктопных приложений. ARIA-атрибуты и управление фокусом с помощью JavaScript необходимы для их полной имитации. Одна из целей ARIA — помочь веб-разработчикам создавать сложные веб-интерфейсы и не нарушать при этом устоявшие паттерны взаимодействия, пришедшие из реального мира.

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

 Сложность ▾  
Лёгкая Средняя Очень высокая 
 

Примечания Скопировать ссылку

• aria-haspopup просто указывает на то, у кнопки есть скрытое меню. Это работает как предупреждение о том, что при нажатии на кнопку пользователь будет перемещён в выпадающее меню (скоро мы рассмотрим поведение фокуса). Его значение не меняется: оно всегда true .
• Элемент внутри кнопки содержит символ Юникод с маленьким чёрным перевёрнутым треугольником. Он визуально показывает, что нажатие на кнопку раскроет что-то под ней. Этого aria-haspopup не может показать. Атрибут aria-hidden=»true» не разрешает скринридерам объявлять «перевёрнутый треугольник» или что-то подобное. Благодаря aria-haspopup этого не нужно делать в невизуальном контексте.
• aria-haspopup дополняет aria-expanded . Атрибут сообщает пользователю, находится ли он в данный момент в открытом (развёрнутом) меню или оно закрыто (свёрнуто), переключаясь между значениями true и false .
• Само меню имеет (точно названную) роль menu . Для него нужны потомки с ролями menuitem . Они не обязательно должны быть прямыми потомками элемента menu . В этом примере так сделано для простоты.

Клавиатура и поведение при фокусе Скопировать ссылку

Когда дело доходит до того, чтобы сделать интерактивные контролы доступными для клавиатуры, лучшее, что вы можете сделать, это использовать правильные элементы. Поскольку здесь используются элементы , то мы можем быть уверены в том, что события по клику будут срабатывать при нажатии клавиш Enter и Space , как указано в HTMLButtonElement interface. Также это означает, что мы можем отключить пункты меню, используя связанное с кнопкой свойство disabled .

Есть намного больше способов взаимодействовать с кнопкой с клавиатуры. Вот краткий обзор поведения при фокусе с клавиатуры, которое мы будем реализовывать на основе WAI-ARIA Authoring Practices 1.1:

• Enter , Space или ↓ на кнопке меню — открывает меню.
• ↓ на пункте меню — перемещает фокус к следующему пункту меню или к первому, когда вы дошли до последнего пункта.
• ↑ на пункте меню — перемещает фокус к предыдущему пункту меню или к последнему, если вы находитесь на первом.
• ↑ на кнопке меню — закрывает меню, если оно открыто.
• Esc на пункте меню — закрывает меню и перемещает фокус на кнопку меню.

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

Добавление tabindex=»-1″ к пунктам меню делает их недоступными для фокуса с помощью Tab , но сохраняет возможность фокуса на элементах при нажатии на клавиши со стрелками.

 Сложность ▾  
Лёгкая Средняя Очень высокая 
 

Метод open Скопировать ссылку

Мы можем создать методы для обработки различных событий как часть продуманного дизайна API.

Например, метод open нужен для переключения значения aria-expanded на true , изменить значение меню hidden на false и сделать фокус на первом элементе меню с menuitem , который не скрыт:

MenuButton.prototype.open = function ()

Мы можем исполнить этот метод, когда пользователь нажимает клавишу вниз на кнопке меню, на которой сделан фокус:

this.button.addEventListener('keydown', function (e) < if (e.keyCode === 40) < this.open(); >>.bind(this)); 

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

exampleMenuButton = new MenuButton( document.querySelector('[aria-haspopup]') ); exampleMenuButton.open(); 

Примечание. Хак с чекбоксом Скопировать ссылку

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

В случае с кнопками меню желание сделать их «работающими без JavaScript» привело к появлению так называемого хака с чекбоксом. В нём состояние checked (или unchecked ) скрытого чекбокса используется для переключения видимости элемента меню с помощью CSS.

/* Меню закрыто */ [type="checkbox"] + [role="menu"] < display: none; >/* Меню открыто */ [type="checkbox"]:checked + [role="menu"]

Для пользователей скринридеров роль чекбокса и состояние checked бессмысленны в этом контексте. Это можно частично исправить, добавив role=»button» для чекбокса.

К сожалению, это отменяет взаимодействие со встроенным состоянием checked , лишая нас обратной связи о состоянии элемента без JavaScript (что плохо, хотя в этом контексте это было бы так же связано с состоянием checked ).

Но это возможно имитировать с помощью aria-expanded . Нам просто нужно добавить наш лейбл к двум элементам со , как показано ниже.

  Сложность развёрнуто свёрнуто ▾  

Оба этих элемента визуально скрыты благодаря классу visually-hidden , но, в зависимости от того в каком состоянии мы находимся, только один из них скрыт от скринридера. То есть только одному задано свойство display: none и это определяется установленным (но не объявляемым) состоянием checked :

/* Класс, который скрывает визуально элементы со */ .vh < position: absolute !important; clip: rect(1px, 1px, 1px, 1px); padding:0 !important; border:0 !important; height: 1px !important; width: 1px !important; overflow: hidden; >/* Отобразить правильное состояние для скринридеров с помощью текущего состояния элемента */ [type="checkbox"]:checked + label .expanded-text < display: inline; >[type="checkbox"]:checked + label .collapsed-text < display: none; >[type="checkbox"]:not(:checked) + label .expanded-text < display: none; >[type="checkbox"]:not(:checked) + label .collapsed-text

Это разумное решение, но работа над нашей кнопкой меню всё ещё не закончена. Ожидаемое поведение фокуса, которое мы обсудили, просто не может быть реализовано без JavaScript.

Такое поведение принято и предсказуемо, оно делает кнопку более удобной. Однако, если вам действительно нужно сделать кнопку меню без JavaScript, то это самый подходящий вариант. Учитывая то, что урезанная кнопка навигационного меню, которую я рассмотрел ранее, предлагает контент меню, который не зависит от самого JavaScript (то есть ссылки), этот подход может быть подходящим вариантом.

Примечание: меню открывает только пробел.

Событие choose Скопировать ссылку

Исполнение некоторых методов должно вызывать события, чтобы мы могли настроить обработчики событий. Например, мы можем транслировать событие choose , когда пользователь кликает по пункту меню. Мы можем установить это с помощью CustomEvent , которое даёт нам возможность передавать аргумент в свойство события detail . В этом случае аргумент ( choice ) будет узлом DOM выбранного пункта меню.

MenuButton.prototype.choose = function (choice) < // Определить событие 'choose' var chooseEvent = new CustomEvent('choose', < detail: < choice: choice >>); // Передать событие (Dispatch the event) this.button.dispatchEvent(chooseEvent); return this; > 

Есть много всего, что мы можем сделать с помощью этого механизма. Возможно, у нас есть live region с id со значением menuFeedback :

Теперь мы можем настроить обработчик событий и заполнить live region информацией, скрытой внутри события:

exampleMenuButton.addEventListener('choose', function (e) < // Получить текст узла (label) var choiceLabel = e.details.choice.textContent; // Получить узел live region var liveRegion = document.getElementById('menuFeedback'); // Заполнить live region liveRegion.textContent = `Your difficulty level is $`; >): 

При выборе пункта меню пользователь скринридера услышит: «Вы выбрали [название пункта меню]». Изменения контента live region (которому задан здесь атрибут role=»alert» ) объявляются скринридерами при каждом его обновлении. Live region не является обязательным, но это пример того, что может произойти в интерфейсе, когда пользователь сделал выбор в меню.

Сохранение выбора Скопировать ссылку

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

Атрибут aria-checked=»true» работает для элементов, которым вместо menuitem задана роль menuitemradio . Расширенная разметка со вторым выбранным элементом (установленным) выглядит так:

 Сложность ▾  
Лёгкая Средняя Очень высокая 
 

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

[role="menuitemradio"][aria-checked="true"]::before

При перемещении по меню с запущенным скринридером при фокусе на этом выбранном элементе он объявит что-то вроде: «Галочка, средний, пункт меню, выбрано».

Поведение при открытии меню с выбранным menuitemradio немного отличается. Вместо того, чтобы сделать фокус на первом (включённом) элементе в меню, фокус устанавливается на выбранном элементе.

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

Использование кнопки меню с помощью скринридера Скопировать ссылку

В этом видео я покажу вам как использовать кнопку меню в VoiceOver и Chrome. В примере используются элементы с ролью menuitemradio , атрибутом aria-checked и обсуждается поведение кнопки при фокусе. Таким образом ведут себя и другие популярные скринридеры.

Расшифровка Скопировать ссылку

Хейдон: Это кнопка меню со сложностью и я собираюсь протестировать её на VoiceOver в Chrome. Для начала я сделаю фокус на самой кнопке.

VoiceOver: Сложность, всплывающая кнопка.

Хейдон: Сначала вы услышите «Сложность» — это подпись. Затем «всплывающая кнопка», что означает её состояние, что ей задано area-expanded=»false» и что она всплывающая, потому что для неё установлено значение true в атрибуте aria-haspopup . Сейчас я открою меню с помощью клавиши со стрелкой вниз.

VoiceOver: Галочка, очень сложно, пункт меню, выбран, меню, пять пунктов.

Хейдон: Здесь много информации. Для начала «Галочка, очень сложная». Это подпись. Я использую псевдоэлемент для того, чтобы добавить галочку. «Пункт меню», потому что в этом случае это пункт меню с ролью menuitemradio . «Выбран», потому что задан атрибут aria-checked со значением checked . И также вы слышите, что в меню пять пунктов. Это потому, что этот пункт меню вместе с другими находится внутри элемента, которому задана роль menu . Сейчас я нажму на кнопку со стрелкой вниз, чтобы сделать фокус на пункте «Очень высокая».

VoiceOver: Очень высокая, пункт меню.

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

VoiceOver: Сложность, всплывающая кнопка.

Хейдон: Это закрывает меню и перемещает фокус на саму кнопку меню «Сложность». Итак, вы вернулись туда, откуда начали.

Инклюзивная кнопка меню на Github Скопировать ссылку

Я и Хьюго Жирадель вместе работали над созданием компонента кнопки меню с фичами API, которые я описал, и ещё многим другим. Вы должны поблагодарить Хьюго за многие из этих фич, так как они основывались на работе над a11y-dialog — доступным модальным окном. Он есть на Гитхабе и в npm.

npm i inclusive-menu-button --save 

Кроме того, Хьюго сделал специально для вас версию кнопки на React.

Чеклист Скопировать ссылку

• Не используйте семантику ARIA для меню в случае с системами навигационных меню.
• На сайтах с большим количеством контента не скрывайте структуру в выпадающих меню.
• Используйте aria-expanded у кнопок для того, чтобы сообщить о том, что навигационное меню открыто или закрыто.
• Убедитесь, что навигационное меню следующее в порядке фокуса после кнопки, которая его открывает и закрывает.
• Никогда не жертвуйте юзабилити ради решений без JavaScript. Это заносчиво.

Как прогресс ухудшил жизнь продвинутых пользователей (и как это исправить)

Я не люблю нытьё «раньше трава была зеленее» и в целом рад техническому прогрессу. Но считаю, что вместе с развитием компьютеров произошли и некоторые перемены, которые ухудшили жизнь «продвинутых пользователей» (power users) в угоду массовому пользователю. Перемены, которые мешают людям использовать технологии максимально эффективно.

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

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

Вижу три больших технологических рывка, которые чем-то делали хуже:

1. Мобильная революция

Когда смартфоны стремительно захватывали мир, я смотрел на это завороженно. Теперь у людей есть почти повсеместный интернет-доступ! Можно хоть с горной тропы загуглить любую информацию, управлять банковским счётом, делать покупки!

Сейчас я по-прежнему считаю, что это всё очень здорово. Но со временем заметил в популяризации смартфонов и проблему для людей вроде меня.

Для многих массовых пользователей смартфон стал главным устройством не только на горной тропе, но и дома. А для меня дома компьютер остаётся вне конкуренции. Физическая клавиатура, большой экран и возможности вроде «Ctrl+F» позволяют мне быть ощутимо продуктивнее, даже когда речь не о работе, а о бытовых вопросах вроде покупок в интернет-магазинах.

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

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

А даже если компьютерная версия есть, мобильная революция может лишать её части возможностей. Вот пример: в 2019-м Apple добавили в macOS новое видеоприложение TV. И запустив его, я обнаружил, что не могу в нём переключаться между полями с помощью клавиши Tab, как порой делаю в других приложениях. Хотя в настройках macOS у меня проставлена галочка «Press the Tab key to move focus forward».

Почему компания Apple, которая добавила в настройках эту галочку, сама же в собственном приложении не поддерживает её? Если правильно понимаю, дело в том, что изначально приложение TV появилось в iOS. И на Mac перенесли уже имевшиеся мобильные наработки, внеся минимум изменений по сравнению с айпадами. А на айпадах, понятно, обычно пользуются не кнопкой Tab. Так мобильный мир ворвался на десктоп и отнял уже привычную возможность.

Массовый пользователь, который привык тыкать мышкой и не пользуется клавишей Tab, вообще не заметит тут никакой проблемы. А я замечаю и она для меня не смертельна, но неприятна. Если что, тут ни в коем случае не пытаюсь принизить «обычных пользователей» и представить их способ использования как «неполноценный». Им удобно «как на айпаде» — да пожалуйста, только рад за них. Хочу сказать только, что люди вроде меня тоже существуют, и из-за расцвета мобильных устройств нам сделали хуже.

2. Интернет-революция

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

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

Есть очевидная часть, о которой и без меня часто пишут: когда данные не локально у тебя, а где-то в облаке, ты лишаешься контроля над ними (могут взять и удалить завтра из стриминга твой любимый альбом). А продвинутые пользователи любят всё контролировать.

Есть чуть менее очевидная часть, сожаления о которой вижу реже: когда данные в облачном сервисе, то лишаешься контроля ещё и над способом взаимодействия с ними. Медиафайл c диска можно запустить разными плеерами, выбирай подходящий тебе хоть до посинения. А вот стриминг-сервис предлагает какой-то один интерфейс, сиди с ним и «ешь что дают», даже если что-то не нравится и хочется богатых возможностей «как в VLC». Сужается выбор, а для «продвинутых» пользователей возможность выбора важна.

А вот ещё менее распространённая жалоба, которая есть у меня: по-моему, эти безальтернативные веб-интерфейсы облачных сервисов в среднем хуже подходят для power users, чем интерфейсы «устаревших» десктопных приложений. У нативных приложений чаще встречаю хоткеи и меню, которым можно пользоваться с клавиатуры, а в вебе знай себе клацай мышкой. Есть браузерные расширения вроде SurfingKeys для управления сайтами с клавиатуры, они частично улучшают ситуацию, но всё-таки это костыль.

3. Мышиная революция

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

Поймите меня правильно. И мыши, и GUI — замечательные изобретения, я рад, что они есть. И я совершенно не призываю отказаться от мыши, например, при работе в графических редакторах, там она очень полезна.

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

Вот, например, Telegram. В целом замечательно к нему отношусь, это ещё хороший случай. И в его macOS-приложении в принципе задумывались о хоткеях (спасибо за это): по нажатию на Cmd+? вылезает справка по ним, целый ряд действий возможно сделать с их помощью. Но всё-таки активно пользоваться Telegram на маке без мышки/трекпада, если правильно понимаю, почти невозможно. Для кучи действий (например, прикрепить к сообщению файл) в списке хоткеев ничего не указано.

Чтобы это обойти, я даже искал версию Telegram для командной строки. Теоретически она существует. А практически она не обновлялась семь лет, и у меня не получилось её запустить.

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

В итоге все мои попытки как следует выучить хоткеи и по-настоящему уйти от мышки проваливались. Отчасти ощущаю это своей слабостью, а отчасти сопротивлением среды. И мне печально, что среда сопротивляется эффективной работе с ней, навязывая менее эффективную. А если бы мышку/GUI никогда не придумали и мы все сейчас сидели бы в командной строке, среда бы так не сопротивлялась.

Как улучшить ситуацию

Я написал это всё не просто для того, чтобы поныть «как всё плохо». Мне интереснее не вопрос «кто виноват», а вопрос «что делать». И мне кажется, что тут есть частичный ответ.

Да, где-то исправить ситуацию вряд ли получится. Если у сервиса есть только мобильная версия из-за того, что бюджет позволял сделать только её — тут вряд ли можно что-то изменить, бизнес не станет изыскивать ресурсы просто для того, чтобы порадовать нескольких гиков.

Но есть и другие ситуации. Подозреваю, что в эппловском приложении TV нельзя воспользоваться кнопкой Tab не из-за бюджетных/технических ограничений (много ли ресурсов надо это исправить?), а просто потому что об этом никто не подумал. Люди, привыкшие к айпадам, потыкали курсором в разные места и сказали «всё работает».

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

По-моему, с «продвинутыми пользователями» отчасти похоже: проблемы, возникающие у них, может быть сложно заметить человеку со стороны, у которого паттерны использования ПО отличаются. И при проверке приложения TV для него всё выглядит хорошо. Но достаточно было бы одного человека, лично пользующегося кнопкой Tab, чтобы донести до Apple, что их общий принцип из ОС здесь сломался.

Так что был бы рад, если бы возникло какое-то понятие в духе accessibility, но о потребностях опытных пользователей. Если бы, помимо проверок «каково пользоваться нашим продуктом без зрения», проводили ещё и проверки «каково пользоваться нашим продуктом без мышки и телефона».

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

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

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

Давайте сделаем софт чуть-чуть продвинутее.

Напоследок минутка рекламы. Мы в JUG Ru Group сейчас проводим осенний сезон конференций: уже сегодня в 16:00 стартует Mobius по мобильной разработке, завтра HolyJS (понятно, про JavaScript), в конце ноября новая конференция по системному и бизнес-анализу Flow. Если какая-то из этих тематик пересекается с вашей деятельностью, советую обратить внимание.

Что значит термин интерфейс и 18 видов его реализации

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

Что такое интерфейс

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

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

Определение UI (английский — user interface) переводится как «пользовательский интерфейс». UI охватывает не только графический интерфейс, а еще и тактильный, голосовой или звуковой. В качестве инструментов взаимодействия с системами UI могут выступать:

• текстовые поля;
• кнопки и галочки;
• выпадающие списки;
• всплывающие подсказки;
• переключатели;
• элементы меню программы или сайта;
• и многое другое.

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

Какие задачи решают интерфейсы

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

Интерфейсы предназначены для решения следующих задач:

1. Ввода команд (с помощью мышки, клавиатуры, жеста и даже голоса).
2. Отправки запроса и получения ответа. Ответ может иметь форму звука, текста, изображения.
3. Обмена информацией между программами и устройствами.
4. Взаимодействия человека и устройств, ОС.
5. Управления программами и аппаратными устройствами.
6. Получения данных о возникших на устройстве ошибках, допущенных операционными системами или программой.

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

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

Типы и виды интерфейсов

Интерфейсы принято делить на несколько типов. Разные устройства могут использовать сразу несколько типов интерфейсов. Например, в ноутбуке имеются графические и жестовый интерфейс, командная строка. Смартфоны используют одновременно графический, жестовый и голосовой интерфейс. Рассмотрим основные типы интерфейсов:

1. Командная строка (CLI). Такой интерфейс активно использовался на заре развития компьютерных технологий. Командная строка – единственно возможный способ взаимодействия между пользователем и операционной системой MS-DOS.
2. Графический интерфейс (GUI, graphical user interface). Иногда графический называют WIMP — потому что он применяет Windows, Icons, Menus and Pointers. Позволяет взаимодействовать с операционной системой и программами с помощью визуальных элементов – иконок, окон, указателей мыши, списков, полей ввода и других объектов. Примером графического интерфейса является любой веб-сайт. Все, что мы видим на странице – это фронтенд. Благодаря ему пользователи взаимодействуют с бэкэндом, программной составляющей.
3. Текстовый интерфейс (TUI, Text user interface). Способ взаимодействия человека и компьютера с помощью набора букв и цифр. Ярким примером реализации текстового интерфейса является старая операционная система MS-DOS.
4. Жестовый интерфейс (GBI, Gesture-Based Interface или GDI — Gesture Driven). Это технология взаимодействия, с помощью которой можно управлять устройствами, которые «понимают» жесты (движения тела). Используется в ноутбуках, смартфонах и планшетах. Бывают двух типов: контактный (тактильный) и бесконтактный.
5. Голосовой интерфейс (VUI, Voice user interface). Пользователь вводит голосовую команду на своем родном языке, смартфон распознает ее и выполняет. Практическая реализация голосовых интерфейсов – сложная задача, программисты должны учитывать множество параметров. Пример: программы Алиса у Яндекс, OK Google.
6. Тактильный интерфейс. Это подвид жестового, предполагает непосредственный контакт с поверхностью (сенсорный экран, тачпад).
7. Нейронный интерфейс. предназначен для передачи сигнала из мозга в компьютер или другое устройство. Для этого в мозг вживляют электроды. С помощью системы нейронного интерфейса парализованный человек может общаться с окружающим миром. Системы программ, которые это обеспечивают, имеют большое медицинское и гуманитарное значение.
8. API. Application programming interface, Программный интерфейс – то универсальный способ взаимодействия между собой приложений, написанных на разных языках программирования и разными разработчиками. Как пример, виджет погоды яркий пример программного интерфейса,
9. Программно-аппаратный (аппаратно-программный) интерфейс. Способ взаимодействия приложений и оборудования. Самая главная задача ОС (операционной системы) – обеспечить взаимодействие программ и программ с «железом».
10. Аппаратный интерфейс (Хардварный). Hardware-интерфейс обеспечивает взаимодействие различного оборудования и физических девайсов, например, компьютера и принтера, компьютера и беспроводной мыши, компьютера и телевизора (внешнего монитора). Такой интерфейс может быть контактным, бесконтактным и смешанным.
11. Пользовательский интерфейс (технология ЧМИ — человеко-машинный интерфейс) — это все инструменты, с помощью которых человек взаимодействует и может пользоваться программой, игрой, системой «умный дом», отправляет команды и получает данные. Пользовательский интерфейс связывает воедино самого пользователя, операционную систему и программы.
12. Веб-интерфейс. Это все способы взаимодействия программ в интернете. Например, пользователь заходит в интернет-магазин, выбирает там товар и нажимает на кнопку «Купить» а затем – «Оплатить картой». Сайт отправляет запрос банку на списание средств со счета клиента и на зачисление на счет магазина. Понятно, что веб-интерфейсом в этом случае будет клиентский браузер – все взаимодействие происходит через него.
13. Игровой интерфейс. Сюда входит все взаимодействие пользователя с игровым приложением — от графического до системы управления. Создавая игру, программист должен ответить на такие вопросы: какие команды может давать игрок, как будет представлена различная информация в игре, как игра отреагирует на те или иные действия пользователя, какие данные игра предоставит.
14. Материальный интерфейс. Это любое взаимодействие с компьютерной мышкой, джойстиком, сенсорным экраном и даже с водопроводным краном. То есть со вполне осязаемыми, материальными объектами.
15. Интерфейс в телефонах. В современных телефонах используются различные виды интерфейсов: графический, голосовой, жестовый, тактильный. Технология работает так: пользователь прикасается к кнопкам на экране, дает команды голосом, а программное обеспечение распознает и обрабатывает эти команды.
16. MDI — управляемое меню, Menu Driven.
17. FBI — на основе форм, Form Based.
18. NLI — естественный язык, Natural Language.

Каким должен быть интерфейс

Цель любого interface – это диалог двух систем, продуктивное взаимодействие. С пользовательским интерфейсом каждый сталкивается ежедневно. Поэтому самая важная задача в этом случае — обеспечить легкое, интуитивно понятное управление устройством, программой.

Если хотите знать об интерфейсах веб-сайта, то он должен быть:

• Адаптивным к ПК, мобильным устройствам разных версий, производителей и моделей;
• Содержать оптимальное число графических элементов управления и надстроенных программ. Графических элементов не должно быть много, главное — все задачи пользователя должны решаться;
• Быть интуитивно понятным. Когда юзер тратит время на поиски, например, оформления заказа в корзине, это вызывает раздражение и нежелание завершать покупку. Поэтому важно, чтобы у пользователя на основе его предыдущего опыта не возникало проблем с взаимодействием. Все составляющие должны быть понятными, исправно работающими и «говорящими», не требующими что-то установить;
• Стоит обратить внимание на наличие кнопок с популярными социальными сетями, контактами, системой поиска, удобной формой регистрации, цветовых акцентов. Не должно быть неприятных, тяжелых для глаз цветовых сочетаний и шрифтов;
• Лаконичным. Объяснить назначение всех кнопок управления — хорошо, но отнимет много времени у посетителя. Универсальность и лаконичность позволяют не раздувать интерфейс, не делают его перегруженным информацией;
• Последовательным. Должна соблюдаться структура сайта, логичность. Не может кнопка «обратная связь» или «задать вопрос» находиться внутри только одной категории «одежда и обувь»;
• Эффективным. На этот пункт обращают особое внимание практически все интернет-магазины. Чем короче путь клиента к целевому действию, тем лучше для компании. Кнопка «оформить в 1 клик» в интернет-магазине намного прибыльней, чем оформление заказа в 3-5 этапов. Если говорить прагматично — когда пользователь тратит много времени на решение своей задачи, выше риск, что он откажется от идеи покупки именно на этом сайте;
• Учитывать возможные ошибки. Клиенты могут нажать «не туда», удалить данные, сделать заказ ненужного товара. В этом случае интерфейс должен предложить возможность отмены операции или восстановления данных;
• Проводить тестирование интерфейса на предмет работоспособности и удобства для простого пользователя. Попросите коллег, знакомых: это позволит понять, действительно ли интерфейс хороший и удобен для пользователей.

Основные элементы интерфейса

К интерфейсу относятся все элементы на мониторе пользователя. Давайте разберем подробнее те, с которыми будут напрямую взаимодействовать пользователи:

• Кнопка. Позволяет выполнить определенное действие при нажатии. Например, при нажатии кнопки «Купить» пользователь попадет в форму оформления заказа.
• Чек-бокс. Позволяет выбрать сразу несколько элементов. Используется в фильтрах сайтов для настройки вывода информации.
• Выпадающий список (select). Позволяет выбрать одну из опций, скрытых до момента наведения мышки или клика.
• Аккордеон. Список со скрытыми системами элементов. При клике на нем показываются дополнительные опции. Обычно он используется для сокращения меню. В развернутом виде аккордеон показывает скрытые пункты меню. Пользователь может открыть одно скрытое подменю или сразу все.
• Слайдер. Несколько изображений, сменяющих друг друга. Они обязательно имеют кнопки-стрелки для смены картинки. Часто применяется для показа разных объявлений. Картинки могут сменяться самостоятельно или после клика по слайдеру.
• Контент. Блок с текстом или визуальной информацией.
• Всплывающее окошко на сайте. Обычно используется для приглашения подписаться на рассылку, заказать услугу или прочитать похожую статью.
• Модальное окно. Разновидность popup, но в отличие от первого закрывает большую часть экрана. Чтобы продолжить работу с сайтом, пользователю нужно или закрыть это окно, или выполнить требуемые действия.
• Экран (блок). Фрагмент контента, рассказывающий об одной вещи. Чаще всего делается с расчетом на один экран.
• Страница. Структурная единица контента на веб-ресурсе. Обладает отдельным адресом, обычно посвящена одной теме или товару/услуге.
• Хедер (Header). Шапка сайта. Располагается в верхней части. Здесь обычно размещают контактную информацию и навигационные элементы: меню, поисковые строки.
• Подвал (футер/footer). Располагается в самом низу. Здесь можно разместить адрес компании, дополнительное меню, услуги и ссылки на важные страницы.
• Превью. Уменьшенное изображение при нажатии на которое открывается полная картинка, блок контента и т.д..
• Тултип (tooltip). Всплывающая подсказка. В зависимости от настроек может появляться при наведении или нажатии.
• Навигационные элементы. Все что помогает пользователю ориентироваться: меню, сайдбары с подсказками, кнопки для быстрого перехода на нужный фрагмент страницы. К навигационным элементам относятся и кнопки для возврата вверх страницы.
• Пагинация. Разновидность навигации, позволяющая переходить на страницы идущие или по порядку, или по определенным правилам. Например, пагинация может предлагать похожие статьи.
• Хлебные крошки. Разновидность пагинации. Фактически — это подборка статей по выбранному параметру. Размещаются чаще всего внизу, для увеличения кликабельности рекомендуется делать с использованием превью.
• Поисковая строка. Позволяет производить внутренний поиск. Некоторые ресурсы используют поисковую выдачу «Яндекса» или Google.
• Медиаплеер. Элемент, позволяющий просматривать видео непосредственно на сайте.
• Поле для ввода личных данных. Поле для ввода имени при регистрации или оставлении заявки.
• Маска для номера телефона. Если пользователю предлагается ввести номер телефона, используется «маска» с полями для заполнения.
• Форма для ввода пароля. Обычно символы пароля сразу скрываются точками с целью безопасности данных. Форма для входа обычно включает в себя логин или электронную почту и поле для ввода пароля. Современные сайты предлагают возможность входа через социальные сети или аккаунты Google и «Яндекса».
• Элемент, показывающий процесс загрузки. Позволяет пользователю понять, что сайт или приложение работают и нужно просто немного подождать.
• Теги. Позволяют определить, к какой категории или рубрике относится страница. Могут использоваться для настройки пагинации. Размещаются или перед основным контентом, или после.

Элементы интерфейса в GUI реализованы на основе метафор и абстракции.

Trello (система для управления задачами) визуально выглядит как доска для управления проектами по SCRUM (метафорично), на ней также можно таскать стикеры из одной колонки в другую. Интерфейсы конструируют по принципам атомарного дизайна.

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

Так, система делится на:

• Атомы. Мельчайшие частицы, из которых состоит интерфейс: кнопки, поля ввода, чекбоксы, радиокнопки, стили для типографики.
• Молекулы (группы атомов). Если взять два атома и соединить друг с другом — получится молекула. Например, кнопка и поле ввода.
• Организмы. Если объединить несколько молекул, получится организм — крупная часть интерфейса. Например, сквозная навигация в шапке или боковой панели.
• Шаблоны. Если объединить организмы друг с другом и создать шаблон — получится интерфейс, предназначенный для решения типовых задач.

При проработке элементов помните о пользователях. Сведите к минимуму нагрузку на их память, сделав объекты, действия и параметры заметными.

Этапы разработки пользовательского интерфейса

В международной практике подход к дизайну интерфейсов уже стал стандартом. Обучающие курсы зачастую опираются на одни данные. Процесс по дизайну интерфейсов включает следующие ключевые этапы (в этом блоке будем опираться на материалы UX Mastery — партнера Interaction Design Foundation, крупнейшего в мире сообщества обучения UX-дизайну):

1. Стратегия (Бренд-стратегия и UX-стратегия) — определяет полезное действие, ценности бренда и видение будущего. Стратегия естественным образом влияет на цели и методы проекта по дизайну интерфейсов, критерии достижения целей и результатов и приоритет проекта в общем ландшафте высот организации.
2. Исследование (UX-исследование) — фаза открытий. Комплексные проекты включают в себя масштабную работу по пользовательским исследованиям (UX-исследованиям) и анализу конкурентов (бенчмаркинг). Небольшие организации или стартапы могут подойти к исследовательской работе в упрощенном формате и обосновать идею, построенную по принципам минимальной жизнеспособности (Minimum Viable) через интервью, опросы и юзабилити тестирования технологии.
3. Анализ (UX-аналитика) — цель анализа в том, чтобы сделать выводы из данных и дать уверенный старт созданию дизайн-концепций. Выводы призваны помочь понять суть происходящего и приступить к проектированию интерфейса.
4. Проектирование и прототипирование интерфейсов — на этапе происходит создание прототипов интерфейсов, их тестирование пользователями и корректировка на основе обратной связи. На этой фазе чаще применяются прототипы с низкой детализацией (Low-fi prototyping), так в них пользователи фокусируются только на функциях и не отвлекаются на бренд-дизайн (уникальную графическую идентичность) и другие визуальные детали.
5. Дизайн интерфейсов и Разработка — на этом этапе создается проработанный дизайн, пишется детальный контент, алгоритмы, создается вся уникальная графика и начинается совместная работа с программистами.

Чтобы избежать возможных недочетов, имеет смысл провести тестирование интерфейса. В идеале оно проводится в два этапа:

• Проверка тестировщиком или аудит сайта по SEO. Отдаем интерфейс человеку соответствующего класса знаний, который профессионально проверяет работу всех элементов интерфейса. Далее занимаемся устранением всех выявленных технических недочетов.
• Beta-тест. Запускаем ограниченный трафик на сайт или приложение и смотрим, как реальные пользователи взаимодействуют с веб сервисом.

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

Базовые принципы разработки интерфейсов

Базовые принципы можно проследить сквозь 24 года исследований в сфере интерфейсов: с 1987 до 2009 года. Эти принципы работают и сейчас.

Читайте главные рекомендации по проектированию интерфейсов. Шнайдерман (1987 год) и Плезент (2009 год):

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

Примеры крутых интерфейсов

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

Рассмотрим интересные примеры интерфейсов, которые набрали популярность:

1. Приложение соцсети «ВКонтакте». Хорошая структура с полезными программами, все кнопки расположены в удобных местах на виду, реклама ненавязчива. За счет удобного графического интерфейса можно без проблем можно найти все необходимое и перейти в нужный раздел в пару кликов.
2. Маркетплейс «Вайлдберриз». Интерфейс и фирменный стиль интернет-магазина постоянно обновляется, становясь визуально легче, проще и удобнее.
3. Онлайн-кинотеатр «Кинопоиск». Здесь очень хорошо подобраны шрифты и цвета, все сделано в стиле кино. Пользователям приятно находиться на странице, а это улучшает UX.
4. Приложение для шахматистов «Chess.com». Сдержанный дизайн, гармонично подобраны цвета и простой в освоении хороший интерфейс.
5. Приложение сток-фотографий «Pinterest». Простой и понятный каждому интерфейс. Функционал довольно небольшой приложения, однако все сделано по канонам правильного создания пользовательского интерфейса.

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

Часто задаваемые вопросы

Речь не про язык программирования (типа python). Под языком интерфейса подразумевается не язык, на котором отображается/вводится текстовая информация, а язык, используемый при загрузке ОС. Он же используется в диалоговых окнах программы, в меню, в справке, окне ошибок.

Профессия специалиста, который разрабатывает пользовательские интерфейсы, называется UX/UI-дизайнером.

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

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

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

Есть ряд дополняющих друг друга причин. Это:

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

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

Заключение

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