Скотт Харф привёл результат исследования минимального размера кнопки для тач-интерфейсов и сравнил с рекомендациями Apple, Google и Microsoft.

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

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

In English (копия в Вебархиве). #button #mobile

Эдвард Скотт написал о хлебных крошках в мобильных версиях интернет-магазинов.

— Основная навигация в них обычно скрыта: пользователю сложнее понять, где в иерархии сайта он находится, а также сложнее перемещаться через главное меню;
— Хлебные крошки делают жизнь пользователя проще;
— Размещайте в них полный путь к текущему товару или хотя бы ключевые уровни иерархии;
— Чтобы они не были слишком длинными: а) избегайте чрезмерной категоризации (то, что должно быть фильтром, может быть ошибочно реализовано как категория), б) уберите из них ссылки на главную страницу (на неё можно попасть, нажав на логотип) и текущий товар, в) сократите названия категорий;
— Если строка с хлебными крошками всё ещё слишком длинная, дайте прокручивать её по горизонтали. Для большинства пользователей это естественно (особенно, если начало или конец строки будут обрезаться и тем самым намекать на возможность прокрутки);
— Добавьте отступы, чтобы строка с хлебными крошками не сливалась с другими элементами в верхней части страницы;
— Их оформление должно отличаться от других элементов на странице. Используйте подчёркивание и стандартные разделители > и / между уровнями иерархии.

In English. #breadcrumbs #mobile

Леви Ковач написал о мобильных формах.

— Если в раскрывающемся списке от 2 до 5 вариантов для выбора, лучше заменить его на Segmented Control. Так сделать выбор можно меньшим количеством нажатий;
— Если вариантов 2 и это, например, «Показать» и «Скрыть», можно заменить его на чекбокс или переключатель;
— Если варианты — это значения в рамках определённого диапазона, можно использовать ползунок;
— Если варианты — числовые значения и пользователи обычно не сильно меняют значения по умолчанию, подойдёт степпер. Меньше нажатий и ошибок;
— Иногда несколько раскрывающихся списков можно объединить в один. Например, выбор даты;
— Располагайте поля в одну колонку;
— Сообщения об ошибке при заполнении поля показывайте рядом с этим полем и показывайте по мере заполнения формы, не перечисляйте неправильно заполненные поля в конце или начале формы;
— Не повторяйте, что поле обязательно для заполнения. Старайтесь исключить из формы необязательные поля. Подписывайте необязательные поля, если такие всё-таки оказались в форме;
— Группируйте связанные поля.

In English. #form #mobile

Станислав Хрусталёв написал о быстрых действиях в iOS.

— Разместите в них полезные действия, часто совершаемые пользователями в приложении. Хорошие кандидаты — действия, для перехода к которым в приложении надо больше одного касания;
— Нет смысла размещать там переход на главный экран, который открывается при запуске приложения;
— Добавьте 4 действия (столько сейчас возможно) — кому-то из пользователей это упростит жизнь. Можно отслеживать использование быстрых действий и заменять непопулярные;
— Но не обновляйте их слишком часто и кардинально, чтобы не ломать привычки;
— Действия могут быть динамическими и зависеть от контекста и стадии пользовательского пути. Скрывайте нерелевантные действия. Например, «Открыть заказы» не имеет смысла, если пользователь ещё ничего не заказывал;
— Расскажите о быстрых действиях в онбординге. Не все пользователи iOS знакомы с этой функцией;
— Проверьте, что названия у действий есть, они краткие, не обрезаются, локализованы, форматированы единообразно, дают понять, что произойдёт. Сделать действие понятнее помогают подзаголовки;
— Если добавлять подзаголовки, то лучше для всех пунктов;
— Добавьте релевантные иконки. Они не должны дублироваться. Хорошо, если метафоры совпадают с иконками таких же действий в приложении;
— Сделайте толщину иконок и размер такими же, как у иконок системных действий;
— Для приложения магазина в быстрых действиях можно разместить: бонусная карта (и статус программы лояльности в подзаголовке), акции, новинки, избранное, список покупок, корзина, где мой заказ, штрихкод заказа (или данные для его получения), оценка заказа, промокод, магазины, авторизация.

