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

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

#ecommerce

Игорь Штанг (уже давно) написал о висячей пунктуации из 120-го параграфа «Ководства».

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

#typography

Иван Мрачко написал о пользе прототипов в заказной разработке.

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

#prototype

⚡️ Изящно проработанный сценарий получения фидбека.

Vlad Dugnist разместил вот такое сообщение в iOS приложении. Его видно по лонг-тапу, обычно перед попыткой удалить аппку. В итоге c этой точки прилетает 50% от всего фидбека от юзеров.

@tg_knl

Никита Прокопов написал о круглых чекбоксах [In English].

— Чекбоксы от радиокнопок отличаются тем, что они квадратные, внутри отображается галочка, когда чекбокс выбран, можно выбрать любое количество чекбоксов в группе. Радиокнопку в группе можно выбрать только одну;
— В ранних версиях операционных систем (Mac OS 7.5, 1994 год и Windows for Workgroups 3.11, 1993 год) можно встретить крестики вместо галочек;
— Но форма радиокнопок и чекбоксов отличалась уже в 90-х, и операционные системы придерживались этого правила;
— В последнее время в вебе можно было встретить радиокнопки с галочками (Twitter), а также квадратные радиокнопки с галочками (Yandex Maps);
— Веб всегда был пластичнее, но подобное стало встречаться и в нативных приложениях (Telegram for macOS);
— В некоторых продуктах (Yandex Maps, опросы в Telegram Web) рядом можно встретить радиогруппу и группу чекбоксов, которые работают по-разному (чекбоксов можно выбрать несколько), но визуально вообще никак не отличаются;
— Создатели операционных систем до сих пор придерживались изначальной концепции, но теперь в библиотеке Apple для visionOS появились круглые чекбоксы. Видимо, стройной концепции с круглыми радиокнопками и квадратными чекбоксами пришёл конец.

#radio_button #checkbox

Анастасия Скопина написала об эмодзи в интерфейсе.

— Допустимо ли их использовать, зависит от сферы продукта, целевой аудитории, географии и Tone of Voice;
— Скорее да: сервисы для детей, сфера красоты, дизайн. Скорее нет: B2B, B2G, медицина, ToV задаёт строгий официальный стиль;
— С эмодзи 73% людей считают вас более дружелюбным. Но люди постарше чаще воспринимают их негативно;
— Одни эмодзи могут по-разному воспринимать в разных странах. Например, в арабских странах 🙏 (сложенные руки) почти не используется, так как не ассоциируется с молитвой, в Китае 👋 (взмах руки) символизирует разрыв отношений и дружбы;
— Эмодзи хорошо работают на приветственном экране (сделать первый контакт как можно дружелюбнее), при выборе пола или страны (можно заменить иконки), в пустых состояниях (разбавить сухой текст), диалогах (более человечное общение, визуальные якоря), как бейджи (объединить товары в группу), в попапах (показать, позитивное это сообщение или нет, и если нет — немного сгладить негатив);
— Кроме того их часто используют в пушах, формах обратной связи, некоторых кнопках (как замена иконки или усилитель текста);
— В некоторых продуктах вроде Ноушена эмодзи помогают пользователю лучше ориентироваться в своём контенте.

#image

Женя Крупина написала о прокачке нетворкинга в компании через совместный просмотр докладов.

— Потребность в этом появилась после реструктуризации, надо было лучше узнать друг друга, научиться работать вместе, научиться обогащать продукт и друг друга за счёт крутых скилов и уникального опыта отдельных специалистов;
— Хорошо себя показал совместный просмотр докладов на продуктовые темы и около того. Он оказался и вовлекающим, и развивающим, и полезным для работы;
— Наибольшую пользу приносит не сам доклад, а его обсуждение: нажимали на паузу, сразу докручивали, как применить в своём продукте, спорили, смеялись;
— В группе просмотр обучающего контента проходит осознаннее;
— В итоге за 3 месяца провели уже 6 просмотров и не только прокачали нетворкинг, но и применили отдельные находки в работе.

#management

Андрей Шапиро написал о схеме преобразования данных в системе с интерфейсом.

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

#analysis

