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

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

• убедиться, что именно твой телефон сейчас сопряжён с колонками;

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

• запустить какое-то приложение;

• выбрать какую-то музыку;

• а если тебе ещё на это устройство позвонят, а если телефон жены быстрее твоего подключится?!...

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

Железо, софт

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

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

Сборка и установка железа заняла у меня минут 20 и несколько часов я потратил на написание сайта-web-приложения-интерфейса, который в последствии менялся, обрастал функционалом и принял более-менее окончательный вид. Об этом хочу рассказать подробнее...

Web-приложение, UI/UX

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

Казалось бы, Цель достигнута, но мне хотелось большего, а именно:

• сайт должен запускаться не как окно браузера, а как обычное приложение из иконки с рабочего стола;

• должно быть плавное переключение каналов (кроссфэйд);

• автоматическое переподключение при потере аудио-потока;

• отображение активности радио при фактическом проигрывании звука (визуализация);

• и некоторые другие плюшки.

Далее было несколько познавательных циклов разработки...

Цикл 1.

Web App Manifest дал возможность реализации сайта, как веб приложения со своим значком на рабочем столе устройства.

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

После тестирования выявлено:

• планшет "засыпает" при отсутствии активности пользователя;

• после нескольких суток работы приложения в круглосуточном режиме появлялись проблемы с аудио потоком;

• из-за одновременного воспроизведения нескольких источников в бэкграунде необоснованно использовалось достаточно много трафика;

• оказалось, что на Mobile Safari есть очень серьёзные ограничения на работу с многопотоковым аудио и на работу с громкостью. На начало 21го года эти ограничения звучат примерно так: допускается одновременное воспроизведение только одного потока, программная регулировка громкости недоступна.

Цикл 2.

Wake Lock Api решил вопрос засыпания устройства.

Пришлось потратить какое-то время на дебаг для поиска причин нестабильной работы через большой промежуток времени, однако всё привело к тому, что проблема кроется не в клиентской программной части, а где-то на уровне браузера-системы. Т.к. сайт заточён в свою песочницу, я сделал определённые выводы и провёл определённый ресёрч в сторону настроек Web Audio Api, работы с каналами, битрейтом, буферами и пр. Скорректировал настройки.

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

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

Добавил адаптивную вёрстку под любое устройство.

После тестирования выявлено:

• Проблемы воспроизведения потоков через Web Audio Api не пропали. Они стали проявляться значительно реже. Через несколько суток работы браузер мог начать значительно "подвисать" или выключался.

Цикл 3.

Т.к. я так и не смог найти решения для полноценной работы всего функционала построенного на Web Audio Api на mSafari, сделал выдох, перенёс весь функционал работы с аудио через Web Audio Api в отдельную настройку и вернул первоначальную ветвь с простой работой через html5 audio.

Провёл оптимизацию клиентской части. Как инструмент диагностики использовал Lighthouse (pagespeed от google). Если ставить перед собой цель 100 баллов, то можно узнать много полезного используя этот инструмент.

В итоге получилось рабочее веб-приложение, которое отправилось в бой.

После тестирования выявлено:

• В обычном режиме работы с аудио, приложение работает более стабильно. Решением пользуется вся семья (простота и надёжность сделали своё дело).

Эволюция интерфейса

Выводы

1. Идея и реализация были верны, чему я лично очень рад. Принцип "Чем проще - тем лучше" работает практически всегда!

2. Web Audio Api - классная штука, но если её использовать, то необходимо проработать вопрос совместимости и определиться с режимом работы (короткая сессия, длинная сессия (несколько суток), бесконечная сессия). По моим выводам, на начало 21го года, я бы не стал делать на его основе web-приложений для длинных или бесконечных сессий.

3. Так же, для длинных и бесконечных сессий связку андроид - хром - веб-приложение необходимо тестировать на целевых устройствах под актуальными версиями ПО. Я использовал в работе устаревший 8ой андроид, возможно мои проблемы со стабильностью работы уже давно решены, но я работал с тем что было на руках.

Что дальше

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

Вишенка

Многие web разработчики не знают как выглядят 100 баллов в Lighthouse. Вот так... :)

Сайт проекта

Буду рад, если мой опыт окажется полезным и вам. Всем удач!

Приветствую. Представляю вашему вниманию перевод заметок с сайтаHTMHell - коллекции плохих примеров HTML-кода, взятых из реальных проектов.

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

Так как я объединил в единую статью заметки, которые изначально являются независимыми и самодостаточными, во время перевода позволил себе иногда немного отходить от стилистики изначальных формулировок, пытаясь сделать текст менее "сухим" и более последовательным.

1. Кнопка, замаскированная под ссылку

Плохой код

<button role="link" title="Name of website" tabindex="0">  <img alt="Name of website" src="logo.jpg" title="Name of website"></button>

Ошибки и что следует исправить

• Пример неправильного использования элемента <button>. Для ссылок на другую страницу или сайт следует использовать элемент <a> . Не пренебрегайте семантикой HTML-тегов, если только в этом нет явной потребности

• Благодаря элементам <a>, на страницы можно ссылаться и без использования JavaScript

• Атрибут title описывает содержимое элемента в виде всплывающей подсказки и для элементов <button> указывать его излишне

• В атрибуте tabindex также нет необходимости, ведь при переключении между элементами с помощью клавиатуры кнопки получают фокус по умолчанию

Хороший код

<a href="http://personeltest.ru/aways/">  <img alt="Name of website" src="logo.jpg"></a>

2. Элемент с атрибутом role="button"

Плохой код

<div tabindex="-1">  <div role="button">    <svg width="28" height="24">  </svg>  </div></div>

Ошибки и что следует исправить

• Нет необходимости пытаться задать семантику <div>-элемента с помощью атрибута role, ведь вместо этого достаточно просто использовать элемент <button>

• При использовании <button> не понадобится и атрибут tabindex . HTML-кнопки по умолчанию могут получать фокус

• На <div>-элементах событие клика вызывается только непосредственно кликом мыши. На элементах же <button> это происходит ещё и при нажатии на кнопки Enter или Space на клавиатуре

• SVG-иконки, расположенной внутри нашей псевдокнопки не хватает текстовой альтернативы на случай, если SVG не отобразится

Хороший код

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

<button>  <span class="sr-only">Send</span>  <svg width="28" height="24" aria-hidden="true">  </svg></button>

Тексту присваивается класс .sr-only с набором свойств, делающим его скрытым только визуально

.sr-only {  position: absolute;  white-space: nowrap;  width: 1px;  height: 1px;  overflow: hidden;  border: 0;  padding: 0;  clip: rect(0 0 0 0);  clip-path: inset(50%);  margin: -1px;}

3. Картинки - кнопки

Плохой код

<img src="http://personeltest.ru/aways/habr.com/images/edit.gif" onclick="openEditDialog(123)"><img src="http://personeltest.ru/aways/habr.com/images/delete.gif" onclick="openDeleteDialog(123)">

Ошибки и что следует исправить

• Элемент <img> предназначен отнюдь не для выполнения JavaScript, а для показа изображений

• Как и на упомянутом ранее <div>, на элементе img> событие клика вызывается только непосредственно кликом мыши. Если бы вместо него использовался элемент <button> , это происходило бы ещё и при нажатии кнопок Enter или Space на клавиатуре

• Для самого изображения не задана текстовая альтернатива (атрибут alt ). Из-за этого скринридеры могут озвучивать название самого файла изображения, что далеко не всегда информативно

Хороший код

Решение 1: Использовать кнопки, а к помещённым внутрь кнопок изображениям добавить атрибут alt

<button onclick="openEditDialog(123)">  <img src="http://personeltest.ru/aways/habr.com/images/edit.gif" alt="Edit product XY"></button><button onclick="openDeleteDialog(123)">  <img src="http://personeltest.ru/aways/habr.com/images/delete.gif" alt="Delete product XY"></button>

Решение 2: Использовать кнопки и вместо добавления атрибута alt к изображениям, добавить описание в текстовые элементы

<button onclick="openEditDialog(123)">  <span class="sr-only">Edit product XY</span>  <img src="http://personeltest.ru/aways/habr.com/images/edit.gif" alt=""></button><button onclick="openDeleteDialog(123)">  <span class="sr-only">Delete product XY</span>  <img src="http://personeltest.ru/aways/habr.com/images/delete.gif" alt=""></button>

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

.sr-only {  position: absolute;  white-space: nowrap;  width: 1px;  height: 1px;  overflow: hidden;  border: 0;  padding: 0;  clip: rect(0 0 0 0);  clip-path: inset(50%);  margin: -1px;}

4. Ссылка с кнопкой внутри

Плохой код

<a href="http://personeltest.ru/aways/example.com">  <button>Example</button></a>

Ошибки и что следует исправить

• Вкладывая кнопку внутрь ссылки, вы подаёте сразу два сигнала: это кнопка, но также это и ссылка

• Если вы не уверены, когда нужно использовать элемент <a>, а когда <button>, рекомендую посмотреть видео "The Links vs. Buttons Showdown" от Marcy Sutton

Хороший код

.button {  /* используйте CSS, чтобы задать ссылке вид кнопки */}

<a href="http://personeltest.ru/aways/example.com" class="button">Example</a>

5. Кнопкоподобная ссылка

Плохой код

Контекст: это ссылка, стилизованная под кнопку. Ведёт она на форму, расположенную на этой же странице

<a href="#form" role="button" aria-haspopup="true"> &nbsp;&nbsp;Register&nbsp;&nbsp; </a>

Ошибки и что следует исправить

• Добавляя к ссылке role="button" , вы сообщаете, что это кнопка, хотя она ведёт себя как ссылка. Не меняйте семантику элементов, только если в этом нет серьезной необходимости

• Атрибут aria-haspopup="true" призван сообщать вспомогательным устройствам, что данный элемент вызывает попап, но в нашем случае этого не происходит

• Внутренний отступ padding следует добавлять к элементам через CSS, а не с помощью  

Хороший код

.button {  /* с помощью CSS задайте ссылке вид кнопки  */}

<a class="button" href="#form"> Register </a>

6. Ссылка с void-оператором в значении атрибута "href"

Плохой код

<a href="javascript:void(1)" onClick='window.location="index.html"'>Link</a>

Ошибки и что следует исправить

• Если JavaScript-код не загрузился или не может быть выполнен, использующая его ссылка просто перестанет работать

• Да и для ссылки на другую страницу нет необходимости использовать JavaScript. Адрес можно указать в атрибуте href, который 100% поддерживается всеми браузерами и будет корректно работать

• Такая ссылка будет работать только при клике левой кнопкой мыши. Открыть её в новой вкладке/окне щелчком скролла или через конктекстное меню не удастся

Хороший код

<a href="index.html">Link</a>

7. Дубликаты "id" и табличная раскладка

Плохой код

 <table>   <tr id="body">     <td id="body">       <table id="body">         <tr id="body_row">           <td id="body_left"></td>           <td id="body_middle"></td>           <td id="body_right"></td>         </tr>       </table>     </td>   </tr> </table>

Ошибки и что следует исправить

• Значениея атрибутов id должны быть уникальными, независимо от того, к какому тегу они добавляются

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

• Текущую разметку следует заменить на семантические HTML5-теги. Это существенно сократит количество тегов и сделает код более понятным

• При стилизации следует использовать новые технологии FlexboxиCSS Grid, но никак не элементы таблиц

• Для значений атрибута IDдолжны быть использованы более семантические термины

Хороший код

<main id="body">   <aside id="secondary_content"> </aside>   <article id="primary_content"> </article>   <aside id="tertiary_content"> </aside> </main>

8. Якорная ссылка в роли кнопки

Плохой код

<a href="#" onclick="modal.open()">Login</a>

Ошибки и что следует исправить

• Элементы <a> следует использовать для ссылки на другие ресурсы: такие как страница или PDF-документ

• В нашем же случае задача элемента вызвать JavaScript-действие на текущей странице. Для таких целей лучше подходит элемент <button> с атрибутом type="button" , потому что не имеет поведения по умолчанию и изначально предназначен для вызова действий в ответ на нажатие пользователем

• Ещё одним серьёзным недочётом данного примера является то, что браузеры и устройства, которые не поддерживают JavaScript, не смогут получить доступ к содержимому модального окна

Хороший код

Решение 1: Использовать элемент <button>

<button type="button" onclick="modal.open()">Login</button>

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

Решение 2: Ссылка на отдельную страницу

<a href="http://personeltest.ru/aways/habr.com/login" onclick="modal.open()">Login</a>

Ещё одно решение - использовать элемент <a> , у которого в атрибуте hrefуказать путь на отдельную полноценную страницу, где пользователь сможет проделать те же действия, что и в модальном окне. А переход по указанному пути, который является поведением ссылки по умолчанию, заблокировать через JavaScript

Таким образом, получаем некий фолбэк для браузеров и устройств, которые не поддерживают JavaScript или если он по какой-то причине не сработал

Это пример прогрессивного улучшения при разработке

9. Запрос согласия на хранение Cookie

Плохой код

<body>  <header></header>  <main></main>  <footer></footer>  <div class="cookie_consent modal">    <p>We use cookies</p>    <div class="cookie_consent__close">      <i class="fa fa-times"></i>    </div>    <div class="cookie_consent__ok">OK</div>  </div></body>

Ошибки и что следует исправить

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

• Кнопки данного окна, реализованные с помощью <div> элементов , а значит не получат фокус при переключении между элементами с помощью клавиатуры

• Содержимое внутри <div>-кнопок семантически является просто текстом. Всё это не позволит вспомогательным технологиям вроде экранных читалок понять, что определённые элементы на самом деле являются кнопками

• Как уже было указано ранее, в дополнение ко всему, на элементах <div> событие клика вызывается только непосредственно кликом мыши. Если бы всесто них использовались элементы <button>, это происходило ещё и при нажатии на кнопки Enter или Space на клавиатуре

• Для иконки нет текстовой альтернативы, а значит её назначение можно определить только визуально

• Font Awesome советует скрывать иконки от скринридеров, добавляя элементам <i> атрибут aria-hidden="true"

• Font Awesome добавляет Unicode-содержимое через псевдоэлемент ::before. Некоторые вспомогательные технологии могут озвучивать его. Но в данном примере иконка будет названа "разы" (times), поскольку fa-times - это не "крестик", а "знак умножения". Обратите внимание: Talkback и VoiceOver в данном случае не озвучат вообще ничего

• В завершение можно также добавить, что крайне полезным было бы иметь возможность закрыть модальное окно нажатием Escape

Хороший код

<body>  <div class="cookie_consent modal">    <h2 class="sr-only">Cookie notice</h2>    <p>We use cookies</p>    <button class="cookie_consent__ok">OK</button>    <button class="cookie_consent__close">      <span class="sr-only">Close notification</span>      <i class="fa fa-times" aria-hidden="true"></i>    </button>  </div>  <header></header>  <main></main>  <footer></footer></body>

Для описательного текста кнопок мы снова используем набор свойств, называемых классом .sr-only , который скрывает его визуально, но оставляет доступным для скринридеров

.sr-only {  position: absolute;  white-space: nowrap;  width: 1px;  height: 1px;  overflow: hidden;  border: 0;  padding: 0;  clip: rect(0 0 0 0);  clip-path: inset(50%);  margin: -1px;}

Дополнительные материалы

• Screen readers and cookie consents

10. Элемент как замена для

Плохой код

<section id="page-top">  <section data-section-id="page-top" style="display: none;"></section></section><main>  <section id="main-content">    <header id="main-header">      <h1>...</h1>      <section class="container-fluid">        <section class="row">          <article class="content col-sm-12">            <section class="content-inner">              <div class="content__body">                <article class="slider">                  <section class="slide">  </section>                </article>              </div>            </section>          </article>        </section>      </section>    </header>  </section></main>

Ошибки и что следует исправить