#ecommerce #mobile

Фрэнк Рауш написал о шаблонах навигации в iOS-приложениях.

— Чаще всего архитектура приложений — иерархическое дерево с несколькими уровнями вложенности;
— Навигация происходит по структуре дерева. Из списка пользователь переходит к новому списку или конечным экранам, а возвращается назад по кнопке «<»;
— Плоская структура: шаблон предназначен для навигации между ключевыми экранами с помощью нижней панели на телефоне и боковой на планшете;
— Ключевых экранов может быть не более 5, один из пунктов меню всегда выбран, панель доступна всегда, когда не перекрыта модальным окном;
— Пирамидальная структура: шаблон позволяет быстро перемещаться между элементами одного уровня иерархии (например, свайпами), не возвращаясь на родительский экран;
— Модальная навигация: высокоприоритетные окна (требуют принятия решения, диалоги), низкоприоритетные (не требуют принятия решения, подсказки, попапы, всплывающие меню);
— Немодальная навигация: уведомления, интерактивные элементы вроде индикатора настройки громкости;
— Внутренняя навигация: изменение состояния (пользователь остаётся на том же экране), пошаговая навигация (ряд экранов объединены в линейный флоу и размещены в модальном окне).

In English. #mobile #navigation

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

— Их рекомендуют делать минимум 44×44 px. Поэтому на нижней панели меню поместится не более 5 пунктов;
— На разных экранах пиксели разные, поэтому следует говорить о DIPs (dp), device independent pixel;
— Таблица для перевода pt в px и em, в SP или DP для Android, в pt для iOS и в DIP или px для Windows;
— Минимальная область нажатия может быть разной: 11 мм (31 pt / 42 px) в верхней части экрана, 12 мм (34 pt / 46 px) в нижней, 7 мм (20 pt / 27 px) в центре;
— Согласно требованиям WCAG 2.1 уровня ААА, если область нажатия находится в предложении или текстовом блоке, она может быть 27 px;
— Предлагайте отдельные контролы для точных манипуляций. Можно поворачивать изображения жестом, но удобнее может быть специальный слайдер или кнопка;
— Иногда несколько касаний лучше одного. Можно выбирать цвет товара нажатием на маленькие кружочки, а можно при нажатии на блок с кружочками отобразить специальную панель выбора цвета с удобными большими контролами;
— Максимизируйте кликабельные области. Например, чтобы нажать можно было на всю карточку, а не только заголовок, или на весь прямоугольник аккордеона.

In English. Конвертер mm в px и обратно Александра Овчаренко. #mobile

Юля Гранкина написала о виджетах.

— Виджет может поднять DAU приложения. Он привлекает внимание на домашнем экране. Упрощённое взаимодействие повышает лояльность продукту;
— Создавая виджет, надо определить основную функцию приложения;
— Виджеты включают 1) важную информацию, которую можно узнать, не открывая приложения, вроде погоды, 2) элементы управления основным приложением вроде музыкального проигрывателя, 3) коллекции потенциально интересного контента вроде фильмов в онлайн-кинотеатре;
— Данные о пользовательских финансах лучше не выносить в виджет;
— В виджетах разных форматов стоит использовать одни и те же размеры шрифтов и менять только объём информации;
— Актуальные размеры для iOS можно посмотреть в Human Interface Guidelines. В Андроиде размеры виджетов завязаны на размер ячейки, в которую вписывается иконка и название приложения;
— Можно предлагать пользователям варианты виджета с разной функциональностью;
— Стоит проработать пустое состояние, чтобы оно мотивировало сделать то, что приведёт к заполнению виджета. Можно и просто показывать коллекции контента или связанную с приложением статистику;
— Увеличение шрифта в системе на виджеты тоже влияет. Проверяйте, какой максимум текста может поместиться;
— Практика показывает, что минимальное время для смены контента на виджете — от 5 минут на iOS до 15 на Андроиде;
— В iOS нажатие на виджет открывает приложение. Если его размер превышает Small, можно добавить разные области нажатия. В Андроиде возможно более сложное взаимодействие с виджетом.

#widget #mobile

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