Павел Шерер написал 4-ю статью цикла о функциональной архитектуре.

— V-модель разработки делает акцент на тестировании, что позволяет выпускать стабильные продукты за оптимальное время;
— Но она не гарантирует качество, так как всегда кто-то формирует видение (дизайнер с макетами, аналитик с требованиями), а остальные от них отталкиваются. При этом первые плохо понимают технические ограничения, а вторые потребности пользователей;
— В разработку уходят требования, а значит, «строители» принимают решения за «архитекторов»;
— На старте проекта много белых пятен и хаоса, но их закрашивание хаос не уменьшает, так как специалисты почти всегда уходят в детали и принимают решения без понимания общей картины. В моменте кажется, что ситуация под контролем, но потом часть наработок оказывается в корзине;
— Работа над функциональной архитектурой подразумевает этап высокоуровневого проектирования, продумывание базиса, на который потом можно положить детальное описание функций;
— Нет шаблонов ФА, которые могут переходить из проекта в проект, так как архитектура должна подстраиваться под продуктовые реалии. Но могут быть методологические форматы отдельных артефактов;
— Если нет супердизайнера или плотной связки дизайнера с аналитиком, решающих всё в реальном времени, создать консистентную проектную документацию поможет «перекрёстное опыление»;
— Это синхронизация дизайна и аналитики при создании каждого функционального слоя: 1) концепция, 2) функциональная модель, 3) сценарии, 4) информационная архитектура, 5) сведение функций с экранами и состояниями;
— Например, на этапе концепции дизайнеры прорабатывают базовую ролевую модель, потребности и особенности пользователей. Аналитики вместе с технарями и бизнесом решают, как закрыть интересы всех заинтересованных сторон.

#functional_architecture #process

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

— С этим помогут локальные переменные (Variables) и условия (экшен Conditional);
— Если их не использовать и просто переводить пользователя с одного экрана на другой, для формы из 4 полей потребуется 16 экранов (включая полностью заполненную форму и полностью незаполненную);
— Поля, с которыми будет взаимодействовать пользователь, надо заменить на локальные компоненты с вариантами «Не заполнено» и «Заполнено»;
— Когда пользователь заполняет поле, это надо сохранять в локальную переменную;
— При отображении формы надо проверять переменные и переключать компоненты заполненных полей на нужный вариант: триггер After delay, повешенный на компоненты конкретных полей, плюс экшен Conditional.

#figma #prototype #form

Даниэль Виленчук написал о категоризации фидбека.

— Вы начали собирать обратную связь от пользователей и получили таблицу с 3000 отзывами. Как с ними работать?
— Удалите отзывы без текста. Они могут занимать до половины таблицы;
— Практика показывает, что из отзывов короче 10–15 символов почти невозможно извлечь инсайт. Можно отфильтровать таблицу, бегло просмотреть отзывы короче 5 символов и удалить бесполезные. Повторить для 10, 15 и 20 символов. Так очищается не меньше трети документа;
— Отсортируйте отзывы от А до Я. Самые первые, скорее всего, будут мусорными: состоять из цифр и случайных символов;
— Далее по ключевым словам определите родительские категории, например, сценарии («Оплата и промокоды», «Авторизация») или типы пользователей («Покупатели», «Продавцы»);
— По типу возникающих проблем определите дочерние категории: «Оплата и промокоды / Просроченный промокод»;
— В первый раз придётся самостоятельно идти по отзывам, придумывать категории и расставлять их вручную. Так вы познакомитесь с языком ваших пользователей и сформируете набор ключевых слов, по которым отзыв можно отнести к той или иной категории;
— Проставленные категории дадут статистику, какие проблемы вызывают больше обращений пользователей, и позволят работать с фидбеком точечно, передавать конкретным командам;
— Категории и ключевые слова сохраните для категоризации будущих отзывов.

#feedback

Алексей Тюрин написал, как обезопасить ввод пинкода на телевизоре, когда экран видят другие люди.