• Элементы секционного содержимого (<article>, <aside>, <nav>, <section>) это разделы, которые потенциально можно как-то озаглавить

• Секционные элементы вкладывать друг в друга можно, только это имеет смысл в ситуациях, когда содержимое внутренных элементов связано с содержимым родителя

• В данном конкретном случае секционные элементы используются не для того, чтобы разбить содержимое на разделы, а лишь с целью стилизации. Значит большинство из них должны быть элементами <div>, не передающими семантическое значение

• Когда пользователь переходит к элементу <section>, скринридеры могут озвучивать роль выбранного элемента region. Устройства также могут предоставлять возможность быстрой навигации по этим разделам. Использование большого количества элементов <section> (в том числе, вложенных) может сделать интерфейс излишне сложным для пользователей экранных читалок

• Важный момент, который следует понимать элементы <section> не являются заменой <div>

• Ещё одна ошибка в данном примере - неправильное использование элемента <header>. Обычно он содержит вводное содержимое для ближайшего родительского элемента <main> или другого секционного элемента. Если <header> не является вложенным, относится ко всей странице

• Компонент карусели (слайдера) следует озаглавливать и связывать заголовок с главным элементом с помощью атрибута aria-labelledby чтобы позволить пользователям скринридеров легко его найти

Хороший код

<div id="page-top">  <div data-section-id="page-top" style="display: none;"></div></div><main>  <section id="main-content">    <header id="main-header">      <h1>...</h1>    </header>    <div class="container-fluid">      <div class="row">        <div class="content col-sm-12">          <div class="content-inner">            <section aria-labelledby="sliderheading" class="content__body">              <h2 id="sliderheading" hidden>New Products</h2>              <ul class="slider">                <li class="slide">  </li>              </ul>            </section>          </div>        </div>      </div>    </div>  </section></main>

Дополнительные материалы

• Accessibility Support - section element (html)

11. Триграмма неба

Плохой код

<span class="nav-toggle">  Menu </span>

Ошибки и что следует исправить

• Проблема данной реализации в том, что текст внутри тегов скринридеры могут озвучить как "триграмма неба меню". Причина кроется в символе "", который таким образом называется в unicode

• Задача иконок - декоративное оформление, поэтому они должны быть скрыты от скринридеров. Рассмотрите добавление декоративных изображений с использованием CSS-свойства background

• Так же, как на упомянутых ранее <div>, и <img>, на элементе <span> событие клика вызывается только непосредственно кликом мыши. Если вместо него использовать <button> , клик можно будет вызвать ещё и при нажатии на кнопок Enter и Space на клавиатуре.

• Элемента <span> касаются и проблемы, связанные с невозможностью получения фокуса при переключении между элементами с помощью клавиатуры. А в нашем случае это особенно важно, ведь главная навигация открывается и скрывается именно с помощью данного элемента

• Для улучшения доступности при открытии навигации к элементу следует добавлять атрибут aria-expanded для обозначения текущего состояния панели. Значением true если панель открыта, false если закрыта

Хороший код

<button class="nav-toggle" aria-expanded="false">  <span aria-hidden="true"></span> Menu</button>

12. Доступный опрос "Да/Нет"

Плохой код

<form role="form">  <h2>Poll title</h2>  <div id="pollQuestion">Is this accessible?</div>  <div name="pollGroup" role="radiogroup">    <div role="radiogroup" aria-label="Poll title">      <input type="radio" name="poll" aria-labelledby="pollQuestion" value="[object Object]">      <span>Yes</span>      <input type="radio" name="poll" aria-labelledby="pollQuestion" value="[object Object]">      <span>No</span>      <input type="radio" name="poll" aria-labelledby="pollQuestion" value="[object Object]">      <span>Maybe</span>      <input type="radio" name="poll" aria-labelledby="pollQuestion" value="[object Object]">      <span>Can you repeat the question?</span>    </div>    <button type="submit">Vote</button>  </div></form>

Ошибки и что следует исправить

• Элемент <form> сам по себе семантически подразумевает форму, поэтому нет необходимости повторно указывать это с помощью атрибута role="form"

• Форма это важный для доступности страницы ориентир. Поэтому внутрь формы полезно поместить заголовок, а в элементе <form> с помощью атрибута aria-labeledby, сослаться на него. Это существенно облегчает навигацию в документе с помощью вспомогательных технологий

• Задавать атрибут role="radiogroup" необязательно, и уж точно не дважды. Если нужно сгруппировать элементы, просто используйте <fieldset>

• Не используйте aria-labelledby для создания связи между радиокнопкой и вопросом. Данный атрибут предназначен для установки доступного имени. Вместо этого для текста вопроса используйте элемент <legend>

• Чтобы радиокнопке назначить доступное имя, текст из <span> поместите в элемент <label> и свяжите с радиокнопкой с помощью атрибута for

• Кнопку также следует поместить внутрь <fieldset> для создания одной логической группы элементов

Хороший код

<form aria-labelledby="poll-title">  <h2 id="poll-title">Poll title</h2>  <fieldset>    <legend>Is this accessible?</legend>    <input type="radio" id="radio1" name="poll" value="yes">    <label for="radio1">Yes</label>    <input type="radio" id="radio2" name="poll" value="no">    <label for="radio2">No</label>    <input type="radio" id="radio3" name="poll" value="maybe">    <label for="radio3">Maybe</label>    <input type="radio" id="radio4" name="poll" value="repeat">    <label for="radio4">Can you repeat the question?</label>    <button type="submit">Vote</button>  </fieldset></form>

13. Ссылка или

Плохой код

<input type="checkbox" id="accept" required><label for="accept">  <a href="http://personeltest.ru/aways/habr.com/legal"> I accept the confidentiality policy and data </a></label>

Ошибки и что следует исправить

• Вкладывать элементы с запускаемым поведением (таким как клик) считается плохим решением

• Возможность выбора чекбокса путём нажатия на его название улучшает удобство и доступность (путём увеличения области клика)

• Но в данном случае пользователи не ожидают, что при нажатии на название чекбокса откроется новая страница

• Размещайте ссылки за пределами элемента <label>

Хороший код

<input type="checkbox" id="accept" required><label for="accept"> I accept the confidentiality policy and data </label>(read <a href="http://personeltest.ru/aways/habr.com/legal">Terms and conditions</a>)

Источники

• 4.10.4. The label element

• Be Wary of Nesting Roles by Adrian Roselli

14. Неподходящий "type"

Плохой код

<a type="button" class="button" href="http://personeltest.ru/aways/habr.com/signup" tabindex="-1">Sign up</a>

Ошибки и что следует исправить

• В данном примере с элементом <a> используется атрибут type , хотя он никак не влияет на семантику и можно сказать, что совсем неуместен

• Если его и добавлять, то лишь со значением, являющимся допустимым MIME-типом. Браузеры могут учитывать его, но исключительно как рекомендацию

• Если это ссылка, которая в атрибуте href содержит путь на какой-то ресурс (страницу или документ), следует использовать элемент <a>, а не <button>, независимо от того, как данный элемент выглядит в дизайне: как ссылка или как кнопка

• Отрицательное значение tabindex значит, что элемент не получит фокус при переключении между элементами с помощью клавиатуры. Правда, такой элемент всё же может получить фокус с помощью JavaScript

• Не меняйте семантику элементов, присущую им по умолчанию, если только в этом нет явной необходимости

• Если вам нужна кнопка, просто используйте элемент <button>

Хороший код

<a href="http://personeltest.ru/aways/habr.com/signup" class="button">Sign up</a>

Источники

• 4.8.2. Links created by a and area elements

• 4.5.1. The a element

15. Буква за буквой

Контекст: буквы обёрнуты в <div> с целью анимирования каждой буквы через JavaScript

Плохой код

<h3>  <div style="display: block; text-align: start; position: relative;" class="title">    <div style="position: relative; display: inline-block; transform: rotateX(90deg); transform-origin: 50% 50% -30.8917px;" class="char">H</div>    <div style="position: relative; display: inline-block; transform: rotateX(90deg); transform-origin: 50% 50% -30.8917px;" class="char">e</div>    <div style="position: relative; display: inline-block; transform: rotateX(90deg); transform-origin: 50% 50% -30.8917px;" class="char">a</div>    <div style="position: relative; display: inline-block; transform: rotateX(90deg); transform-origin: 50% 50% -30.8917px;" class="char">d</div>    <div style="position: relative; display: inline-block; transform: rotateX(90deg); transform-origin: 50% 50% -30.8917px;" class="char">i</div>    <div style="position: relative; display: inline-block; transform: rotateX(90deg); transform-origin: 50% 50% -30.8917px;" class="char">n</div>    <div style="position: relative; display: inline-block; transform: rotateX(90deg); transform-origin: 50% 50% -30.8917px;" class="char">g</div>  </div></h3>

Ошибки и что следует исправить

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

Код примера, продемонстрированного на видео

• Старайтесь избегать разрастания DOM. Слишком большое количество DOM-узлов или вложенных элементов может плохо отразиться на производительности страницы

• Большое DOM-дерево ведёт к большому дереву доступности, которое также может плохо сказываться и на производительности вспомогательных технологий

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

Хороший код

Решение 1

<h3> Heading </h3>

Решение 2

Если в этом действительно есть необходимость, добавьте версию текста, доступную для скринридеров, а текст, предназначеный для визуального отображения, скройте с помощью aria-hidden="true"

<h3 class="title">  <span class="sr-only">Heading</span>  <div aria-hidden="true">    <div style="transform-origin: 50% 50% -30.8917px;" class="char">H</div>    <div style="transform-origin: 50% 50% -30.8917px;" class="char">e</div>    <div style="transform-origin: 50% 50% -30.8917px;" class="char">a</div>    <div style="transform-origin: 50% 50% -30.8917px;" class="char">d</div>    <div style="transform-origin: 50% 50% -30.8917px;" class="char">i</div>    <div style="transform-origin: 50% 50% -30.8917px;" class="char">n</div>    <div style="transform-origin: 50% 50% -30.8917px;" class="char">g</div>  </div></h3>

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

.title {  display: block;  text-align: start;  position: relative;}.char {  position: relative;  display: inline-block;  transform: rotateX(90deg);}.sr-only {  position: absolute;  white-space: nowrap;  width: 1px;  height: 1px;  overflow: hidden;  border: 0;  padding: 0;  clip: rect(0 0 0 0);  clip-path: inset(50%);  margin: -1px;}

Источники

• Uses An Excessive DOM Size

• Performance and the Accessibility Tree

16. alt, хотя нет..., aria-label, хотя нет..., alt

Контекст: список изображений, которые ссылаются на страницы с товаром

Плохой код

<a tabindex="0">  <div alt="Browser Wars: The Last Engine" aria-label="Browser Wars: The Last Engine">    <div>      <img alt="Browser Wars: The Last Engine" src="thumbnail.jpg">    </div>  </div></a>

Ошибки и что следует исправить

• Если у элемента <a> атрибут href имеет пустое значение или данного атрибута нет вообще, он представляет собой заполнитель для того места, где могла быть ссылка (HTML спецификация)

• Если вы добавляете обработчик клика к ссылке-заглушке, то, по всей видимости, хотите, чтобы она была не заглушкой, а полноценной ссылкой с атрибутом href или кнопкой <button>, в зависимости от того, что должно происходить при клике

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

• Атрибут alt не используется с элементами div и никак не влияет на их семантическое значение

• Не злоупотребляйте ARIA. Атрибут aria-label лишний для элемента div, потому что img уже имеет доступное имя (значение атрибута alt)

Хороший код

Полноценная ссылка с заполненным атрибутом href и текстовая альтернатива alt для изображения

<a href="detail.html">  <div>    <img alt="Browser Wars: The Last Engine" src="thumbnail.jpg">  </div></a>

Источники

• The a element

• The accessibility of placeholder links

17. Недоступные карточки

Контекст: список карточек со ссылками, каждая из которых имеет заголовок, изображение и краткое описание

Плохой код

<section>  <section>    <h2>Overview</h2>    <figure class="card" data-url="image1.html" style="background: url(image1.jpg)">      <figcaption>        <h4>My heading</h4>        <article>Teasertext...</article>      </figcaption>    </figure>    <figure class="card" data-url="image2.html" style="background: url(image2.jpg)">  </figure>  </section></section>

Ошибки и что следует исправить

• Вероятнее всего, в подобных ситуациях необходимости в таком количестве элементов <section> нет. Чтобы лучше понять почему, рекомендую прочитать статью "Why You Should Choose HTML5 <article> Over <section>" автора Bruce Lawson

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

• Согласно спецификации, HTML5-элемент <figure> представляет собой самодостаточный элемент, который под основным содержимым опционально может содержать подпись. Но в этом примере нет содержимого, есть только подпись

• Изображнеие карточки не является декоративным, оно несёт какую-то информацию и должно быть частью HTML-кода документа, а не добавляться через CSS-свойство background . Фоновые изображения доступны пользователям не всех устройств

• В приведённом примере обработка клика на карточку происходит только через JavaScript. Если нет элемента ссылки с указанием пути (<a href="path/to/page">), для пользователей скринридеров переход на страницу карточки становится недоступным. Также элемент карточки не получает фокус при навигации с помощью клавиатуры

• Элементы <h1> - <h6> представляют собой вводный заголовок для родительского элемента <section>. <h4> является потоковым содержимым и, как следствие, технически может быть потомком <figcaption>, но лучше сделать его заголовком всей карточки

• Элемент <article> представляет собой самодостаточную композицию на странице. Это может быть газетная статья , эссе или отчёт, публикация в блоге или социальной сети. Для обычного абзаца текста лучше использовать элемент <p>

• Сделать доступной карточку, вся область которой является кликабельной, непросто. Дополнительную информацию можно найти в разделе "источники" ниже

Хороший код

<div>  <section>    <h2>Overview</h2>    <article class="card">      <h3>        <a href="image1.html"> My heading </a>      </h3>      <img src="image1.jpg" alt="Description of image1" />      <p>Teasertext...</p>    </article>    <article class="card">  </article>  </section></div>

Источники

• Semantic Structure

• Block Links, Cards, Clickable Regions, Etc.

• Inclusive Components: Cards

• Teaser with multiple links

• Block Links Are a Pain (and Maybe Just a Bad Idea)

18. Панель div-игации

Контекст: главная панель навигации

Плохой код

<div class="nav">  <div>    <div>about</div>    <div>thoughts</div>  </div></div>

Ошибки и что следует исправить

• <div> - это элемент, используемый в крайнем случае - когда никакие другие элементы не подходят. Использование <div> вместо более подходящих по семантике элементов ухудшает доступность

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

• Используйте элементы <ul> или <ol> для структурирования ссылок, связанных семантически и визуально. Скринридеры обычно объявляют номер элемента в списке, что помогает ориентироваться

• Если в навигации имеет значение последовательность элементов, используйте <ol> вместо <ul>

• Если вместо <a> для ссылок использовать элемент <div>, событие клика будет вызываться только непосредственно кликом мыши. Это сделает их недоступными для пользователей скринридеров и тех, кто переключается между элементами с помощью клавиатуры

Хороший код

<nav>  <ul class="nav">    <li>      <a href="http://personeltest.ru/aways/habr.com/about">about</a>    </li>    <li>      <a href="http://personeltest.ru/aways/habr.com/thoughts">thoughts</a>    </li>  </ul></nav>

Источники

• 4.3.4. The nav element

• Menu Structure

• Menus & Menu Buttons

19. Неправильная работа с заголовками

Контекст: простая страница, которая отображает наличие товара

Плохой код

<h1>Product Status</h1><h2>Is the product available?</h2><div>  <h3>    <div>      <div>        <i>          <h3 class="message is-success">            Its <a>available</a>.          </h3>        </i>      </div>    </div>  </h3></div>

Ошибки и что следует исправить