— Блокировать действие уместно, когда не выполнены условия для его выполнения;
— Проблема в том, что условия могут быть разными: не хватает данных от пользователя (на текущем экране, прошлом, в сторонних сервисах вроде подтверждения имейла) или компонентов программы (медленный интернет или вычисления, внутренние ошибки);
— Неактивная кнопка не подскажет, в чём проблема, а также плохо заметна;
— Блокировка кнопок может быть полезна для необратимых деструктивных действий, чтобы совершить ошибку было сложнее;
— В мобильной форме фиксированная в нижней части экрана кнопка занимает место, и её преждевременное нажатие (если она не заблокирована) приводит к ошибке. Лучше расположить её в конце формы — пользователь увидит её, прокрутив экран с формой до конца, и она как раз окажется под пальцем;
— Если форма занимает меньше одного экрана, кнопку можно закрепить в нижней части экрана, чтобы на неё легко было нажать;
— Таким образом в длинных и коротких формах пользователь будет видеть кнопки в одном и том же месте.

#form #button #mobile

Ксения Толокнова и Марина Сапожникова написали о поиске в мобильных приложениях.

— Точкой входа в поиск может быть поле поиска (в верхней, нижней части экрана и ближе к середине; поиск в этом случае — ключевая функция или основной способ взаимодействия с контентом), иконка лупы в нижней навигации (важность функции меньше), иконка лупы в навбаре (важность ещё меньше). Точка входа может быть спрятана, например, в раскрывающемся меню;
— Поиск может быть глобальным (по всему приложению) и локальным (по экрану или разделу), открываться на новом или на том же экране (для локального поиска и фильтрации контента);
— Поисковая выдача может быть простой (однородной), с категориями и фильтрами, с секциями (если хочется разделить контент и не вводить навигацию в виде категорий и фильтров);
— Мультипоиск позволяет обрабатывать несколько запросов одновременно. Например, искать недвижимость в нескольких районах (Zillow) или по фото и тексту одновременно (Google);
— Продумайте, как пользователь будет очищать ввод в поле (скорее всего крестиком в поле) и выходить из режима поиска («Отменить» в iOS, стрелка «Назад» в MD3);
— Результаты лучше выводить после ввода 1–3 символов. Запрос лучше отправлять, когда возникает пауза во вводе;
— Рекомендации до ввода поискового запроса крайне полезны. Кроме повышения удобства (сохранённые, недавние, популярные запросы) они могут стать инструментом дополнительных продаж;
— Не забывайте о подсказках внутри нативной клавиатуры. Их немного, но больше, чем можно разместить в поле поиска.

#search #mobile

Владимир Гайдадей написал об управлении интерфейсом одним пальцем.

— Существующие решения: режим одной руки (активируется свайпом вниз в нижней части экрана), когда верхняя часть интерфейса смещается в центр экрана. Так можно дотянуться до кнопки «Назад» в левом верхнем углу;
— Режим одной руки на экранной клавиатуре уменьшает её, позволяя дотянуться до всех букв большим пальцем;
— Кажется, они не особо популярны, так как проще перехватить телефон или использовать вторую руку. И они не учитывают, что палец может находиться не у нижней части телефона;
— Samsung, Xiaomi умеют уменьшить весь интерфейс под диагональ в 4 дюйма (можно настроить) и расположить в правом нижнем углу экрана;
— Обычно скрол останавливается, когда нижняя часть прокручиваемого контента достигает нижней стороны экрана или верхняя часть — верхней стороны;
— Можно реализовать длинный скрол — останавливать его, когда нижняя часть контента достигает верхней стороны экрана или верхняя часть — нижней. Так элемент, на который пользователь хочет нажать, можно проскролить в любую часть экрана, где бы ни находился палец;
— С одним пальцем пользователю остаются свайпы и тапы (одинарные, двойные и так далее);
— Свайп вправо можно оставить под возвращение назад, кроме главного экрана, где с ним может быть связано другое действие;
— Свайп влево в этой концепции подойдёт для вызова меню с действиями, которое также обладает длинным скролом.

#mobile

Ксения Толокнова написала о мобильных клавиатурах.