— Пинкод закрывает детям и сожителям доступ к настройкам телевизора, подпискам и покупкам, платёжным данным. Особенно актуально, если телевизор находится в публичном месте;
— Также им можно ограничить детей от взрослого контента;
— Люди могут использовать тот же пинкод, например, в банковском приложении, что повышает ставки, если кто-то подсмотрит его во время ввода на телевизоре;
— Раньше не было проблемы ввести код, не выбирая цифры на экране, так как цифры были на пультах;
— Проблему легко решили на приставках (PlayStation, Steam): на контроллере много кнопок, которые можно нажимать вместо цифр;
— В Android TV, Sony Bravia, Samsung Tizen есть безопасный ввод: стрелками ↑ и ↓ на пульте пользователь выбирает на экране группу цифр (1-2-3, 4-5-6, 7-8-9), а кнопками ←, OK, → незаметно для стороннего наблюдателя выбирает левую, правую или центральную цифру в группе;
— Коды иногда используют для отключения родительского контроля. Если ребёнок дошкольного возраста, вместо пинкода для разблокировки взрослого контента можно просто просить ввести решение несложного математического выражения (3×8=?) или цифры, написанные на экране словами (Zero, One, Zero, Two);
— Стоит ожидать появления разблокировки отпечатком пальца или лицом через встроенные в пульт сенсоры.

#tv #log_in

Таня Мисютина поделилась советами, как упорядочить визуализацию.

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

#data_visualization #dashboard

Егор Камелев написал о проектировании форм.

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

#form

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

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

#search #mobile

Катя Тюхай рассказала о конфликтах в продуктовой команде.

— Самый распространённый — борьба за ресурс, когда дизайнеров или исследователей мало, а продуктовых команд и задач много. Можно перевести их в формат студии, без привязки к продуктовым командам, или чётко разделить, сколько времени можно тратить на задачи конкретной команды;
— Если дизайнеров достаточно, надо легализовать теневые работы вроде дизайн-ревью, которые часто не учитывают при планировании;
— Руководитель не должен выносить конфликты на уровень команды;
— Конфликты могут возникать из-за культурной разницы. Минимизировать их помогает неформальное общение с коллегами (например, в формате Random Coffee), один день поработать рядом с человеком на его рабочем месте, сессии совместной работы;
— Когда сотрудник хочет, но ещё не готов стать лидом, предложите взять какой-нибудь спецпроект, стать лидером компетенции, составить чеклисты или методички, менторить стажёра;
— У команд противоположные KPI (продавцы хотят быстрее совершать сделки, риск-менеджеры — тщательнее их проверять). Надо встретиться, обменяться цифрами и целями на полгода-год и найти точки соприкосновения. Они есть всегда;
— Нет ресурсов на достижение KPI. Ищите команды со схожими целями и KPI. Например, если занимаетесь дизайн-системой, вовлекайте тех, кто получит от её внедрения максимальный буст;
— Непрозрачные процессы. Создавайте чеклисты, шаблоны задач, автоматизируйте прохождение задачи в Jira, внедряйте синки, например, большие горизонтальные демо раз в одну-две недели.

#management

Юля Кондратьева поделилась исследованиями тёмных паттернов из научных статей (компании таким делятся редко).

— 95% исследованных приложений и 97% популярных сайтов содержали тёмные паттерны. Правда, к ним относят и довольно вегетарианские приёмы вроде проставленной по умолчанию галочки;
— Если рядом расположить одинаковые кнопки «Подписаться» и «Отказаться», конверсия будет 16,7%. Если «Подписаться» сделать акцентной — 18,1%. Если под «Подписаться» написать «Рекомендовано» — 20,1%. Если «Отказаться» заменить на ссылку «Другие опции» — 23,6%;
— Если информацию о стоимости после истечения бесплатного месяца написать мелким серым цветом в сноске, конверсия становится 30,1% (без этого — 14,8%). Если добавить социальные доказательства — 22,1%. Если использовать манипулятивную формулировку на кнопке отказа — 19,6%. Если ограничивать время и создавать ажиотаж — 14,3%;
— Тёмные паттерны сильнее влияли на респондентов с худшим образованием;
— Удлинение флоу отказа повысило конверсию с 11,7% до 25,8% (+2 шага) и 41,9% (+6 шагов, похожий был в Яндекс Плюсе). При этом оценка готовности повторить опыт снизилась всего с 4,46 баллов до 4,11 и 3,97 из 7;
— Пользователи посчитали интернет-магазин с целым набором тёмных паттернов более надоедливым по сравнению с магазином без них: 3,44 балла против 2,34 из 5. А также хуже соблюдающим свои обещания (3,26 против 3,55, −5,8%) и менее вызывающим доверия (3,07 против 3,42, −7,5%);
— В одном исследовании дизайнеры опознали меньше половины тёмных паттернов. Не разбираясь, можно неосознанно использовать их в своей работе;
— Многие научные работы посвящены автоматическому отслеживанию тёмных паттернов. Возможно, когда-нибудь браузеры станут предупреждать о них при посещении сайтов или поисковые системы учитывать их наличие при ранжировании сайтов.