• Элементы <h1> - <h6> не должны использоваться для разметки подзаголовков, альтернативных заголовков и слоганов, если только они не озаглавливают новый раздел или подраздел

• Все элементы <div> в данном примере излишни. Скорее всего, они присутствуют только потому, что фронтенд-фреймворк добавляет их по умолчанию. Используйте Fragments in React или подобные техники в других фреймворка, чтобы избежать этого

• Старайтесь избегать разрастания DOM. Слишком большое количество DOM-узлов и вложенных элементов может отрицательно повлиять на производительность страницы

• Большое DOM-дерево ведёт к большому дереву доступности, что может отрицательно влиять и на скорость работы вспомогательных технологий

• Потомками <h1> - <h6> могут быть только элементы фразового содержимого. <h3> и <div> к ним не относятся

• Элемент <i> представляет собой фрагмент, который скринридеры произносят изменённой интонацией, чтобы обозначить его отличие от остального текста. Если вам нужен просто курсивный текст, используйте CSS-свойство font-style: italic

• Если у элемента <a> нет атрибута href, он представляет собой заглушку в том месте, где в другой ситуации может быть ссылка

• Если вы добавляете обработчик клика к ссылке-заглушке, то, по всей видимости, хотите, чтобы она была полноценной ссылкой с атрибутом href или кнопкой <button>, в зависимости от того, что должно происходить при клике

Хороший код

 <h1>Product Status</h1> <p>Is the product available?</p> <p class="message is-success">   Its <a href="http://personeltest.ru/aways/habr.com/product.html">available</a>. </p>

Источники

• 4.13.1. Subheadings, subtitles, alternative titles and taglines

• 4.5.22. The i element

• 4.5.1 The a element

20. Спецвыпуск HTMHell: кнопка "Закрыть"

В данном спецвыпуске рассматривается один из наиболее сложных и наиболее спорных шаблонов во фронтенд-разработке кнопка "Закрыть".

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

После недолгого исследования, занявшего менее 2 часов, HTMHell представляет 11 примеров плохой реализации данного элемента

Пример 1: с фоновым изображением

<div class="close"></div>    

close::after {  background: url("close.png");  content: "";}

Ошибки и что следует исправить

• <div> - это элемент для крайнего случая, когда никакие другие элементы не подходят. Использование <div> вместо более подходящих по семантике элементов ухудшает доступность

• На <div> событие клика вызывается только непосредственно кликом мыши. На элементах <button> это происходит ещё и при нажатии на кнопки Enter или Space на клавиатуре

• <div> не получает фокус при переключении между элементами с помощью клавиатуры

• Для фонового изображения невозможно задать текстовую альтернативу

• Данный элемент скринридеры озвучат: Никак

Пример 2: с иконкой

<div class="close">  </div>

Ошибки и что следует исправить

• Символ "" не является чем-то вроде "Закрыть" или "Перечёркнуто", это знак умножения. Например, 2 2 (два умножить на два). В кнопках "Закрыть" использовать его неуместно

• В первом примере подробно описаны проблемы, связанные с использованием элемента <div>

• Данный элемент скринридеры могут озвучить: как-то вроде "умножить на" или "разы" (times)

Пример 3: Иконки Font Awesome

<div class="close">  <i class="fas fa-times"></i></div>

.fa-times::before {  content: '\f00d';}

Ошибки и что следует исправить

• Скринридеры могут озвучивать содержимое, которое генерируется через CSS

• Font Awesome рекомендуют скрывать иконки семантически с помощью атрибута aria-hidden="true" для элемента <i>

• Font Awesome добавляет Unicode-содержимое через псевдоэлемент ::before. Вспомогательные технологии могут озвучивать эту Unicode-альтернативу, которая в этом конкретном примере будет звучать как "разы" (times), поскольку fa-times - это не крестик, а знак умножения. Обратите внимание: Talkback и VoiceOver в данном примере не озвучат вообще ничего

• Элемент <i> представляет собой фрагмент, который скринридеры произносят другой интонацией, что обозначить его отличие от остального текста. Если вам нужен просто курсивный текст, используйте CSS-свойство font-style: italic

• В первом примере подробно описаны проблемы, связанные с использованием элемента <div>

• Данный элемент скринридеры могут озвучить: "разы" (times)

Пример 4: Закрывающая ссылка

<a href="#" class="close"></a>

a::after {  font-size: 28px;  display: block;  content: "";}

Ошибки и что следует исправить

• Если элемент <a> содержит атрибут href, он представляет собой ссылку на другой ресурс: такой как страница или PDF-документ

• Задача элемента в нашем примере вызвать JavaScript-действие на текущей странице. Элемент <button> с атрибутом type="button" подходит лучше, потому что не имеет поведения по умолчанию и разработан для вызова действий в ответ на нажатие пользователем

• Если вы не уверены, когда нужно использовать элемент <a>, а когда <button>, посмотрите видео "The Links vs. Buttons Showdown" от Marcy Sutton

• Скринридеры могут озвучивать содержимое, которое генерирует CSS

• Символ "" не является чем-то вроде "Закрыть" или "Перечёркнуто", это знак умножения. Например, 2 2 (два умножить на два). Не используейте его в кнопках "Закрыть"

• Данный элемент скринридеры могут озвучить: "ссылка, разы" (link, times)

Пример 5: Закрывающая ссылка с текстом

<a href="#" class="close">  Close</a>

.close::before {  content: "\e028";}

Ошибки и что следует исправить

• Хорошая попытка, но это всё ещё ссылка, а не кнопка

• В предыдущем примере подробно написано про использование элемента <a> и генерируемое CSS содержимое

• Данный элемент скринридеры могут озвучить: "ссылка, разы закрыть" (link, times close)

Пример 6: Закрывающая ссылка без атрибута href

<a class="close" onclick="close()"></a>

Ошибки и что следует исправить

• Ещё одна хорошая попытка, но ссылка без атрибута href всё еще не является кнопкой

• Если у элемента <a> нет атрибута href, он представляет собой заглушку в том месте, где в другой ситуации может быть ссылка

• Если вы добавляете обработчик клика к ссылке-заглушке, то, по всей видимости, хотите, чтобы она была не заглушкой, а полноценной ссылкой с атрибутом href или кнопкой <button>, в зависимости от того, что должно происходить при клике

• Ссылки-заглушки не получают фокус при переключении между элементами с помощью клавиатуры

• Если вы не уверены, когда нужно использовать элемент <a>, а когда <button>, посмотрите видео "The Links vs. Buttons Showdown" от Marcy Sutton

• Данный элемент скринридеры могут озвучить: "разы, кликабельно" (times, clickable)

Пример 7: Ссылка-заглушка и изображение

<a onclick="close();">   <img src="close.png"> </a>

Ошибки и что следует исправить

• Для изображения не задана текстовая альтернатива. Скринридеры могут озвучить название файла

• В 6 примере подробно написано про использование ссылок-заглушек

• Скринридеры могут озвучить данный элемент: "close.png, изображение" (close.png, image)

Пример 8: Радио-кнопка

<label class="close" for="close">   <svg>  </svg> </label> <input id="close" type="radio">

[type="radio"] {  display: none;}

Ошибки и что следует исправить

• Когда сторонники доступности говорят "Просто используйте кнопку", они имеют в виду элемент <button>, а не радио-кнопки

• Радио-кнопки используются в группах, описывающих набор связанных вариантов (опций)

• У SVG нет текстовой альтернативы. Чтобы больше узнать о доступности SVG, рекомендую почитать статью "Creating Accessible SVGs" автора Carie Fisher

• Также, display: none на элементе <input> делает недоступным <label>

• Данный элемент скринридеры озвучат: Никак

Пример 9: Кнопка с иконкой

<button class="close" type="button">  </button>

Ошибки и что следует исправить

• Символ "" не является чем-то вроде "Закрыть" или "Перечёркнуто", это знак умножения. Например, 2 2 (два умножить на два). Не используейте его в кнопках "Закрыть"

• Данный элемент скринридеры могут озвучить: "разы, кнопка" (times, button)

Пример 10: Кнопка с svg

<button class="close">  <svg>  </svg></button>

Ошибки и что следует исправить

• У SVG нет текстовой альтернативы. Чтобы больше узнать о доступности SVG, рекомендую почитать статью "Creating Accessible SVGs" автора Carie Fisher

• Данный элемент скринридеры могут озвучить: "кнопка" (button)

Пример 11: Старая добрая буква "X"

<div role="button" tabindex="0">X</div>

Ошибки и что следует исправить

• Нет необходимости с помощью атрибута role явно задавать семантику элемента, вместо этого стоит просто использовать элемент <button

• При использовании <button> атрибут tabindex не нужен. HTML-кнопки получают фокус по умолчанию

• В 1 примере подробно описаны проблемы, связанные с использованием элемента <div>

• Буква "X" не является иконкой для кнопки "Закрыть"

• Данный элемент скринридеры могут озвучить: "икс, кнопка" (X, button)

"Использовать букву "X" для кнопок "Закрыть" это то же, что добавлять в кофе соль вместо сахара, потому что выглядит она так же"

Max Bck

Примеры правильной разметки

Решение 1: Кнопка с видимым текстом без иконки

<button type="button">  Close</button>

• Только текст: легко в реализации и понятно для пользователей

• Скринридеры могут озвучить данный элемент: "Закрыть, кнопка" (Close, button)

Решение 2: Кнопка с видимым текстом и только визуально доступной иконкой

<button type="button">  Close  <span aria-hidden="true"></span></button>

• Если вы вынуждены использовать иконку "умножить", скройте её от скринритеров, обернув в элемент <span> с атрибутом aria-hidden="true"

• Скринридеры могут озвучить данный элемент: "Закрыть, кнопка" (Close, button)

Решение 3: Кнопка со скрытым текстом и только визуально доступной иконкой

<button type="button">  <span class="sr-only">Close</span>  <span aria-hidden="true"></span></button>

.sr-only {  position: absolute;  white-space: nowrap;  width: 1px;  height: 1px;  overflow: hidden;  border: 0;  padding: 0;  clip: rect(0 0 0 0);  clip-path: inset(50%);  margin: -1px;}

• К сожалению, не существует встроенного способа скрывать содержимое только визуально. Для этого следует использовать CSS-правило, называемое классом .sr-only которое гарантирует, что контент будет скрыт визуально, но останется доступным для пользователей скринридеров.

• Скринридеры могут озвучить данный элемент: "Закрыть, кнопка" (Close, button)

Решение 4: Кнопка со скрытым текстом и только визуально доступной иконкой

<button type="button" aria-label="Close">  <span aria-hidden="true"></span></button>

• Если вы не хотите показывать текст на экране, обеспечьте для иконки или SVG текстовую альтернативу, добавив к кнопке атрибут aria-label

• Скринридеры могут озвучить данный элемент: "Закрыть, кнопка" (Close, button)

Решение 5: Font Awesome

Для полноты картины, закрывающая кнопка с иконкой Font Awesome

<button type="button" class="close" aria-label="Close">  <span class="fa fa-times" aria-hidden="true"></span></button>

Общие примечания

Порой может иметь смысл использование более описательных названий "Закрыть окно", "Закрыть галереию", "Закрыть рекламу".

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

Источники

• Accessibility support for CSS generated content

• The a element

• The accessibility of placeholder links

21. Легендарный legend

Контекст: кнопка, которая разворачивает и сворачивается блок текста

Плохой код

<button class="panel-heading" tabindex="0" href="#collapse0" aria-expanded="true">  <legend> Industries Served </legend></button>

Ошибки и что следует исправить

• <legend> не разрешается помещать в какой-нибудь другой элемент, кроме <fieldset> (HTML спецификация для legend)

• При использовании <button> атрибут tabindex не нужен. HTML-кнопки получают фокус по умолчанию.

• Атрибут href не может использоваться с элементом <button> (HTML спецификация для button)

Хороший код

<button class="panel-heading" aria-expanded="true">  Industries Served</button>

Источники

• The legend element

• The button element

22. Старая добрая div-ссылка

Контекст: ссылка на другую страницу

Плохой код

<div>About us</div>

<div onClick="location.href='about.html'">  About us</div>

<div data-page="aboutus" data-url="index.php">  About us</div>

... или любой другой вариант этого шаблона, где для ссылки на другую страницу используется отличный от <a> элемент

Ошибки и что следует исправить

• <div> - это элемент для крайнего случая, когда никакие другие элементы не подходят. Использование <div> вместо более подходящих по семантике элементов ухудшает доступность

• На <div> событие клика вызывается только непосредственно кликом мыши. На элементах <a> это происходит ещё и при нажатии на кнопку Enter на клавиатуре.

• <div> не получает фокус при переключении между элементами с помощью клавиатуры

• При нажатии правой кнопкой мыши в контекстном меню не будет пунктов "Открыть в новой вкладке/окне" или "Добавить ссылку в закладки"

• По умолчанию скринридеры просто озвучивают текст внутри <div> (например, "О нас"). В случае использования ссылки <a> скринридеры текст и роль элемента (например, "О нас, ссылка")

• Атрибуты наподобие aria-label у элементов <div> могут работать неправильно

• Пользователи скринридеров могут использовать раздел со списком ссылок страницы. <div>-ссылок в этом разделе не будет, если только к элементу не будет добавлен атрибут role="link"

Хороший код

<a href="aboutus.html">  About us</a>

23. Шаблон карточки

Плохой код

<article>  <div>    <div class="sr-only">Image</div>    <img src="http://personeltest.ru/aways/habr.com/feature-teaser.png" alt="Feature teaser" />  </div></article><div>  <span>    <span>Exciting feature!</span>  </span>  <div> This text describes what the feature does! </div>  <a href="http://personeltest.ru/aways/habr.com/blog/feature">    <span>Read more</span>    <svg viewBox="0 0 9 12" xmlns="http://personeltest.ru/away/www.w3.org/2000/svg">      <path d="M.84 10.59L5.42 6 .84 1.41 2.25 0l6 6-6 6z"></path>    </svg>  </a></div>

Ошибки и что следует исправить

• В примере выше используется <article>. Этот элемент предназначен для самодостаточного содержимого, которое может быть повторно использовано на странице. Если здесь и есть что-то повторно используемое, то вся карточка. Более подходящим является элемент <section>

• В первом <div> присутствует доступный только для скринридеров текст "Image". Ощущение, что это своего рода определение роли следующего за ним элемента <img>. Правильно подобранные HTML-элементы сами сообщают о своей семантике. Необходимость в дополнительных "уточнениях" отпадает

• Далее расположен <span>, который, кажется, является заголовком. Вспомогательные технологии могут использовать указанные в коде заголовки для быстрой навигации. Следовательно, более корректным будет использовать элемент заголовка корректного уровня. В данном случае <h4>

• Основной текст внутри карточки обёрнут в <div>. Использование <p> лучше передало бы его предназначение

• "Read more" не самый лучший текст для ссылки. Это особенно заметно пользователям скринридеров, которые используют навигацию по ссылкам. Из названия непонятно, куда именно ведёт эта ссылка

• <svg> внутри ссылки не предоставляет дополнительную информацию и должен быть скрыт от скринридеров

Хороший код

<section>  <div>    <img src="http://personeltest.ru/aways/habr.com/feature-teaser.png" alt="" />  </div>  <div>    <h4>Exciting feature!</h4>    <p>This text describes what the feature does!</p>    <a href="http://personeltest.ru/aways/habr.com/blog/feature">      <span>Read more about our exciting feature </span>      <svg aria-hidden="true" viewBox="0 0 9 12" xmlns="http://personeltest.ru/away/www.w3.org/2000/svg">        <path d="M.84 10.59L5.42 6 .84 1.41 2.25 0l6 6-6 6z"></path>      </svg>    </a>  </div></section>

Источники

• The Generic Section element

24. Placeholder - это не label

<input type="text" placeholder="First name">

Ошибки и что следует исправить

