Эрик Чанг написал о навигации с помощью табов (вкладок).

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

In English. #tab

Михаил Нозик написал, как презентовать объёмные данные, таблицы и отчёты.

— Например, в виде материала для презентации дали скриншот с отчётом из 1С;
— Если просто вставить его в презентацию, слушатели залипнут в таблицу и пропустят рассказ спикера. Показывать на экране стоит то, что воспринимается быстро, пока люди слушают;
— Отчёт может доказывать, что данные не взяты с потолка. Покажите основные цифры и часть скриншота, чтобы люди поняли, что это, но не стали изучать его подробно;
— Если данные на скриншоте и есть предмет презентации, покажите его целиком ненадолго, чтобы объяснить, о чём речь. Затем подсвечивайте и увеличивайте те места, на которые надо обратить внимание (не бойтесь сделать много слайдов для этого);
— Можно пройтись по скриншоту вживую, от фрагмента к фрагменту. Но важно отрепетировать, чтобы избежать беспорядочного метания по экрану.

#slides #presentation

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

— В книге он рассказывает, как незрячие пользуются скринридером VoiceOver, как управлять телефоном голосом, как полностью парализованный человек может отдавать команды;
— А также: как подготовить к такому использованию iOS-приложение, как адаптировать интерфейс для увеличенного размера текста и как это всё протестировать;
— Книга ориентирована на разработчиков, но полезна и дизайнерам, поскольку адаптировать интерфейсы можно на уровне контролов, экранов и сценариев;
— Часть глав ещё в процессе публикации. Например, глав об адаптации для увеличенного размера текста пока нет;
— Есть большая статья — гайд о том, как сделать iOS-приложение доступнее.

#book #accessibility #mobile

В «Работягах» написали, чем заменить сложные таблицы в b2b-интерфейсах.

— Таблица с фильтрами, сортировкой, быстрыми действиями — привычный паттерн для работы с любым массивом данных;
— Она удобна и понятна команде разработки. Они могут решить использовать её без каких-либо исследований;
— Как универсальное решение она плохо помогает выполнять конкретные задачи и часто просто отображает данные;
— Когда стоит задуматься о замене: слишком много колонок; горизонтальный скрол; чтобы понять суть, приходится открывать каждую строку или использовать правильные комбинации фильтров; пользователи только выгружают данные, чтобы обработать их в Экселе;
— Не трогайте таблицы, если пользователь думает ими. В этом случае попробуйте их улучшить закреплением колонок, инлайн-редактированием и так далее;
— Таблицы хороши для сравнения однотипных сущностей по одинаковым параметрам, быстрого сканирования большого массива и поиска расхождений, массовой обработки данных;
— Если у сущностей есть жизненный цикл (лиды идут по воронке), таблицу можно заменить на канбан-доску: сразу видно, где затор, легко управлять потоком;
— Если пользователь обрабатывает поток сущностей, подойдёт очередь. Важно выбрать параметры для отображения, которые помогают приоритизировать сущности;
— Если важны даты начала и окончания и связь сущностей друг с другом, удобнее будет календарь, таймлайн или диаграмма Ганта. Важно дать возможность управления данными при просмотре в этом режиме;
— Дашборд заменяет таблицу с метриками, в которой надо самостоятельно искать отклонения, держа в голове норму;
— Карточки объектов удобнее, если нужна возможность рассмотреть каждую сущность целиком. В таблице картинки, теги, длинные названия, статусы и действия раздувают строки, и важные признаки теряются;
— Ещё вариант: AI-слой, который будет анализировать данные таблицы (отвечают на вопрос «Что у нас есть») и, руководствуясь продуктовой логикой, подсказывать, «Что делать»: саммаризировать, выявлять отклонения, предлагать кнопки действий по каждому пункту;
— Чтобы выбрать подходящий паттерн, надо понять, кто работает с интерфейсом и ради чего, какие вообще свойства бывают у объекта, какие из них нужны разным ролям и какие нужны для выполнения конкретных действий;
— Не стоит избавляться от таблиц полностью: в b2b почти всегда нужен режим «Все записи» для массового редактирования, экспорта, сверки, аудита продвинутыми пользователями.

#table #b2b

Отношения между сценарием и навигацией в интерфейсе

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

Что будет, если просто положить сценарии в основу навигации?

Когда сценариев очень мало, может получиться неплохой интерфейс. Если есть всего три-пять действий, за которыми человек приходит в интерфейс, и мы просто делаем для них кнопки, то всё будет понятно и удобно. Это то, что я предлагал для ПВЗ «Яндекс-маркета»:
https://ilyabirman.ru/meanwhile/all/interfeys-pvz-yandeks-marketa/

Но такие интерфейсы встречаются редко. Даже в небольшом продукте есть множество связей между функциями, и число сценариев огромно. Если в таком случае начать строить навигационную модель вокруг сценариев, в интерфейсе станет невозможно разобраться. В заметке об архиве вакансий я как раз указываю на эту проблему:
https://ilyabirman.ru/meanwhile/all/arhiv-vakansiy-ne-mozhet-byt-podrazdelom-sozdaniya-vakansii/

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

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

Ну и что, как построить навигационную модель вокруг этого сценария? Да никак.

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

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

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

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