— При проектировании мобильных форм стоит подумать о подходящих экранных клавиатурах;
— Клавиатура зависит от типа поля ввода, которых около 50 на iOS и 30 на Android;
— Например, для ввода имейла на iOS на клавиатуре с буквами появляются «.» и «@». Для ввода телефона используется цифровая клавиатура с символами «+», «*» и «#»;
— Есть более специфичные варианты, заточенные под ввод определённых наборов символов. Например, dectimalPad для ввода нецелых чисел;
— Можно скрыть строку с рекомендациями (при вводе имейла в ней может быть имейл пользователя), настроить действия при вводе, например: автозамену при орфографических ошибках, написание новых предложений с заглавной буквы;
— Во многих клавиатурах есть кнопка действия (может быть заблокированной). По умолчанию это Return, которая в зависимости от типа поля переключает на следующее поле, создаваёт новую строку, сворачивает клавиатуру;
— В iOS их 12 вариантов: Next переключает на следующий элемент ввода или шаг, Continue переводит на следующий шаг, Search запускает поиск;
— Если в вашей форме на кнопке написано Continue, здорово, если на экранной клавиатуре тоже будет Continue;
— Можно настроить, как скрывать клавиатуру (или не скрывать совсем, как в Ноушене). В iOS-приложении Телеграма она скрывается свайпом вниз, у Ютуба — минимальной прокруткой контента;
— Чтобы в тулбаре появлялись коды из смс, типом поля должно быть OTP;
— Над клавиатурой можно добавить кастомный тулбар (Ноушен, Твиттер). Их можно стилизовать под нативный с помощью серого фона (Google App, Revolut);
— Например, в приложении MyFitnessPal в тулбаре можно менять единицы изменения, одновременно с этим вводя числа в соответствующее поле.

Копия статьи. #mobile #form

Энтони Ценг написал, как в мобильных интерфейсах можно иногда отказаться от кнопки «Назад».

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

In English. #navigation #mobile

Станислав Хрусталёв написал, как с помощью Action button создать ещё одну точку контакта с продуктом.

— Action button заменила переключатель бесшумного режима в iPhone 15 Pro и всех версиях iPhone 16;
— Пользователь может привязать к ней любое действие. Например: то же переключение бесшумного режима или быструю команду (шорткат);
— В приложении «Команды» (Shortcuts) пользователь может создавать команды, запускающие разные последовательности действий в приложениях. Например: открыть музыкальное приложение и запустить любимый плейлист;
— Какие команды в каких приложениях доступны, зависит от разработчиков, всё это надо разрабатывать;
— В сегменте электронной коммерции в России команды в приложениях встречаются редко (ВкусВилл, Золотое Яблоко, AliExpress). Они не были популярны, так как запускать шорткаты можно было через Сири и Поиск;
— Разработчики могут создавать команды (намерения) на основе ключевых действий в своих приложениях, а клиенты — выбирать их в качестве быстрой команды и запускать выделенной физической кнопкой;
— Например, для банковского приложения таким намерением может быть открытие камеры для оплаты по QR-коду через СБП;
— Для такси — заказ такси на работу, когда ты дома, и обратно, когда на работе.

#mobile

Фёдор Миронов написал, как ускорить подготовку макетов мобильного приложения под вторую платформу с помощью переменных в Фигме.

— Создайте коллекции переменных, которые будут отвечать за параметры интерфейса;
— Коллекция Platform: стиль шрифтов, размеры устройств, пропорции картинок;
— Например, переменная Device width для iOS может иметь значение 393, для Android — 412. А переменная Font: SF Pro и Roboto;
— Коллекция Typography: размер шрифта, межстрочное и межбуквенное расстояние, вес;
— Чтобы создавать дизайн с учётом доступности и масштабировать шрифты, основные параметры можно подтягивать из коллекции Dynamic typography (достаточно базового и максимального значения размера шрифта и межстрочного расстояния);
— Для названий цветов удобно использовать токены из Material Design 3, так как цвета на обеих платформах называются одинаково и есть их контекстные названия;
— Универсальные компоненты вроде кнопок выглядят одинаково на разных платформах, меняется только текстовый стиль;
— Платформенные компоненты вроде Navbar, которые сильно отличаются, лучше сделать вариантами одного компонента;
— Вложенными компонентами легче управлять по отдельности при большом количестве вариантов. Важно одинаково называть их параметры для iOS и Android, чтобы при смене платформы сохранялся контент.