• Каждому элементу <input> нужен <label>. Когда пользователи скринридера переходят к полям формы, озвучивается содержимое <label> и тип поля (например, "имя, поле ввода"). Если этот текст пропущен, пользователи могут не знать, какую информацию они должны указать в этом поле

• Некоторые скринридеры всё же берут текст из атрибута placeholder, но не стоит полагаться на это

• По умолчанию, текст placeholder отображается светло-серым цветом с плохой контрастностью. Людям со слабым зрением может быть трудно его прочитать при ярком солнечном свете

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

• Использование <label> увеличивает область выбора нужного поля, что может быть очень полезным, особенно на устройствах с сенсорным экраном

• Если placeholder является единственным местом, содержащим название поля, при вводе текста он скрывается. Это ухудшает удобство заполнения форм, особенно если содержат много полей.

• Пользователи не могут проверить, правильно ли они заполнили форму, потому что видят только значения, но не названия полей.

• Если браузер заполняет поле автоматически, пользователь вынужден вырезать содержимое поля, чтобы убедиться, что оно заполнилось корректно

• Текст placeholder обрезается, если он выходит за рамки поля

• Инструменты подобные Google Translate могут не переводить значение данного атрибута при переводе всей страницы

• Названия полей лучше воспринимаются, когда расположены над соответствующим текстовым полем, а не внутри него

Хороший код

 <label for="firstname">First name</label> <input type="text" id="firstname">

Источники

• Placeholders in Form Fields Are Harmful

• 11 reasons why placeholders are problematicbyAdam Silver

• Dont Use The Placeholder AttributebyEric W. Bailey

• Form Design Quick Fix: Group Form Elements Effectively Using White Space

• placeholder - the piss-take labelbySteve Faulkner

• Floated Labels Still Suck

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

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

Я посмотрела на большие цифры последних двух опросов UX Writing Hub ирешила собрать цифры отдельно для России с учётом местных реалий. Желательно по регионам.

Вопросов было 4:

• Название должности

• Город, на который человек работает

• Уровень

• Зарплата за месяц

Опрос анонимный в некоторых компаниях зарплаты разглашать нельзя.

Ответили 34 человека. Результаты я публиковала в телеграм-канале, к постам задавали вопросы. Встатье будут некоторые из них.

Названия ролей

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

Опрос показал, что люди, которые пишут текст для пользовательского интерфейса называются по-разному:

• UX Writer или UX писатель

• UX-редактор

• Технический писатель или Technical Writer

• Специалист по технической документации

• Редактор

• Редактор продукта

• Content Strategist

• Content Lead

• И даже Главный ИТ-инженер (судя по названию, этот человек может заниматься вообще всем)

Когда наступает момент, когда выделяется отдельная роль? Реально задач хватает наотдельную?

Отдельная роль выделяется, когда

1. Есть потребность нормально писать (тексты в интерфейсах, release notes и прочие штуки), чтобы было понятно обычным людям.

2. Текущая UX команда может, но уже не вывозит.

3. Сумели продать эту тему руководству.

Есть ли разница по зарплатам в зависимости от названия?

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

Зарплаты по регионам

В среднем 103 207 рублей. В реальности от 40 000 до 300 000. Зарплата сильно зависит отрегиона. Больше 100 000 можно зарабатывать в Москве, Санкт-Петербурге, Ереване (не Россия, но близко) и в Нижнем Новгороде.

Для меня важным результатом оказалось, что UX writing развивается не только в Москве и Питере. Больше половины участников из других городов. Правда, больше только на двоих (18 и 16). Поскольку я сама из региона, я рада.

Есть пара ребят из Армении и Украины, но поскольку они активны в российских сообществах ипишут для русской аудитории, их ответы тоже вошли в исследование.

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

А где там до 300к? Только 250 вижу на графике.

Некоторые участники отмечали диапазон. На графике я отобразила среднее значение. Например, у одного человека зарплата 200300 тысяч. На графике 250, но максимальное значение получилось 300.

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

Кстати, если кому-то надо пруфы того, кем я работаю, держите:

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

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

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

В этой статье рассматриваются шесть способов снизить когнитивную нагрузку в UX-проекте.

1. Чем реже нужно делать выбор, тем лучше

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

Если у пользователя слишком много вариантов выбора, он легко сбивается с толку и раздражается. У продукта могут быть все необходимые функции, но если интерфейс чересчур запутан из-за чрезмерного количества возможностей, он становится неудобным. В опубликованном в журнале Journal of Personality and Social Psychology исследовании говорится, что такая ситуация часто вызывает паралич принятия решений и раздражение. [1]

В погоне за повышением числа начальных (или повторных) продаж компании могут включать в свои продукты слишком много (или слишком мало) функций. Используя модель, предложенную в Harvard Business Review, можно найти золотую середину в зависимости от желаемого результата.

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

Проблема в том, что компании предлагают пользователю слишком много вариантов, что оказывается бесполезной тратой ресурсов и может иметь неприятные последствия. Покупатель может тратить время, пробуя все возможные продукты, вместо того, чтобы купить хоть что-то. [2]

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

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

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

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

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

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

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

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

Понятно, что все мы иногда делаем ошибки даже лучшие из нас! Но как организовать хороший интерфейс на случай ошибки пользователя?

Ответ прост: нужно дать возможность легко вернуться туда, откуда пользователь начал.

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

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

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

При разработке пути пользователей я использую следующие рекомендации:

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

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

• Предотвращайте неправильный ввод данных: сохраняйте их до того, как ошибка испортит пользователю впечатление.

• Не показывайте сообщение на всю страницу укажите, в каких полях ошибка.

• В сообщениях избегайте резких формулировок: они могут отпугнуть и даже разозлить некоторых пользователей.

3. Визуальные подсказки для навигации

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

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

Правильно подобранное количество визуальных подсказок:

• Упрощает обзор и чтение страницы.

• Улучшает визуальную иерархию.

• Улучшает навигацию по странице.

• Существенно повышает коэффициент конверсии.

На эту тему институт CXL провел интересное исследование, в котором пользователям демонстрировали различные примеры целевой страницы. Всего было шесть вариантов с различными визуальными подсказками, которые призваны были помочь заполнить форму.

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

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

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

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

4. Снижение когнитивной нагрузки посредством знакомых шаблонов и условностей

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

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

Согласованная цветовая схема.

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

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

Повторение в шаблонах проектирования и условностях.

Важно не только следовать принятым условностям, но и регулярно использовать их и тогда случится прекрасное:

• вашим продуктом станет удобно пользоваться, потому что в нем не будет ничего нового (это снижает когнитивную нагрузку);

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

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

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

Знакомые значки и символы для обозначения привычных действий: например, корзина для удаления файлов.

Значки удобное средства указания на действие или объект в приложении. Их легко распознать, поэтому они идеально подходят для быстрого взаимодействия. Добавление привычных каждому значков и символов поможет упростить ориентирование в приложении.

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

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

5. Делайте интерфейс для пользователей, а не для себя или своей компании

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

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

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

При этом можно задавать такие вопросы:

• Что больше всего понравилось в нашем последнем продукте?

• Как бы вы отнеслись к изменению функции X?

Некоторые полученные в результате такого опроса идеи могут вас удивить и даже изменить направление развития прототипа.

Есть несколько методов исследования UX, которые помогут держать пользователей в центре внимания:

• Надлежащее исследование рынка.

• Использование персонажей пользовательских ролей.

• Макеты и прототипы для получения быстрой обратной связи.

• Регулярное общение с собственной службой поддержки.

И этот список, конечно, далеко не полный

6. Стремитесь к простоте не перегружайте пользователей большим количеством вариантов и функций одновременно

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

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

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

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

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

Заключение

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

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

Помогли ли вам приведенные в статье советы? Расскажите в комментариях ниже или напишите мне на почту alexander@radahl.no.

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Не путать с тёмным режимом!

Шумиха вокруг Социальной дилеммы заставила многих осознать силу технологий и их влияние на всех нас. Для UX-дизайнеров использование нечестных уловок на цифровых платформах не новость: мы называем такие хитрости тёмными паттернами.

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

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

Замаскированная реклама в YouTube

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

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

Тараканья ловушка (Spotify)

Тараканья ловушка такой дизайн, который упрощает попадание в определенную ситуацию, но затрудняет выход из нее (например, оформление подписки).

Помните, как создается аккаунт Spotify? Вряд ли: вы наверняка использовали OAuth и сразу же вошли через аккаунт Facebook. А если нет заполнили небольшую форму, указали регистрационные данные и всё. А как удалить аккаунт Spotify? Если вы пытались это проделать, наверняка помните, что пришлось постараться.

На веб-странице Spotify легко понять, как войти или зарегистрироваться. На панели навигации есть понятные кнопки и еще выделенная кнопка в центре экрана.

Если нажать кнопку входа, вы обнаружите, что для использования Spotify не нужно создавать аккаунт можно войти через аккаунт Facebook, Apple или Google. Просто и удобно, правда?

А вот удалить аккаунт Spotify то еще испытание. Нужно всего лишь выполнить следующее:

1. Перейти на страницу support.spotify.com/us/contact-spotify-support/.

2. Нажать Войти справа вверху и ввести свои учетные данные.

3. Нажать пункт Подписка.

4. Выбрать вариант Я хочу удалить аккаунт.

5. Нажать Удалить аккаунт.

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

Заманить и подменить (Reddit)

Заманить и подменить: вы хотите сделать одно, но вместо этого выполняете другое, нежелательное действие.

Листая ленту Reddit, можно раскрывать изображения, нажимая на них. Однако в ленте Reddit есть множество рекламных записей, и если пользователь нажимает на картинку такой записи, вместо стандартного поведения (развертывание изображения) открывается какой-нибудь рекламный веб-сайт.

Тараканья ловушка (Instagram)

Instagram использует паттерн тараканьей ловушки не так, как Spotify: Instagram мобильное приложение, но при этом удалить аккаунт из самого приложения невозможно. Пользователю понадобится браузер, что неоправданно усложняет процесс удаления аккаунта.

Принудительное продолжение (Skillshare)

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

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

Подтверждение с укором (Wish)

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

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

Предотвращение сравнения цен (AliExpress)

Предотвращение сравнения цен: продавец затрудняет сравнение цены одного товара с другим, что не дает принять обоснованное решение.

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

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

Скрытые затраты (Broadway.com)

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

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

Об авторе

Мариана Варгас UX-специалист и певица из Лиссабона (Португалия). С ней можно связаться через LinkedIn.

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Привет, Хабр. Меня зовут Ольга, я работаю в тестировании с 2013 года, специализируюсь на тест-анализе и тест-дизайне. Сегодня хочу рассказать, как при планировании тестирования сохранить фокус на пользователях и их потребностях.

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

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

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

Статья получилась объемной, так что вот оглавление:

1. Введение

2. Зачем и для кого фича?

3. Какую проблему решает фича?

4. Как пользователь будет использовать эту фичу?

5. Варианты использования

6. Основное направление варианта использования

7. Альтернативные направления

8. Исключения

9. От входных/выходных данных к тест-кейсам

10. Совет как писать сценарии

11. Общий алгоритм применения подхода

12. Профит от подхода для тестировщика

13. Заключение

Введение

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

Самые нажористые, сложные в исправлении баги обычно скрываются в требованиях и в постановке задачи.

Есть разные варианты, что может пойти не так:

• Ожидания пользователей (пользователи хотят одно, а мы думаем, что они хотят другое; нет важных фичей; фичи есть, но неудобные).

• Ожидания заказчика (ПМ хочет то, что невозможно/дорого реализовать; или то, что противоречит уже существующей логике).

• Ожидания бизнеса (бизнес хочет платную фичу, а мы не разобравшись даем ее пользователю бесплатно).

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

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

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

Другой вопрос: а как тестить до разработки, если по постановке задачи ничего непонятно?

Для этого нам нужно определить:

• Зачем и для кого фича.

• Как пользователь/заказчик будет использовать эту фичу.

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

Зачем и для кого фича?

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

Это можно спросить у автора задачи.

Стоит различать пользователя продукта и заказчика

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

Пользователи продукта тоже могут быть разные. Важно выявить:

• Какие категории пользователей есть в вашей целевой аудитории (ЦА).

• Зачем люди из каждой категории используют эту фичу.

• Какие проблемы они решают с помощью нее.

• Какие есть варианты использования фичи.

Итак, задача может быть для нужд бизнеса, например, чтобы организовать PR-компанию, или уменьшить затраты на Х, или увеличить доходы с У, или предотвратить/остановить отток пользователей.

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

Задача может быть для ПМа или владельца продукта, например, чтобы собрать статистику и на основе нее принять решение. При этом важно понимать, что это за решение.

Для команды разработки например, рефакторинг определенной области.

Для саппорта чтобы лучше локализовать проблему или чтобы снизить нагрузку на саппорт.

Для другой команды обычно это интеграции или еще какой-то обмен данными.

Какую проблему решает фича?

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

Можно обдумать это еще и в ключе: как пользователь/заказчик решает эту проблему сейчас?

Например:

• Делает руками, долго и болезненно. Или наоборот, руками получается быстро и ему ок.

• Запускает какой-то скрипт.

• Решает проблему через другое приложение.

• Никак не делает и страдает.

• Никак не делает и ему норм.

Ответ на этот вопрос поможет понять: а мы этой фичей точно улучшим пользователю работу или еще хуже сделаем?

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

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

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

Конфликт интересов

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

В книге Разработка требований к программному обеспечению (Карл Вигерс, Джой Битти) я нашла замечательную таблицу о том, как разрешать конфликты между сторонами при определении требований. Привожу ее здесь:

Как пользователь будет использовать эту фичу?

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

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

Если при разработке ориентироваться на пользователя и его работу с продуктом, то этих проблем можно избежать. Для этого удобно использовать технику Варианты Использования (Use Cases).

Варианты использования (Use cases)

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

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

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

Возьмем для примера агрегатор доставки заказов из ресторанов и магазинов. В нем можно найти вот такие варианты использования:

• Заказать еду из ресторана с доставкой.

• Заказать еду с самовывозом.

• Заказать доставку продуктов из супермаркета.

• Найти, в каком ресторане есть желаемое блюдо.

• Посмотреть стоимость доставки из ресторана Х.

• Повторить прошлый заказ.

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

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

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

Примеры вопросов, чтобы найти действующих лиц:

• Кому приходит уведомление о событиях в системе?

• Кто предоставляет системе информацию или услугу?

• Кто помогает системе среагировать и выполнить задачу?

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

Т.е. у нас будет как минимум 4 действующих лица:

• Покупатель

• Ресторан

• Курьер

• Система (т.е. само приложение)

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

Если покупатель выберет в заказе оплату картой, то добавится действующее лицо Банк. Если закажет еду не себе, а бабушке, то появится еще Получатель. А если будет писать в техподдержку, то добавятся Бот и Оператор техподдержки.

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

Основное направление варианта использования

Определим варианты использования основной фичи агрегатора доставки заказа еды из ресторана.

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

Действующие лица:

• П Покупатель

• Р Ресторан

• К Курьер

• С Система (т.е. само приложение)

• Б Банк

Предусловия:

• Пользователь авторизован в приложении

• Доступен как минимум 1 ресторан

• Заказ делается в часы работы ресторана

• У ресторана есть блюда в наличии

Сценарий (основное направление):

П: Добавляет блюда в корзину

С: Проверяет доступность блюд

С: Показывает пользователю сумму заказа в корзине

С: Подсчитывает сумму и прогноз доставки

П: Переходит в Корзину

С: Показывает текущее содержимое заказа

П: Инициирует оформление заказа

С: Предлагает выбрать параметры заказа (адрес, время доставки, вид оплаты)

П: Выбирает оплату картой онлайн и инициирует оплату

Б: Открывает страницу подтверждения оплаты

П: Подтверждает оплату (вводит код из СМС)

Б: Проверяет подтверждение