#dark_patterns #conversion

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

— Правило хорошего UX — дать пользователю возможность вернуться в предыдущий режим, к изначальному состоянию;
— Пользователь нажимает на кнопку отправки формы, все пустые поля переходят в состояние Error, в нормальное состояние они возвращаются по очереди по мере заполнения. По сути форма переходит в режим отладки;
— Нажатие на кнопку приводит к изменению состояния полей, но объект взаимодействия — кнопка, с ней связан локус внимания пользователя. Но не она говорит с пользователем, а поля (которые вместо полей ввода стали полями вывода);
— Если автоматически фокусироваться на первом пустом поле, на мобильных это приведёт к отображению клавиатуры и затруднит изучение формы в целом. Можно прокручивать страницу к этому полю, но тогда пользователю придётся нажимать на поле, чтобы его заполнить;
— Стоит разделять ошибки данных (не хватает @ в адресе электронной почты) и ошибки процесса (пришёл ответ сервера о несуществующем адресе);
— Пустое поле — не ошибка данных, а приглашение к взаимодействию;
— Принцип «один экран — одно действие» сокращает количество вариантов для выбора и повышает его скорость;
— Если на экране одновременно одно поле, поднимающаяся при фокусе клавиатура не мешает. Если оставить его пустым, нажатие на «Продолжить» вернёт фокус в поле и отобразит клавиатуру, приглашая к взаимодействию без сообщения об ошибке;
— Если на экране полей много, можно реализовать их последовательное заполнение, переходя между полями кнопкой Next на экранной клавиатуре и прокручивая страницу так, чтобы заполняемое поле было ровно над клавиатурой;
— При попытке отправить форму можно вернуть пользователя к первому неправильно заполненному полю (с сообщением об ошибке), не помечая все остальные.

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

Елена Сеченых написала о тёмной теме в письмах.

— Нет единых правил инвертирования в разных почтовых сервисах и даже разных приложениях одного и того же сервиса;
— 4 варианта поведения: ничего не делать (большинство десктопных клиентов, веб-версии Gmail и Яндекс Почты); инвертировать светлые письма и не трогать тёмные; инвертировать и туда и обратно (Gmail на iOS); позволять управлять отображением с помощью медиазапросов (Apple Mail на macOS и iOS, Mail Ru на мобильных и в веб-интерфейсе);
— Подбирайте палитру, чтобы автоматически выбираемые почтовиками инверсные версии цветов оставались контрастными. Лучше не использовать жёлтый — по факту остаётся светлым и становится чуть более грязным;
— Изображения автоматически не инвертируются. Можно использовать картинки с прозрачным фоном. В этом случае может понадобиться светлая обводка, которой не будет видно в светлой теме, но которая выделит графику в тёмной (например, чёрный логотип, если брендбук не запрещает);
— Не забудьте про фоновые изображения. Они не инвертируются и находящийся поверх них текст может потерять контраст;
— Если почтовик умеет обрабатывать медиазапросы, можно просто подготовить отдельное изображение;
— Обязательно проверьте отображение письма в андроид-приложениях Яндекса, Mail Ru, Gmail, а также в Gmail на iOS;
— Есть сервисы для тестирования писем: Email on Acid, Litmus, но они не работают с Яндексом. Фреймворк для вёрстки Ampier показывает и классическую инверсию, и вариацию Gmail на iOS.

#email #dark_theme

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

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

#mobile