Копия в Оди. #mobile #figma

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

— Понадобится Node.js, Expo, Git и редактор кода Cursor;
— Expo даёт набор инструментов для создания кроссплатформенных приложений (мобайл и веб) на базе React Native;
— Прототип можно запускать через Expo Go на телефоне как обычное приложение (на любой операционной системе) с нативным поведением, виброоткликом, гироскопом и так далее;
— Git нужен для сохранения всей истории изменений файлов проекта. Полезно при вайбкодинге, так как Курсор может откатить изменения только в пределах одного контекстного окна;
— У Курсора есть Rules and Memories, где можно указать место хранения SVG-ассетов и выбранную библиотеку для анимации (например, React Reanimated). Правила могут распространяться на конкретный проект Project Rules и на все проекты User Rules;
— Пропишите в правилах, что приложение будет в связке React Native и Expo. Возьмите в Фигме personal access token и укажите его в настройках MCP. Так Курсор сможет ходить в Фигму за макетами;
— Если не работаете с дизайн-системой, потратьте время на нормальное именование элементов в Фигме. Так можно будет обращаться к конкретным элементам, а ИИ даже сможет предугадывать ваши желания при создании прототипа;
— Создайте шаблонный проект приложения со стандартной структурой, сбросьте шаблон, чтобы получить чистый проект;
— Начать эксперименты лучше с файла index.tsx, который отвечает за главную страницу;
— Скопируйте в чат ссылку на фрейм главной страницы в Фигме и скажите использовать функцию get_code (команда изучить структуру фрейма), чтобы ИИ воссоздал макет в коде;
— Так можно проверять решения без разработчиков, лучше разобраться в терминологии и логике кода.

#ai #prototype #mobile

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

— Вёрстка — финальный макет, передаваемый в разработку, и его реализация в коде, которую разработчик передаёт дизайнеру на проверку;
— iOS, Android, WebView, десктопный и мобильный веб (плюс горизонтальная ориентация и планшеты) имеют особенности и технические ограничения, которые надо учитывать;
— Есть платформенные паттерны, но их могут игнорировать, пытаясь сформировать общий паттерн использования приложения, не зависящий от платформы;
— Технически на макете не всё собирается через таблицу или стек. Применять только Auto layout невозможно, так как элементы могут настраиваться через констрейнты, закрепляться на экране поверх остального контента, оставаясь его частью;
— Изображение не должно искажаться при изменении ширины контейнера. Как оно должно вести себя при увеличении ширины вьюпорта?
— Учитывайте это, и один макет будет работать с любой вёрсткой: широкой и узкой, горизонтальной и вертикальной;
— Паттерны навигации в iOS: Push (линейная со стрелочкой «Назад») и Present (модальная с крестиком). Можно комбинировать: внутри модальной использовать линейную (но пользователь может ошибочно закрыть весь флоу, по которому двигался в модальности);
— Чтобы не путаться, заведите под эти паттерны шаблоны в дизайн-системе. И вообще фиксируйте все правила, о которых договорились с разработчиками;
— Определяйте типы элементов в макете. От типа зависят их свойства: какие есть состояния, могут ли отображать загрузку и ошибку, нативные или кастомные это элементы, должны ли нажиматься;
— Передать информацию о типе можно, использовав определённые компоненты дизайн-системы (по крайней мере так реализовано в Альфа-Банке);
— Если этого не делать, разработчики будут возвращаться с вопросами или даже делать так, как сами (неправильно) поняли;
— Экран может быть реализован с помощью разных технологий: фронтовая вёрстка, серверная (например, BDUI), комбинированная;
— Технология определяет допустимый набор элементов и возможности их кастомизации. Например, весь экран — это модуль, и его можно только переиспользовать;
— Макеты — это техническое задание. Качественное ТЗ — залог лёгкого последующего дизайн-ревью. Но чтобы делать качественно, надо общаться с разработчиками (не стесняясь задавать глупые вопросы) и понимать технические нюансы.

#mobile #handoff

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

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

#book #accessibility #mobile