Б: Передает в Систему данные, что заказ оплачен

С: Присылает покупателю чек об оплате

С: Показывает покупателю, что заказ принят

С: Запрашивает подтверждение заказа у Ресторана

Р: Подтверждает заказ

Р: Начинает готовить заказ (в реальном мире)

С: Находит Курьера и запрашивает у него подтверждение принятия заказа

К: Подтверждает, что принял заказ

К: Идет в ресторан (в реальном мире)

Р: Подтверждает, что заказ готов

К: Подтверждает, что принял заказ в доставку

К: Транспортирует заказ (в приложении видна геометка курьера на карте) (в реальном мире)

П: Получает заказ

К: Подтверждает, что передал заказ покупателю

С: Показывает, что заказ завершен

Альтернативные направления

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

Можно посмотреть на сценарий целиком и подумать, как можно получить заказ другим способом:

Например:

• А-1 Зайти в раздел с завершенными заказами и повторить прошлый заказ

А можно смотреть на каждую строку и думать: может ли действующее лицо сделать другой выбор на этом шаге?

Например:

• А-2 Покупатель оформляет заказ на другого получателя (а не на себя)

• А-3 Покупатель выбирает оплату наличными (и сценарий минует шаги с онлайн-оплатой)

• А-4 Покупатель применяет промокод и сумма к оплате пересчитывается

• А-5 Покупатель выбирает доставку к определенному времени

• А-6 Курьер сначала принимает заказ, а потом отказывается и заказ берет новый курьер

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

Каждую такую альтернативу можно пошагово расписать, как и основной сценарий. А можно нарисовать блок-схему.

Исключения

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

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

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

• И-1.1 Добавляемое блюда закончилось в ресторане и больше недоступно для заказа.

• И-1.2 У ресторана закончилось время работы.

• И-1.3 Ресторан прекратил прием заказов и вообще исчез из списка.

• И-1.4. В корзине лежат блюда другого ресторана (обычно при этом система предлагает убрать блюда другого ресторана из корзины).

На шаге подсчета суммы и прогноза времени доставки может оказаться, что:

• И2.1 Сумма заказа недостаточна для доставки (возможен только самовывоз).

При оплате онлайн бывает, что страница банка зависает, и невозможно ввести код оплаты.

Вот этот блок в сценарии:

П: Выбирает оплату картой онлайн и инициирует оплату.

Б: Открывает страницу подтверждения оплаты (но страница зависает).

П: Не может ввести код оплаты.

П: Обновляет страницу.

П: Психует и Переходит на предыдущий экран (т.е. обратно в приложение).

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

Так и назовем исключение:

• И-3.1 Страница подтверждения оплаты зависла.

Еще несколько примеров исключений из этого сценария:

• И-4.1 Курьер не вышел на связь с рестораном (Система отменила заказ автоматически).

• И-4.2 Нет доступных курьеров в зоне доставки(Система отменила заказ автоматически).

• И-5.1 Курьер случайно отменил заказ когда еда уже была у него и отдал заказ бомжу.

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

От входных/выходных данных к тест-кейсам

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

При этом одни и те же параметры на входе в разные сценарии могут иметь разные значения.

Например, при заказе еды в агрегаторе доставки на вход поступают вот такие параметры:

Покупатель:

• Имя

• Телефон

• Адрес

• Способ оплаты

Заказ:

• Блюда и их стоимость

• Количество приборов

• Прогнозируемое время доставки

• Время оформления заказа

• Промокод

Ресторан:

• Адрес

• Часы работы

• Доступные блюда

Курьер:

• Имя

• Телефон

• Местоположение

• Доступность для заказа

На выходе могут быть такие данные:

• Доставлен ли заказ

• Количество доставленных блюд

• Качество (вкус, температура) доставленных блюд

• Доставленные приборы (количество, комплектность)

• Стоимость доставки

• Стоимость заказа

• Фактическое время доставки

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

Если Адрес покупателя будет расположен слишком далеко от Адреса ресторана, то доставка будет недоступна вообще, или сумма доставки будет высокой.

И наоборот, если Адрес покупателя находится в соседнем доме от ресторана, то доставка будет по минимальной стоимости.

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

Если способ оплаты Наличные курьеру, но по факту покупатель не заплатил курьеру, то заказ не будет доставлен (отменен).

То же самое, если на банковской карте не хватило средств для оплаты заказа, то заказ может быть отменен. Или отложен как не оплаченный и пользователь сможет поменять способ оплаты. Реальный исход зависит от реализации.

Из менее очевидного:

Что если покупатель закажет очень много блюд? В 2-3 раза больше, чем влезет в курьерскую термосумку. Сработает ли ограничение в, допустим, 15кг на 1го курьера? Или системе придется искать 3х курьеров?

Как будет в таком случае спрогнозировано время доставки? Ведь все эти блюда нужно еще успеть приготовить.

Если покупатель закажет доставку из ресторана за минуту до закрытия и ресторан не успеет подтвердить заказ, заказ доставят? Или перенесут на другой день? Или отменят?

Такие вопросы следует уточнять у постановщика задачи, ПМа или аналитиков на вашем проекте и не пытаться угадать/придумать правильную логику самостоятельно.

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

Пишите в сценариях смысл действия без опоры на внешний вид

При написании сценариев важно опираться на смысл пользовательского действия, а не на интерфейс. Это позволит не переписывать их при каждом редизайне.Т.е. мы можем написать:

• Покупатель выбирает вид оплаты Картой.

И не стоит писать:

• Покупатель кликнул на серую кнопку Visa/Mastercard в правом нижнем углу формы.

Кнопка может поменять цвет и перестать быть серой.

В текущей версии приложения это кнопка, а потом ее поменяют на плитку/выпадашку/любой-другой контрол.

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

Кнопка может поменять название и расположение.

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

Т.е. при описании сценариев желательно не использовать:

• Цвет

• Форму

• Расположение на экране

• Точное название

• Вид элемента интерфейса

Общий алгоритм применения подхода

Чтобы составить тест-кейсы по фиче с помощью техники Use Cases нужно сделать следующее:

1. Определить, зачем и для кого фича:

   • Какие категории пользователей есть в вашей целевой аудитории (ЦА).

   • Зачем люди из каждой категории используют эту фичу.

   • Какие проблемы они решают с помощью нее.

2. Выписать, какие есть варианты использования фичи.

3. Для каждого варианта использования нужно определить:

   • Какие действующие лица участвуют в сценарии (включая само приложение, ботов и сторонние системы).

   • Основное направление варианта использования.

   • Альтернативные сценарии.

   • Возможные исключения, когда что-то пошло не так.

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

Профит от подхода для тестировщика

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

• Найти пробелы в бизнес-логике.

• Помочь дизайнеру и разработчику разобраться в том, как будет работать фича.

• Убедиться, что есть обработка всех возможных ошибок.

• Проверить, что пользователь может пройти сценарий от начала до конца.

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

Заключение

Есть много техник, чтобы тестировать требования, и Use Cases, показанные в этой статье это тоже не панацея от всех бед.

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

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

Но не стоит забывать, что требования можно протестировать с помощью других инструментов, например, используя диаграмму Сущность-Связь (Entity-relationship), анализируя состояния объектов в продукте (State machine diagram) и т.д. Как при работе с требованиями, так и в тестировании все эти инструменты только усиливают друг друга, но это уже тема для отдельной статьи.

Хабравчане, о каких еще техниках по работе с требованиями вам было бы интересно узнать? Пишите в комментариях, поделюсь в следующих статьях.

Цифровизация сейчас в повестке дня едва ли не любого государства. Но все понимают ее по-разному, по-разному ее начинают, до разной степени готовности и продуманности доводят и приоритеты расставляют по-разному.

Для кого-то и у кого-то цифровизация это контроль и запреты, для кого-то и у кого-то удобство и польза каждого отдельного гражданина.

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

СОДЕРЖАНИЕ

Введение

Правительство Её Величества и его Web

Состав

Сайты

Структура и дизайн

Полный Flat

Код, софт, Performance

Палитра

Содержание по-прежнему Queen

Семантика

Atomic дизайн

Информационное сопровождение

Выводы

ПРЕДУПРЕЖДЕНИЕ: немного лонгрид, вынужден сразу предупредить. Но материал задуман и предназначен для других целей, так что короче никак. Поэтому, кому не интересно, не тратьте время, а кому интересно, наберитесь чуточку терпения.

Введение

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

Говоря о хроническом недоюзе социальных сетей российскими органами власти и его последствиях для нас, я вскользь, но намеренно упомянул стандарты доступности сайтов с твердым намерением вернуться к этой темe. ( II )

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

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

Однако, после некоторого размышления разговоры о доступности и, о как более общем подходе, об ориентированности дизайна веб-сайтов и приложений на пользователя (user-centred design) ( IV ) я решил предварить разговором о дизайне в целом; прежде всего, в ключе его UX/UI составляющей. В конце концов, не будь пользователь изначально поставлен в центр этой инженерной задачи, предваряющей любую разработку, все разговоры о доступности отпадут сами собой.

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

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

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

Правительство и Web Её величества Today

Состав

Согласно сайту gov.uk на начало апреля 2021 года правительство Соединенного Королевства и имеющие к нему отношение организации, это:

• офис премьер-министра;

• 23 министерства;

• 20 департаментов, не являющихся министерствами;

• 411 агентств и прочих госструктур;

• 105 значимые профильные организации;

• 13 госкорпораций;

• и 3 автономные администрации.

Итого: 576 ед.

Сайты

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

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

Все вместе правительственные сайты в домене gov.uk это полмиллиона страниц, множество документов и услуг и в среднем примерно 5,1 млн посещений ежедневно, не считая тех, кто отказался от приема cookies. ( VI )

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

Структура и дизайн

Полный Flat

Над вопросом с чего начинается Родина в случае с веб-империей правительства Её величества голову ломать совершенно не приходится. Набираете в адресной строке gov.uk, и вы дома.

Первое впечатление от посещения: лаконичность, строгость, функциональность. В реализованной концепции все уплощено до предела, ни тени в прямом и переносном смысле, ни на намека на реализм. Можно сказать, gov.uk это квинтэссенция плоского (Flat) дизайна.

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

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

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

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

Код, софт и Performance

Раз зашла речь о производительности, необходимо эту тему немного развить.

Согласно Wappalyzer, правительственные сайты, находящиеся в кусте gov.uk, очень неприхотливы в используемых технологиях. За основу взят Ruby on Rails, веб-сервер и обратные прокси поставлены на Nginx, Varnish для кэширования, из JS-библиотек jQuery (1.12.4) и три собственных UI-фреймворка GOV.UK Toolkit, GOV.UK Template и GOV.UK Front-End, и, как говорят англичане, thats it.

Такой инструментальный минимализм освобождает веб-страницы от массы ненужного кода, а пользовательские браузеры и правительственные веб-серверы от массы ненужной работы. Всего пара скриптов перед закрывающим </body>-тегом вот и весь JavaScript.

Но все же за все приходится платить. Задействовав jOuery, сайты поплатились малость безопасностью (D в тесте на WebPageTest за безопасность прилетело именно из-за нее; см. рисунки ниже), что совсем не на руку обширному веб-хозяйству gov.uk, так как используемые технологии касаются всех сайтов в домене. Но если говорить о производительности, то тут нетребовательность англичан окупается сторицей. А пользователи, как мы знаем, больше любят сайты быстрые, чем безопасные. ( IX )

И на этом разговор о технических характеристиках gov.uk можно, пожалуй, закончить. Кто понимает, о чем идет речь, да поймет.

Цветовая палитра

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

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

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

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

Традиционно голубой цвет считается одним из наиболее любимых у детей. И хотя дети не являются ключевой аудиторией правительственных сайтов, возможно, он также благотворно действует на людей с теми или иными формами аутизма, который, как известно, сопровождает людей на протяжении всей жизни. Как бы там ни было, думаю, большинство согласится, что встань, скажем так, неуравновешенный человек перед выбором (на основе внешнего вида веб-сайта), с кем ему идти в разведку с правительством Великобритании или с ЦРУ (см. новый дизайн сайта ЦРУ), он бы выбрал первое.

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

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

Содержание все еще Queen

Абстрагируясь от конкретных используемых и неиспользуемых в создании британских правительственных сайтов подходов и технологий, главное, что отличает и сам процесс их создания и, как следствие, конечный продукт это тщательная скрупулезная продуманность и согласованность (consistency).

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

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

Содержание (информация, за которой приходят на сайты люди) по-прежнему король (применительно ко времени и месту все же королева, пожалуй), и, как заверяет нас Forbes, останется таковым навсегда. Поэтому пора посмотреть, из чего же, из чего же сделаны эти страницы на gov.uk?

Первым делом, первым делом человек!

Хедер

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

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

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

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

Тело

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

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

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

(Тем более, в самом деле, трафик госсайтам не нужен; кто пришел за услугой и информацией, без нее не уйдет, так не лучше ли сделать так, чтобы на входе скапливалось как можно меньше народа? сделать наоборот, примерно то же самое, как перед входом на эскалаторы метро в Рождество устраивать распродажи).

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

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

Таким образом, если посетителя интересует получение водительских прав, ему не приходится гадать, к ведению какого ведомства отнесена данная услуга. Логика предоставления информации исходит из принципа не важно, кто (окажет услугу), важно, что (в чем заключается потребность конкретного человека) и как.

Следующий раздел всего пять ссылок в трех абзацах по две строчки каждый представляет посетителю несколько другой информационный ракурс. Здесь он может узнать, что собой представляет правительство, сколько в нем каких подразделений, как они называются, как попасть на их сайты (см. Рисунок 1). Что примечательно, никаких промежуточных визитных карточек не предусмотрено; нажав на ссылку, вы сразу переходите на интересующий вас сайт.

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

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

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

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

Футер

Футер последний элемент на который непременно следует обратить внимание. Условно футер правительственных сайтов состоит из двух версий минимальной и полной.

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

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

Полная версия используется на всех официальных правительственных сайтах в домене gov.uk; минимальную можно встретить на прочих сайтах, относящихся к правительству, но не являющихся сайтами правительственных структур. В частности, это блоги, которые размещены в домене третьего уровня blog.gov.uk в виде отдельных сайтов четвертого уровня (например, accessibility.blog.gov.uk); сервисная информация, предоставляемая на сайте третьего уровня data.gov.uk и т.п.

Еще раз посмотрим внимательно на футер. Ни привычной контактной информации, ни ссылок на используемые соцсети в каком бы то ни было виде. Как так?

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

Это тем более имеет смысл, так как раздел контактов у многих правительственных организаций может оказаться очень обширным. Британские ведомства, в отличие от многих наших, не стесняются предоставлять своим посетителям как можно больше вариантов и возможностей для связи с ними. За примером сходите на сайт Форин Офис (FCDO) видели?.. сами можете себе представить, каким должен быть футер, чтобы вместить в себя всю эту информацию.

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

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

Структура отдельных сайтов

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

В качестве примера можно взять любой. Например, сайт GDS (Government Digital Service), организации, ответственной за все это веб-хозяйство (ссылка на ее сайт в футере). Выбор абсолютно не принципиален, поскольку, какой бы сайт вы из этого массива ни вытащили, все они будут иметь одну и ту же структуру (см. рисунок 13).

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

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

Еще один момент, на который непременно стоит обратить внимание. Это элемент, предваряющий футер.

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

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

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

И то, что мы видим у британцев, наводит на мысль, что эти ребята в своем деле толк знают.

Atomic дизайн

Туго пришлось бы британским госдизайнером, скорее всего не случилось бы им создать свое веб-чудо, не будь они знакомы с концепцией atomic ( XII ) дизайна от Брэда Фроста. ( XIII ) Она позволила добиться той лаконичности и содержательности одновременно, которые иным UX/UI дизайнерам не снятся даже в самых смелых фантазиях. Пойди они проторенной дорожкой, и обрекли бы себя на поистине сизифов труд. Не помогли бы ни минимализм, ни собственные фреймворки.

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

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

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

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

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

We Want Information, Information, Information

Блоги

We Want Information, Information, Information, такими словами начинается композиция The Prisoner из альбома The Number of the Beast группы Iron Maiden (британской, конечно же!). И, знаете, власти совсем не против: Хотите информацию? Пожалуйста!

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

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

Их ведут университеты и их подразделения, исследовательские организации, библиотеки и think tanks, международные организации (World Bank, IMF) и ТНК (CISCO, Microsoft).

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

Всего их у него на сегодняшний день не удивляйтесь, в хорошем хозяйстве все посчитано 137. Собраны все блоги под своим, так скажем, подзонтиком в домене https://www.blog.gov.uk/. Не все из них активны, некоторые переведены в архив, но доступ к ним при этом сохраняется в полном объеме.

Исходя из их количества, можно догадаться, что не все ведомства и службы имеют собственные блоги, зато у некоторых их даже не по одному. Так, у офиса премьер-министра три, у министерства юстиции два, ( XIV ) а у GDS (Government Digital Service), в ведении которой и находятся все правительственные сайты, блогов аж девять.

Но блогами этой службы темы функциональности интересующих нас сайтов и их доступности отнюдь не исчерпываются. Например, Civil Service ведет блог Accessibility in government, а Home Office Home Office Digital, Data and Technology. Следует признать, цифровая тема очень плотно пронизывает неформальную информационную повестку британских государственных служащих. 25 блогов из 137 так или иначе связаны с темой цифровизации. Наберите на главной странице блогов в левой части в раскрывающемся списке ключевое слово digital, и вы сами все увидите.

Руководства и нормативно-правовая база

Для доведения своей официальной позиции по тому или иному вопросу у правительства Великобритании предусмотрены другие каналы. Законодательство собрано на сайте https://www.legislation.gov.uk/, а для различных руководств и разного рода наставлений есть раздел Guidance and regulation. Это на случай, если кто-то уже ухватился за мысль, что блоги это единственный способ общения правительства с гражданами и собственным персоналом.

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

Выводы

Британский правительственный веб это торжество английского дизайна, это элегантность Роллс-Ройса и практичность Лэнд Ровер Дефендера. Это очередное подтверждение справедливости народных пословиц о том, что прежде чем резать, стоит семь раз отмерить, или что не все то золото, что блестит, и очередное доказательство состоятельности по-государственному гуманистического подхода к нуждам и запросам людей.

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

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

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

(I) Говорят, что это был Рене Декарт.

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

(III) Можно, конечно, продолжать их не замечать, но дальновидно ли это?

(IV) Приводится в английском варианте написания.

(V) Использование доступного среднестатистическому пользователю языка один из главных принципов UCD (user-centered design). И не только в продукте, если он подразумевает его [языка] использование, но и в сопроводительной документации к нему. GDPR, например, требует соблюдения этого принципа и в части правовой информации, размещаемой на сайтах и предназначенной для конечных пользователей. Поэтому, когда наталкиваешься на подобные документы российских ведомств (https://digital.gov.ru/ru/documents/4820/), начинаешь понимать актуальность таких требований, и что возникают они не на пустом месте.

(VI) Теперь в цивилизованных странах с этим строго: не хочешь cookies, не ешь.

(VII) Зайдите на сайт Рослесхоза, и вы увидите, до какого абсурда можно довести идею с hero-изображениями и каруселями. Представьте, вам каждое утро приносят газету, у которой первая страница до сгиба пустая? Сайт Рослесхоза именно такая газета.

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

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

(X) Хотя государственный язык в России русский, для нас привычное дело назвать официальный сайт органа государственной власти на английском. В качестве примеров можно привести сайты правительства РФ, Совета Федерации, Росрыболовства и целый ряд других.

(XI) 777, Карл! Ты не поверишь!

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

(XIII) Не сказать, чтобы идея принципиально нова. Автомобилестроители, например, давно собирают машины из агрегатов общих для целой линейки моделей. Да Брэд Фрост и сам с этого начинает. Но же это маркетинг, сами понимаете. Он живет по своим законам.

(XIV) Это очень демократично и прогрессивно по сравнению с российским минюстом, который даже соцсетями пользоваться не удосуживается, https://github.com/shydata/govnets/blob/main/govnetsreport-2020-alexshy-FULLREPORT.pdf.

8 июня 2009 года Фил Шиллер выступил на WWDC. Всего 36 секунд он неловко говорил о VoiceOver, Zoom, White on Black (с iOS 6 называется Invert Colors) и Mono Audio. Это были первые реальные специальные функции на платформе iPhone OS, как её тогда называли. Однако, они не произвели большого впечатления 36 секунд закончились, а потом не было никакой демонстрации или аплодисментов, и Шиллер просто перешел к описанию приложения Nike+.

Но в сообществе людей с проблемами зрения всё было иначе. Казалось, что время остановилось где-то после 1:51:54. Произошло нечто совершенно удивительное, и только несколько человек, казалось, понимали, что это значит.

Примечание. Статья переведена и адаптирована в качестве поддержки книги Миши Рубанова Про доступность iOS. Надеемся, что статья поможет вам глубже погрузиться в мир доступности и начать разрабатывать доступные приложения. В этом и поможет книга. Первые четыре главы уже доступны на сайте. Остальные будут выходить в канале Dodo Mobile. Подписывайтесь.

Что произошло 8 июня 2009 года

8 июня 2009 года Фил Шиллер два часа выступал на WWDC. В 1:51:54, после того, как он продемонстрировал голосовое управление и новое приложение Compass, на экране появился логотип Apple accessibility фигура в виде пряника с вытянутыми руками и ногами, которая используется по сей день.

Мы также очень заботимся о доступности.

Сказал Шиллер, и слайд переключился на экран настроек iPhone с перечислением функций доступности: VoiceOver, Zoom, White on Black (с iOS 6 называется Invert Colors) и Mono Audio.

36 неловких секунд и всё кончилось: никакой демонстрации или аплодисментов. Доступность не произвела большого впечатления, и от первых реальных специальных функциях на платформе iPhone OS, Фил перешёл к описанию приложения Nike+.

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

У всех возникли вопросы: смогут ли теперь пользоваться iPhone люди, которым он был недоступен? Спустя 10 лет мы знаем ответ теперь у Apple лучшая мобильная доступность. Но всё это происходило не сразу, и не каждый шаг на этом пути был верным. Я бы хотел рассказать об этом пути.

В дополнении к моему аудио-документальному фильму 36 секунд, которые изменили все: как iPhone научился говорить, я собрал список основных этапов доступности iOS за последние 10 лет. Я сосредоточился на аппаратном обеспечении и ОС Apple. Обновления приложений Apple и сторонние приложения, которые открыли двери для новых способов использования iOS, тоже важны, но с ними список будет слишком длинным. Поэтому, за некоторыми исключениями, я обратился к особенностям доступности iOS. Многие основные функции имеют специальные приложения и преимущества, даже если они не подходят напрямую.

2007-2009: до появления iPhone

В 2007 году на Mac всего пару лет было доступно ПО для чтения экрана для людей с проблемами зрения Mac Screen Reader. Это теперь он называется VoiceOver, а в 2005 его представили как Tiger версии 10.4. До Tiger ни одна версия Mac OS X не предоставляла инструменты доступности.

Поэтому немного пользователей Mac с проблемами зрения были настроены услышать что-то кардинальное на MacWorld Expo в 2007 году. До Mac OS X Apple действительно предлагала несколько настроек доступности, и программу для чтения с экрана от сторонних разработчиков.

Некоторые энтузиасты технологий с проблемами зрения перешли на Mac после прихода VoiceOver с Tiger. Именно они больше всего интересовались, будет ли доступен iPhone.

Потому что в 2007 году среди покупателей iPhone не было людей с проблемами зрения iPhone был им недоступен. Многие люди, как незрячие, так и зрячие, полагали, что этого не будет никогда.

В конце концов, как перемещаться по холодному гладкому стеклу без зрения?

Примечание: о проблеме холодного стекла у нас есть перевод статьи Будущее интерактивного дизайна в руках.

Весной 2008 года Apple добавила VoiceOver в iPod Nano. В то же время iTunes на Mac стал доступен для VoiceOver. Старое приложение Carbon раньше не работало с устройством чтения экрана.

Это означало, что незрячий человек теперь мог подключить Nano к iTunes, включить VoiceOver на устройстве, скопировать на него песни и использовать VoiceOver для поиска и воспроизведения.

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

Теперь, когда iTunes стал доступен через Mac, Apple заложила основу для доступности iPhone, сделав возможным для человека с проблемами зрения синхронизировать iPhone со своим компьютером.

Следующая остановка настоящий, доступный iPhone.

2009: iPhone OS 3, 3GS и iPod Touch

Анонс iPhone, которого все ожидали на WWDC 2009, обещал быть грандиозным. Все ждали существенного обновления с длинным списком новых функций, учитывая, что App Store существовал уже год, а за плечами Apple два года разработки. iPhone 3GS был солидным релизом, а iPhone OS 3.0 принесла такие важные и запоздалые достижения, как copy/paste.

Июнь: iPhone OS 3 и 3GS

Поспешное, позднее открытие VoiceOver, Zoom, White on Black и Mono Audio принесло только неопределенность отсутствие демо-версии не внушало доверия. Кроме того, существующие устройства даже не были совместимы с iPhone OS 3.

Чтобы получить доступ, придется подождать и купить iPhone 3GS. Пользователи, которые были довольны или, по крайней мере, смирились со своими телефонами, внезапно обнаружили, что подписались на AT&T и перешли на новый, доступный iPhone.

Как работает VoiceOver

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

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

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

Если, например, вы находитесь в Заметках, эти параметры позволяют читать по строкам, словам или символам, позволяя редактировать текст.

Остальные функции специальных возможностей

• Масштабирование увеличивает экран iPhone. Pinch-to-Zoom был доступен в оригинальной ОС iPhone, но работал только в некоторых поддерживаемых приложениях, таких как Safari. Общесистемный зум увеличивал экран по всему интерфейсу.

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

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

Осень: iPod Touch третьего поколения

Следующая возможность получить доступное устройство от Apple появилась с выпуском iPod Touch третьего поколения старые модели не поддерживали iPhone OS 3.

Самым большим недостатком iPod, конечно, было отсутствие навигационных функций, предоставляемых GPS-оборудованным iPhone. Навигация представляла огромный интерес для незрячих пользователей.

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

2010: iPad, iBooks, iPod Touch

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

Весна: iPad первого поколения и iBooks

Но ещё одна особенность первого iPad также была интересна людям с ограниченными возможностями чтения iPad был первым устройством Apple, с приложением iBooks и iBooks Store. Можно не только добавить любую книгу Apple на iPad, но и использовать VoiceOver, чтобы прочитать её вслух. Это означало, что если книга не была доступна в шрифте Брайля, на ленте или в другом доступном формате, владелец iPad всё равно мог её изучить.

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

Осень: iOS 4

Ввод текста одним касанием (Touch typing). Сначала он был представлен как второй режим набора текста на iPad. Сенсорный ввод на виртуальной клавиатуре работает быстрее для пользователей VoiceOver, чем стандартный. Не нужно выбирать, а затем дважды нажимать клавишу на клавиатуре, чтобы ввести её. Теперь это проще: опустите палец на клавиатуру, наведите на нужную кнопку и отпустите палец для ввода буквы под ним. Разделенное нажатие делает сенсорный ввод гораздо эффективнее с помощью VoiceOver. Перейти в такой режим набора можно через ротор.

В iOS 4 добавили веб-ориентированный ротор с определенными опциями для навигации по элементам в Safari. Эта функция в конечном итоге будет свернута в ротор общего назначения, но iOS 4 это то место, где впервые появились веб-опции.

Поддержка клавиатуры Bluetooth означала, что слепому пользователю не нужно бороться за ввод текста на виртуальной клавиатуре. С Bluetooth стала возможна поддержка обновляемых дисплеев Брайля.

Количество таких дисплеев, поддерживаемых iOS, увеличивается с каждой версией, и Apple ведет текущий список в Интернете.

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

Доступность получила важные обновления в iOS 4, некоторые из которых придали легитимность iOS в глазах скептиков, которые предпочитали Windows.

2011: iPhone 4s, Siri и iOS 5

iPhone 4S был первым телефоном с Siri. Это не функция доступности, как таковая, но человек с физической или зрительной инвалидностью может управлять iOS голосом, что быстрее и проще.

Осень: iOS 5

iOS 5 освободила всех пользователей от необходимости настраивать устройство с компьютера, а пользователи VoiceOver получили возможность выполнять свою собственную настройку с помощью программы чтения с экрана. Начать настройку можно было через iTunes, поскольку Mac OS X также включала программу чтения с экрана.

Тройной щелчок. Незрячим людям стало проще благодаря корректировке поведения кнопки Домой. Раньше тройной щелчок вызывал выбор между масштабированием и голосом за кадром. К сожалению, пользователь VoiceOver с проблемами зрения не мог определить нужную опцию. В iOS 5 теперь можно было сделать тройной щелчок во время процесса установки, чтобы вызвать VoiceOver он включался по умолчанию.

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

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

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

VoiceOver Item Chooser также дебютировал в iOS 5. При посещении веб-страницы с множеством ссылок и элементов контента вызовите средство выбора элементов, чтобы вызвать алфавитный список элементов на странице. Если знаете, что вам нужно, вводите текст, чтобы сузить поиск. Затем дважды коснитесь элемента, который хотите выбрать.

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

Обнаружение лиц. Дебютировало в iOS 5 в приложении камеры. При включенном VoiceOver наведите устройство на объект или объекты, и VoiceOver покажет, сколько лиц видит камера и где они находятся в кадре.

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

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

Особенности слуха

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

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

Новый режим слухового аппарата. Позволил устройствам iOS лучше работать со слуховыми аппаратами Bluetooth. Это было началом расширенной поддержки слуховых аппаратов, которая расцветет в более крупную инициативу Made for iPhone для слуховых аппаратов. Начиная с iPhone 5, они сертифицированы как совместимые со слуховыми аппаратами (Hearing Aid Compatible, HAC) Федеральной комиссией по связи США.

2012: iOS 6

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

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

Осень: iOS 6

Home-Click Speed. Позволяла пользователю регулировать чувствительность кнопки Home, что облегчало человеку с моторной задержкой эффективное нажатие на неё. Guided Access даже получил демо-версию WWDC Keynote.

Контекстные действия в iOS 6. У некоторых элементов появились дополнительные действия. Чтобы переключиться на них проведите пальцем вверх или вниз, двойное нажатие выполняет действие. Например, так можно пометить письмо как прочитанное или удалить. Это немного похоже на использование ротора VoiceOver, но без необходимости делать жест открытия ротора.

Карты. Получили серьезное обновление в iOS 6. Pause to Follow позволяет найти и выбрать улицу, а затем провести пальцем когда вы слышите Pause to Follow.

Действие даёт представление в каком направлении проходит дорога, и насколько она прямая или извилистая. Звуковая обратная связь направляет, когда вы идете по улице, и визуально подсвечивается для людей с низким зрением. Ротор VoiceOver также включал в себя пункт Точки интереса позволяющий пользователю пролистывать близлежащие важные и интересные места, чтобы найти конкретный объект или просто просмотреть свое окружение.

Guided Access. Новинка в iOS 6. Позволило ограничить доступ к элементам iOS, например, отключить кнопки громкости или запретить пользователям доступ к определенным приложениям. Управляемый доступ позволяет учителям сосредоточить внимание учащихся, часто детей со спектром аутизма. Вызовите управляемый доступ и свободно передайте ученику iPad, который может запускать только то образовательное приложение или обучающую игру, которую вы хотите использовать. Также можно замаскировать кнопки или другие элементы интерфейса в выбранном приложении.

AssistiveTouch. AssistiveTouch делает ключевые элементы управления устройствами доступнее.

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

2013: iOS 7

Apple лихо переработала внешний вид интерфейса iOS и практически всех своих собственных приложений. Сквеоморфизм исключили, а тонкие шрифты, прозрачные слои и анимация добавили.

Шаг назад с iOS 7

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

Благодаря отрицательной реакции на iOS 7 Apple исправила то, что сломала: откатила первоначальный дизайн ОС и добавила настройки доступности, которые могли бы компенсировать проблематичность определенных элементов дизайна. Например, они включали в себя формы кнопок, уменьшающие движения и метки включения/выключения. Кроме того, iOS 7 представила увеличенную контрастность, полужирный текст и настройку размера шрифта. Они помогли компенсировать проблемы 7.0.

Все выровнялось в iOS 7.1. Это был единственный релиз iOS, созданный специально для слабовидящих пользователей вроде меня.

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

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

Обновления. iOS 7 представила множество основных обновлений интерфейса, включая Центр управления и усиленный переключатель приложений. Они были сразу же доступны VoiceOver и AssistiveTouch, а также новому интерфейсу управления коммутатором.

Динамичный Текст. Функция Увеличенный текст была доступна в iOS 6, хотя и не сильно повлияла на iOS. Можно выбрать один из шести увеличенных размеров текста и увидеть их в нескольких приложениях, таких как Сообщения или Почта.

Более крупный текст в iOS 7 и поздних версиях это пользовательский интерфейс для Динамичного Текста. Если разработчик поддерживает Динамичный тип в приложении, пользователь может использовать ползунок Размера текста, чтобы сделать его больше или меньше. Даже Apple не поддерживала Динамический тип во всех своих приложениях iOS 7, но постепенно исправила. Многие другие разработчики приняли эту функцию, но не все.

Слуховые аппараты iPhone. Apple никогда не создавала собственные слуховые аппараты, но работала с производителями, чтобы увеличить количество доступных продуктов MFi программу Made for iPhone. Технологические усовершенствования в характеристиках Bluetooth Low Energy (BLE) и согласованные усилия Apple распространили MFi на слуховые аппараты, которые компания начала сертифицировать как совместимые с устройствами iOS.

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

Рукописный ввод VoiceOver. Поддержка рукописного ввода VoiceOver позволяет пользователю VoiceOver вводить текст, рисуя печатные текстовые символы пальцем на экране. Есть жесты для обозначения пробела и для обычных знаков препинания. Можно использовать рукописный ввод для поиска приложений на главном экране. Войдите в режим рукописного ввода с ротором, нарисуйте первую букву приложения и iOS найдёт все подходящие. Рукописный текст также можно использовать для навигации по веб-страницам.

Switch Control. AssistiveTouch был частью iOS начиная версии 6. Switch Control расширил идею интерфейса, который поддерживает пользователей с моторными задержками.

С его помощью мы используем:

• внешние переключающие устройства, которые представляют собой кнопки с двумя состояниями;

• сам экран iOS в качестве переключателя или даже камеры: глядя влево или вправо, мы активируем переключатель на основе камеры.

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

Многие пользователи Switch Control оснащают свои iOS-устройства несколькими устройствами. А iPad, установленный на инвалидном кресле вместе с переключателями, может создать очень эффективную iOS-установку для человека с тяжелыми двигательными нарушениями.

Быстрый доступ к специальным возможностям. Раньше эта функция называлась Triple-Click Home. Позволяет включать и выключать специальные возможности с помощью тройного щелчка. Теперь на тройное нажатие можно добавить несколько специальных функций. При срабатывании iOS покажет меню из тех, которые вы включили.

2014: iPhone 6 и 6 Plus

Первые большие айфоны включили новую функцию под названием Display Zoom.

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

Осень: iOS 8

Несколько новых функций в iOS 8 были важны для доступности.

Клавиатура QuickType. Предсказывала текст и отображала панель с предложениями по набору текста над виртуальной клавиатурой.

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

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

Алекс. В iOS 8 из Mac OS X пришёл голос Алекс. У Алекса есть естественное звучание дыхания во время разговора, что намного удобнее чтения длинных текстов, чем более старые альтернативы из iOS 5.

Оттенки серого. В iOS 8 появился Режим оттенков серого для некоторых людей отсутствие ярких цветов на экране легче для восприятия.

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

Ввод с экрана Брайля. Как и функция рукописного ввода, экранный ввод Брайля облегчает ввод текста на экране.

Вместо того, чтобы рисовать символы пальцем, мы используем метафору ячеек Брайля для ввода ячеек Брайля на экране. Это полезная функция для тех, у кого нет удобного дисплея Брайля при работе с iPhone.

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

2015: Apple Watch и iOS 9

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

3D Touch. Функция появилась на новых iPhone в iOS 9. Несмотря на альтернативные голосовые жесты и необходимость сильно нажимать, чтобы вызвать 3D Touch, пользователи VoiceOver с поддерживаемыми телефонами получили доступ к жестам 3D Touch первого уровня, а также Peek и Pop.

Многозадачность iPad. Появились новые жесты, которые позволяли пользователю VoiceOver работать с Split View или Slide Over. Опять же, пользователи специальных инструментов могли пользоваться новыми инструментами прямо из коробки.

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

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

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

Switch Recipes для Switch Control. При использовании управления переключателем каждый переключатель выполняет одну функцию. Функция Switch Recipes эффективно позволяет пользователю создавать комбинации действий.

Изменения Ротора выбора текста VoiceOver. Изменения в роторе VoiceOver облегчили выбор текста по символу, слову, строке или странице.

2016: iOS 10

Изменения в iOS 10 в основном косметические. Но не все.

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

Новый редактор произношения. Позволяет произносить или вводить имя так, как его должен произносить VoiceOver, и сохранять правильное произношение. А с VoiceOver audio routing можно передавать звук на устройство по вашему выбору, например на Bluetooth-динамик. Теперь Switch Control позволяет пользователям управлять устройствами, подключенными к устройству iOS, включая Apple TV.

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

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

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

Цветовые фильтры. iOS предлагала переключение оттенков серого с iOS 8, но теперь появились цветовые фильтры, предназначенные для настройки вида экрана в зависимости от потребностей пользователей с тремя распространенными формами дальтонизма.

Программное обеспечение TTY. Пользователи iPhone всегда могли подключать свои телефоны к TDD (телекоммуникационное устройство для глухих) если у них был соответствующий аппаратный адаптер. Начиная с iOS 10, можно звонить или отвечать на звонок TTY без допоборудования, а также сохранять стенограммы звонков.

2017: iOS 11

iPhone X первое iOS-устройство без кнопок Home. Это повлияло на доступность: отсутствие кнопки Home изменило жесты по умолчанию, используемые для таких вещей, как open Control Center или App Switcher.

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

iOS 11 была первой версией iOS, которая поддерживает устройства Face ID. Некоторые люди с ограниченными возможностями, особенно незрячие и с протезами глаз, не могут уделять необходимое внимание датчику Face ID. Поэтому iOS добавила переключатель, который позволяет разблокировать телефон без зрительного контакта. Из-за этого Face ID вызывает споры в сообществе людей с проблемами зрения из-за предполагаемого риска безопасности. Также некоторым слепым пользователям трудно заставить Face ID работать.

Однако функция всё равно полезна. Переключатель Require Attention, который включен по умолчанию (функция безопасности) предотвращает разблокировку телефона, если он просто проходит перед лицом своего владельца. Выключение этого переключателя позволяет большему количеству незрячих людей разблокировать телефон с помощью Face ID. Но пользователь потенциально рискует получить телефон разблокированным без их согласия. При настройке устройства, оснащенного Face ID, с помощью VoiceOver пользователю предлагается оставить его включенным или выключить.

Новые возможности. iOS 11 также принесла несколько новых и обновленных версий специальные возможности, например, поддержку VoiceOver для перетаскивания и специальные жесты VoiceOver для владельцев iPhone X. VoiceOver также добавил новый метод перемещения приложений, который был частью iOS 10. Теперь можно использовать ротор для выбора и перетаскивания нескольких приложений в любое место на любом домашнем экране.

Смарт-инверсия цвета. Invert Colors появились ещё в iOS 3, и отображали всё как обратное нормальному внешнему виду. Но Smart Invert Colors отображает изображения как положительные, а не отрицательные, до тех пор, пока рассматриваемое приложение поддерживает его.

Вы все еще можете выбрать между Invert Colors и Smart Invert Colors и добавить их в ярлык специальных возможностей.

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

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

Type to Siri. Если вы не можете говорить или это неудобно, Type to Siri даёт возможность выдавать команды Siri с клавиатуры. Можно печатать с виртуальной, с Bluetooth-клавиатуры или в шрифте Брайля с дисплея Брайля.

2018: iOS 12

Все выпуски iOS содержат ошибки. Пользователи специальных возможностей часто находят те, которые относятся к функциям, что они используют каждый день и ждут, пока Apple их исправит, например, когда шрифт Брайля и VoiceOver глючили в iOS 11. Но, как и iOS в целом, iOS 12, казалось, исправила много проблем доступности и добавила некоторые новые функции.

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

Живое Прослушивание. Уже некоторое время можно использовать микрофон iPhone как усилитель окружающего звука, посылая звук на слуховой аппарат. В iOS 12 функция Live Listen была расширена до AirPods. Теперь можно слышать собеседника даже если вокруг шумно.

2019: iOS 13

Доступности уделили много внимания на WWDC 2019. Вот несколько важных особенностей.

Голосовое управление. Последняя и совершенно новая функция специальных возможностей, анонсированная для iOS 13, а также Mac OS Catalina, имеет очень старое название. До появления Siri в iOS была функция голосового управления (и до сих пор существует). Но можно было только инициировать телефонный звонок или воспроизвести песню с помощью голосовой команды.

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

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

Итог

Если вы измеряете доступность iOS по количеству доступных сегодня функций, 2009 год кажется примитивным временем. В тот год на программном слайде WWDC Фила Шиллера появилось всего четыре пункта. Но один из них VoiceOver точно революционизировал реальную доступность на iPhone почти сразу.

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

Полезные материалы:

Статьи по VoiceOver:

Voice Control и VoiceOver: как адаптировать приложение для незрячих или неподвижных.

VoiceOver на iOS: каждый контрол ведёт себя по-разному.

VoiceOver на iOS: решение типовых проблем.

Другие полезные:

Зачем и как мы пишем постмортемы по критичным багам.

Будущее интерактивного дизайна в руках.

Как выйти на китайский рынок с mini-app для WeChat, чтобы не прогореть.

На пути к 10x инженеру: шорткаты, сниппеты, шаблоны.

Подписывайтесь на Dodo Engineering chat в Телеграм будем обсуждать статью, и на канал там новости и разное интересное.

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

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

Начинаем трансляцию

Устроились поудобнее и заглянули в zoom, где уже встречаем всех гостей приветственным словом Сергея Монина, председателя правления банка, и играем в квиз, чтобы получить приятный подарок фирменный мерч Open Demo Day Райффайзенбанка.

Теперь переходим к главному, ради чего собрались: восемь демо восемь суперфич!

20:44 >>> Сервис для оптимизации работы курьерской доставки
Команды: Customer Relations for PI, Site, Cards, Notifications & On Demand Development

Показываем, как организовали доставку банковских продуктов для физических и юридических лиц. Начиналось все с нескольких десятков доставок в месяц, и вот у нас уже работает собственная курьерская служба. Большие объемы и стремительное развитие бросают вызовы: нужно соответствовать высоким ожиданиям клиентов и автоматизировать процессы. Для этого и разрабатываем сервис, а под капотом используем наработки собственного open-source решения ViennaNET.

42:19 >>> Переводы по номеру телефонав мобильном банке
Команда Instant &Easy

У нас в фокусе работа над самым важным и популярным функционалом для наших пользователей в мобильном банке, и к этим фичам относятся платежи и переводы. В этом направлении мы реализовали две истории: первая история, где отсортировали банки по популярности и добавили им логотипы. Это базовые и понятные вещи, которые экономят в среднем 2,5 секунды на перевод по номеру телефона. Вторая история вот о чем: упростили перевод получателю, номер которого указан в адресной книге. Что делать, если СБП у получателя не включен? Это тоже предусмотрели все наглядно показываем в демо.

1:02:58 >>> Интеграция банковских услуг в SAP
Команда CDC Integrations

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

1:22:55 >>> Опросник NPS для кандидатов
Команда Recruitment Dev Team

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

1:45:43 >>> Омниканальная чат-платформа собственной разработки
Команда Chat

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

2:08:46 >>> Автоматический процесс принятия решения по заявке
Команда Personal Loans

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

2:26:07 >>> Цифровой маркетинг Райффайзен-Лизинг, новый сайт и маркетплейс
Команда Leasing

Для лизинга 2020 был непростым: в целом рынок упал на 6%. Что делала наша команда в прошлом году? Запустили цифровой Лизинг автомобилей и спецтехники и предоставили доступ в систему нашим партнерам. Еще активно занимались развитием сайта и маркетплейса: появился раздел по каталогам автомобилей и условиям и более заметная кнопка с оформлением заявки.

2:41:51 >>> Автоматизация исходящих платежей на базе блокчейн-платформы
Команды Technosoul Cash Management & Payments Service Team

Командами работали над интересной задачей проведение расчетов через собственную блокчейн-платформу R-chain. Как это все устроено? Есть несколько компаний покупатель и поставщик, есть банк, который поддерживает эти расчетные функции. Все участники на своих серверах устанавливают ноды, узлы блокчейна, и далее информационные системы участников объединяются в единую сеть. Так появляется возможность вести общий реестр сделок и расчетов. В теории объяснили, теперь показываем в действии на демо.

Спасибо, что были с нами!
Второй открытый Demo Day мы уже запланировали на ноябрь, следите за анонсами здесь, в нашем корпоративном блоге, и до следующей встречи :)

В этом выпуске Андрей Балканский, руководитель лаборатории в центре юзабилити и смешанной реальности Университета ИТМО. Обсуждаем основные тренды, практику по теме юзабилити-тестирования. Плюс пререквизиты для начинающих в этой области.

Выпуск доступен здесь:

• Apple Podcasts

• Яндекс.Музыка

• Google Podcasts

• PodFM

Таймкоды по основным темам:

00:18 как понимать тренды: от флэт-дизайна к голосовым интерфейсам

09:35 с какими задачами в лабораторию центра юзабилити приходят компании

11:20 как продвигается работа над внутренними проектами Университета ИТМО

15:57 что есть внутри юзабилити-лаборатории, как она устроена

20:16 что находится на переднем крае этой дисциплины

23:42 пара слов о профильной магистерской программе

27:21 какие пререквизиты стоит освоить тем, кто интересуется этим направлением

Подкаст готовит и ведет@dmitrykabanov

Дополнительные материалы о подкасте:

• ITMO Research в числе победителей конкурса Золотое приложение

• Спортивное программирование: интервью с основателем Codeforces

• Какие темы вошли в первый сезон нашего подкаста о науке и технологиях

• Какие образовательные возможности предлагает новый центр Инфохимии

• Как мы готовим победителей олимпиад по молодежной робототехнике

Чат-бот МЕГИ и ИКЕА распознает 8 наиболее распространенных фракций отходов и ежедневно обрабатывает порядка 30 сообщений.Бот АкБарс Банка развивает сотрудников и в прошлом году обучил 54% специалистов в компании. Бот Президентской академии в Санкт-Петербурге отвечает на вопросы абитуриентов и в августе 2020 года помог более 1000 поступающим.При этом все кейсы были реализованы на визуальном конструкторе с NLU. Just AI, разработчик технологий в сфере разговорного AI,рассказывает о деталях создания чат-ботов.

Чат-бот МЕГИ и ИКЕА сортирует мусор

Ежегодно в России образуется около 70 млн тонн бытового мусора, это в 10 раз больше веса пирамиды Хеопса. При разложении отходы выделяют опасные химикаты, например, метан, которыми мы же потом и дышим.

МЕГА и ИКЕА реализуют глобальную стратегию по устойчивому развитию ДА людям и планете! и несколько лет назад запустили программу раздельного сбора мусора Правила Деления в Санкт-Петербурге. На территории двух центров МЕГА появились сортировочные пункты, было налажено сотрудничество с перерабатывающими предприятиями. Организаторы движения стали проводить лекции и сделали группу в социальной сети ВКонтакте, на момент публикации в ней состоят более 22 тыс. подписчиков.

Отчасти причина непопулярности экологических инициатив в России в недостаточном эко-образовании населения. Люди не понимают, как, куда и в каком виде можно сдавать отходы. Мы постоянно получали вопросы, принимается та или иная продукция, нужно ли снимать этикетки с бутылок. Нам хотелось сделать так, чтобы любой человек мог мгновенно получить ответы на запросы о маркировке и раздельном сборе отходов, - Александр Страдышев, куратор проекта, МЕГА Парнас.

Количество мусора можно сократить почти на 80%, если органические и пищевые отходы закапывать в почву, а опасные правильно утилизировать.

Организаторы получали так много сообщений ВКонтакте, что решили автоматизировать ответы на типовые запросы. Команда Правил Деления разработала в конструкторе Aimylogiс чат-бота, который теперь помогает администратору группы. Бот представляет собой интерактивный FAQ, где есть ответы на часто задаваемые вопросы: Можно ли это сдать, Где вы находитесь, Время работы станций, Нужно ли снимать этикетку и др.

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

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

В будущем команда Правил Деления планирует научить чат-бота распознавать маркировки по фото за несколько недель работы пользователи прислали боту 127 фотографий.

Результат

Чат-бот умеет распознавать 8 наиболее распространенных фракций отходов. Ежедневно он обрабатывает порядка 30 сообщений, а в пиковый день помог более чем 500 людям. За все время работы ботом воспользовались 4 430 человек.

Чат-бот Упсала-Цирка знает расписание спектаклей

Единственный в мире цирк для хулиганов Упсала-Цирк, где соединились акробатика, жонглирование, контемпорари, элементы уличной культуры, паркура и брейкданса, не получает финансирование от государства, а работает за счет продажи билетов и поддержки зрителей и партнеров. Для сбора пожертвований у цирка есть отдельный сайт со встроенным чат-ботом.

От AI-технологии в Упсала-Цирке в первую очередь хотели получить больше возможностей для общения со зрителями и волонтерами.

У многих компаний есть одна проблема: люди заходят на сайт, что-то узнают и просто уходят, а мы по факту узнаем, какой был трафик на сайте. Мы хотели собрать контактные данные пользователей, понять, что это за люди, и в дальнейшем отправлять им релевантную информацию, Екатерина Черемисина, PR-менеджер Упсала-Цирка.

Персонажем чат-бота стала собака по кличке Пина, которую списали с реальной собаки режиссера.

Цирк в целом про эмоции и удивление. Кто-то в шутку предложил сделать Пину персонажем чат-бота. Я зацепилась за эту мысль, потому что Пина постоянно в цирке, у всех на виду. Мне показалось, что такой персонаж может заинтересовать и завлечь пользователей, Екатерина Черемисина.

Задумка, действительно, удалась. Бегу за мячиком! Но на пару вопросов отвечу! пишет собака Пина в диалоге. Она может скинуть расписание спектаклей, сориентировать в курсах, объяснить, как добраться до цирка и каким транспортом лучше воспользоваться. В чат-боте есть ветки по вопросам сотрудничества, волонтерства, пожертвований. Также Пина предлагает всем заполнить контактную форму.

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

Результат

За два с половиной месяца работы в цирке роботизированная собака Пина помогла 144 уникальным пользователям. У команды Упсала-Цирка есть задумка встроить в чат-бота окошко для вноса пожертвований. Кроме того, сейчас цирк разрабатывает новый сайт и планирует интегрировать чат-бота туда.

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

Затрачено на конструктор чат-ботов Aimylogic на момент публикации: 3 960 руб.

Чат-бот АкБарс Банка развивает сотрудников

Технология чат-ботов востребована в HR-сфере, часто ее используются для задач прескрининга кандидатов, онбординга новых сотрудников и опросов. В АкБарс Банке взглянули на возможности технологии шире и разработали 9 ботов, задача которых обучение и развитие персонала.

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

Чат-боты АкБарс Банка помогают сотрудникам осваивать профессиональные навыки вроде владения Excel и развивать софт-скиллы. Бот Барсик обучает коммуникативным навыкам: он дает задание и варианты ответов, а потом проговаривает правильный вариант и объясняет, почему другие варианты неправильные.

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

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

Результат

За 3 месяца 2019 года с помощью чат-бота прошли обучение 1798 человек 31% сотрудников компании. Командировочные расходы, связанные с выездами на обучение, упали на 36%.

В 2020 году, когда командировки стали невозможны, значение удаленного обучения существенно возросло. Чат-бот обучил 2726 человек 54% сотрудников. По результатам опроса, в 27 удаленных регионах удовлетворенность обучением выросла с 62 до 75%.

Затрачено на конструктор чат-ботов Aimylogic на момент публикации: 47 200 руб.

Чат-бот Президентской академии помогает абитуриентам

Прием абитуриентов время предельной нагрузки для любого вуза. Чтобы сделать процесс поступления максимально комфортным, в Петербургском РАНХиГС при Президенте РФ действует проект Виртуальный помощник абитуриента. Суть программы в том, что каждый поступающий оставляет электронную почту и потом регулярно получает на нее полезную информацию.

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

По данным Совета ректоров Санкт-Петербурга и Ленинградской области, 70% из числа поступающих приезжают в наш город из других субъектов России. Чтобы процесс поступления в вуз для них был максимально простым и понятным, мы решили создать консультанта с искусственным интеллектом силу, которая никогда не спит и способна общаться с тысячью пользователями одновременно, говорит директор Северо-Западного института управления Владимир Шамахов.

Стоит сказать, что виртуальный консультант СЗИУ РАНХиГС коренной петербуржец, именно поэтому он готов ответить на вопросы не только о поступлении, но и рассказать абитуриентам о главных достопримечательностях города. Для этого потребуется задать лишь один вопрос: Куда сходить в Петербурге?.

В разработке бота участвовали сотрудники приемной комиссии. Они собрали обращения абитуриентов, провели мозговой штурм и определили часто задаваемые абитуриентами вопросы. После создания в конструкторе Aimylogic и публикации чат-бота стали анализировать обращения и добавлять новые ответы и вопросы.

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

Результат

Пик вопросов предсказуемо пришелся на время вступительных экзаменов. В августе 2020 года ботом воспользовались более 1000 человек.

Цветочный чат-бот принимает заказы в интернет-магазине

Цветы в интернет-магазине БукетОпт покупают клиенты из разных регионов и даже часовых поясов. Каждый день у них возникают вопросы по ассортименту, доставке и ценам. Сначала их можно было задать по телефону или в чате на сайте, отвечал на них оператор. Сотрудник заканчивал работу в 8 вечера часть вопросов оставалась без ответов, и компания теряла деньги.

Затем для удобства покупателей в БукетОпт подключили Открытые линии Битрикс24. Эта система собирает сообщения с разных площадок Instagram, ВКонтакте, WhatsApp, сохраняет в CRM и ставит в очередь к оператору. Оказалось, что людям удобно задавать вопросы в привычных социальных сетях и мессенджерах число обращений выросло в несколько раз, и ресурса одного оператора перестало хватать. Тогда в компании задумались о виртуальном помощнике.

Люди часто задают однотипные вопросы: оформление заказа, оплата, доставка, ассортимент, и гораздо проще, когда на них отвечает бот. Мы прослушали порядка 300 звонков и выделили 11 групп часто задаваемых вопросов, - Лада Трегубова, маркетолог БукетОпт.

На изучение материалов и инструкций Aimylogic ушла неделя. Основной задачей была верно составить логику вопросов и ответов для чат-бота.

По образованию я лингвист, и интенты, слова и словоформы подобрала достаточно быстро. Люди формулируют свои запросы очень по-разному, а смысл один, - Лада Трегубова.

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

Результат

Бот обслуживает около 1000 диалогов каждый месяц. Их результативность в компании отслеживают по utm-меткам. 1000 запросов дают 269 переходов на сайт, из посетивших интернет-магазин клиентов 23% добавляют заказ в корзину и 14% оплачивают покупку.

В интернет-магазине БукетОпт планируют, что в дальнейшем бот будет собирать контактные данные покупателей, создавать лиды в Битрикс24 и самостоятельно оформлять заказы. Это сократит время покупки и увеличит продуктивность всего интернет-магазина.

Затрачено на конструктор чат-ботов Aimylogic на момент публикации: 68 990 руб.

Читайте в статье: что такое диалоговый UX/UI и какего создавать, а также полезные лайфхаки при проектировании сценария длячат-бота.

В марте 2021 годааналитики Voicebot провели опрос300 маркетологов и узнали, что они думают про голосовых помощников. Оказалось, что более 60% специалистов уверены в пользе голосовых ассистентов длямаркетинга. Виртуальные помощники и чат-боты больше не новинка и не пустой повод дляхайпав новостях. Бизнесактивно использует разговорные технологии дляэффективной коммуникации спользователями, дляпрямых продаж и создания прочных связей сбудущими и настоящими клиентами. И мы в Just AI уверены, что в будущем эта тенденция будет толькорасти.

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

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

Для новичков. Что такое диалоговый UX и в чем его отличие отдиалогового UI?

Начнем спростого: UX это user experience или опыт, который получает пользователь в ходе его взаимодействия синтерфейсом сервиса, продукта или услуги. UI это user interface, пользовательский интерфейсили то, что мы привыкли называть дизайном.

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

А диалоговый UI это интерфейсы, которые позволяют взаимодействовать между пользователем и системой. Элементом диалога может стать голосовой или текстовый ввод и вывод информации, а также модальное окно на сайте, поп-ап в приложении и т. п.

В рамках диалогового UI мы рассматриваем два условных типа интерфейсов: голосовой и разговорный. Кажется, что это синонимы, но не все такпросто. Под разговорным интерфейсом или Conversational User Interface (CUI) подразумеваются все интерфейсы, скоторыми можно общаться на естественном языке кактекстом, таки голосом.

Соответственно, в понятие CUI входит Voice User Interface (VUI) или голосовой интерфейс. Он предполагает взаимодействие сустройством спомощью голоса.

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

Закрепим. Итак, Алиса в Яндекс.Станции это VUI, а в смартфоне, где сней можно говорить голосом и чатиться CUI. А все вместе это диалоговый UI.

Кто создает диалоговый UX и UI при проектировании чат-ботов

Созданием диалогового UХ и UI занимается отдельный специалист. Он разрабатывает диалоговый пользовательский интерфейс, продумывая пользовательский опыт.В Just AI мы называем такого специалиста дизайнер разговорных интерфейсов.

Но в русском языке точный термин до сих пор не закрепился. Поэтому можно встретить разные переводы. Так, на HH.ru мы встретили 17 разных названий вакансий: дизайнер диалогов, диалоговый редактор, digital-лингвист, voice UX designer, диалог-дизайнер, сценарист чат-бота и такдалее. Подробности о нашем исследовании смотрите в вебинаре Создатели разговорных интерфейсов: кто они и чем занимаются?. На нем мы рассказали, каксделать так, чтобы специалисты и компании нашли друг друга.

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

Для продвинутых. Какразработать диалоговый UX/UI

Шаг 1. Узнайте, подходит ли разговорный интерфейсдляваших задач.

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

Чек-лист диалогового UX/UI

• Ваш вопросможно решить только при участии человека.

• В качестве формата диалога подойдет вопрос-ответ без дополнительных уточнений.

• Чтобы выполнить задачу, сейчаснужно кликать на экран несколько раз.

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

• Сейчаспользователю сложно или долго искать, где решить проблему.

• Задачу можно выполнить, одновременно делая другие дела.

• Задачу можно выполнить, даже если глаза и руки пользователя заняты другими делами.

• Пользователю комфортно говорить или писать о теме задачи.

Обратите внимание, что голосовой интерфейсможет не подойти в следующих ситуациях и пространствах:

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

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

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

• В случаях, когда речь идет о чем-то личном. Если в переписке счат-ботом необходимо сообщить персональные данные или личные сведения, то голосовой интерфейсдлятакого не подойдет.

Шаг 2. Узнайте все о пользователе

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

Чтобы составить пользовательскую персону, дляначала ответьте длясебя на вопросы:

• Кто ваши пользователи?

• Что хотят сделать? Какую проблему хотят решить?

• Какони делают это сейчас?

• Какие слова или фразы они используют, говоря о задаче?

• Каков контекст, обстоятельства этих задач или проблем пользователей?

Продумайте tone of voice то, какую речь будет использовать ботили ассистент при общении спользователем. Если это чат-бот, какон обращается кклиенту на ты или на вы? Использует ли он профессиональные термины? Умеет ли общаться на отвлеченные темы и шутить,какботКвик?

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

Чтобы найти tone of voice, поизучайте ресурсы, на которых сидят пользователи это могут быть Известия, Ревдинский рабочий, Одноклассники, ВКонтакте и такдалее.

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

Ирина Степанова, аналитикразговорных интерфейсов отдела лингвистики в компании Just AI

Сравните сами, какможет отличаться Tone of Voice в сообщениях отразных компаний:

1. Привет, Иван! Посмотри новые тарифы на сайте в разделе Цены! Мы подготовили длятебя классные предложения!

2. Здравствуйте, Иван Иванович. Просим обратить внимание, что с1.06.2021 обновляются Тарифы. Актуальная информация находится в соответствующем разделе.

При создании диалогов обязательно используйтемаксимы Грайса. Это правила ведения разговора, которые подчиняются принципу кооперации, введенному философом Гербертом Полом Грайсом. Они актуальны и дляголосового ассистента сискусственным интеллектом, и дляпростого бота в Facebook Messenger.

Четыре максимы помогают сделать диалог бота спользователем наиболее человечным и эффективным.

Максима качества информации:

• не говори того, что считаешь ложным;

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

Максима количества информации:

• изложи не меньше информации, чем требуется;

• изложи не больше информации, чем требуется.

Максима релевантности:

• не отходи оттемы.

Максима ясности:

• будь последовательным:

• избегай неясности;

• избегай двусмысленности;

• будь краток;

• будь систематичен.

В кратком изложении они описаны на картинке.

Шаг 3. Спроектируйте диалог

Создание сценария чат-бота стоит начать со схемы диалога в голосовом или текстовом каналах (Voice Flow или Chat Flow). Это диаграмма, которая показывает пути, через которые может идти диалог.

Для начала пропишите happy path или счастливый путь идеальный диалог пользователя сботом отначала и до конца. А затем продумайте ответвления, которые могут возникнуть на этом пути: сложности, дополнительные вопросы, уточнения.

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

Шаг 4. Пропишите текстовый сценарий

Чтобы выполнить этотшаг, берите за основу путь пользователя и выбранный tone of voice. Готовые кусочки диалогов потом пойдут в код и превратятся в реальные реплики бота или ассистента.

Шаг 5. Сборка прототипа диалога

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

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

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

Екатерина Юлина, Head of Product UX, Just AI

Чтобы узнать, какими будут дальнейшие шаги и увидеть практикум сборки прототипа диалога, посмотрите наш вебинар Дизайн голосовых интерфейсов: как, что, где и главное, зачем?. Специалисты Just AI рассказали и показали, каксоздают UX и UI при проектировании чат-бота HR дляпроизводственной компании, а также поделились практическими советами.

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