дизайн мобильного приложения это
Дизайн приложений
В создании мобильного софта главную роль исполняет дизайн приложения. Он фундамент приложения. И он же первый, кто цепляет внимание пользователя. Чтобы удержать внимание пользователя нужно продумать: внешний дизайн, структуру, удобство пользовательского интерфейса (конкретно UX и UI) и другие детали. Теперь подробнее.
Дизайн мобильных приложений
Разработка дизайна для приложения — это трудоемкий процесс, который, по исполнению, может оказаться сложнее, чем подготовка макета для сайта.
В среднем, дизайн мобильного приложения занимает от недели до 1 месяца. Если в приложении подразумевается множество уникальных экранов, то разработка может длиться более 1-го месяца.
Этапы дизайна приложения
Процесс создания мобильного приложения разделяется на этапы. Это помогает помнить о каждом шаге в разработке софта.
Этап тестирования приложения необходимо проводить еще и на этапе прототипа. Важно знать, что весь требуемый функционал реализуем и правильно работает. Посмотрите, каждая деталь приложения действует так, как задумывалось? Пользователю понятно, что делает та или иная кнопка? Если сомневаетесь, нужно переработать макет.
Принципы дизайна в разработке приложений
Помните выражение «черт в деталях»? Так вот, это про дизайн. Приятно, когда в дизайне мобильного приложения продуманы все мелочи: как выглядит экран, если контент не загрузился или загрузилась часть. Что будет на странице, если отключился интернет и другие не маловажные детали. Рассмотрим все детали по порядку.
Первое впечатление и обучение пользователя
Onboarding (произносится «онбординг») — это механизм искусственного создания первых впечатлений о приложении у пользователя.
Знакомство пользователя с приложение нужно начинать с onboarding. Онбординг формирует восприятие пользователя к продукту от первого контакта (открытие первого экрана) до момента оплаты (целевое действие). Функция обеспечивает легкий и комфортный старт за счет нескольких механик.
Мы используем onboarding как первый экран с короткой инструкцией / презентацией, где написано, как пользоваться сервисом (обучение). Предоставляет максимум информации по управлению приложением в сжатом объеме.
Применяется в зависимости от целей и результатов, которые нужно достигнуть. Например, стимулировать людей к совершению заказа, к приобретению премиум аккаунта или привязке банковской карты.
Реализация онбординга нужна для конкретной задачи. Не применяйте просто красивые картинки. Создайте эту мини-презентацию исходя из поставленных целей и задач. Другими словами, научите пользователя делать то, для чего создано ваше приложение.
Детали в дизайне приложения
Сделайте акцент на важных кнопках. Например, кнопку «заказать» нужно сделать больше и заметнее, чем кнопку «подробнее», которую можно оставить просто ссылкой.
Задавайте шрифт правильно. Некоторые компании применяют для каждого мобильного приложения разные шрифты. Для пользователя это не всегда удобно. К примеру, в его смартфоне может не оказаться задуманного вами шрифта. Как приложение будет работать в этом случае? Идеально использовать функцию «использовать дефолтный шрифт» (по умолчанию).
Количество действий / переходов в приложении
Оцените, есть ли в приложении лишние действия? Если есть, от них лучше отказаться. Дизайнеры нашей компании, при разработке сайта, приложения или программы, всегда проверяют продукт на наличие лишних действий. Проще говоря, если пользователя можно привести к оформлению заказа в 3-и действия вместо 7-ми, то лучше так и сделать.
Разница между UX и UI дизайном приложений
Фундаментом разработки приложения, программы или сайта, всегда является UX и UI дизайн. Эти две составляющие влияют на весь рабочий процесс в целом.
UX-дизайн (User eXperience, в переводе с англ. «пользовательский опыт») — это привлекательность и эффективность привлечения пользователей к выполнению целевого действия через графические элементы. Суда входит разработка: цветовой гаммы, шрифтов изображений и паттернов.
Если с удобством и логикой построения экранов все в порядке, то можно переходить к разработке визуальной части мобильного приложения. То есть, к UI-дизайну.
UI-дизайн (User Interface, в переводе с англ. «пользовательский интерфейс») — это удобство, интуитивно понятный дизайн для использования. Оценивается по опыту взаимодействия пользователя с дизайном на этапе тестирования.
Как видим из определений, разница между UX и UI есть. На практике, цель у UX и UI общая: сделать приложение удобным, привлекательным и интерактивным. UX и UI связаны между собой и отдельно не действуют.
На заметку: По нашему опыту, 90% пользователей прекращают использовать приложение еще на этапе знакомства, если один из пунктов (UX и UI) не доработан.
Структура экранов мобильного приложения
Чтобы создать работающее мобильное приложение, дизайнеру нужно изучить его особенности, разобраться в построении структуры и переключении экранов, функциональности. Сейчас индустрия мобильных приложений настолько захватила наш мир, что описать стандартный набор экранов стало сложной задачей. И все же, мы попробуем перечислить основной набор экранов.
Главные экраны и меню
В мобильное приложении главный и меню являются основными экранами. Главный экран проектируется с учетом задумки продукта, его назначения и цели. Он же отправная точка для пользователя. Поэтому, главный экран содержит элементы навигации, по которым можно перейти к разным разделам мобильного приложения.
В 50% мобильных приложений дизайнеры помещают меню на главный экран. При этом, меню может быть 2-х видов: выпадающее меню или его отдельный экран. Из практики нашей компании, при создании мобильного приложения следует ограничить количество действий во взаимодействии пользователя с меню.
В идеале, количество кнопок в меню должно быть не более 7-ми, а остальную информацию сделать в подкатегориях.
Экран входа и профиль
На заметку: чтобы приложение завоевало сердца вашей целевой аудитории, нужно изучить площадки конкурентов и тренды в дизайне мобильного приложения в конкретной сфере.
Экран электронной коммерции, каталог
Основная цель создания коммерческого проекта — это продажа продуктов, товаров или услуг. Визуальная презентация товара имеет сильное воздействие на принятие решения пользователем. Задача дизайнера — создать каталог компании в мобильном приложении таким образом, чтобы он был максимально удобным и привлекательным для клиента.
Отсюда слегка выбивается количество карточек товара (продуктов), которое помещается на один экран. Потому что их количество зависит от ширины экрана пользователя. Как показать товар — это уже задача маркетинга.
Контрольный экран
Процесс оформления заказа — это последний шаг в совершении целевого действия пользователем. Дизайнер отлично поработал над мобильным приложением и клиент смог дойти до покупки. Теперь важно не отпугнуть его.
Основная часть экрана — это форма оформления покупки, где клиент вводит личные данные для покупки и ее оплаты. Количество требуемой информации зависит от типа интернет-магазина или сервиса. На этом этапе нужно показать, что данные, вводимые пользователем, останутся в безопасности и не будут переданы мошенникам. Для этого нужно оставить убеждающие фразы.
Сама же задача «защита персональных данных» выполняется программистом. Дизайнер готовит макет, как контрольный экран будет выглядеть.
Социальный экран
Лента активности, новостей, событий — это все социальные экраны. Feed (производится «фид»), должен иметь четкую схему сканирования и отображения событий в ленте, которая не будет перегружена лишними деталями.
Контакты
Говоря об интернет-магазине, само собой разумеется, что в мобильном приложении будет страница «Контакты». Дизайн этой страницы формировался в течении долгих лет, пока не пришел к имеющемуся виду. Экран должен быть представлен в виде отсортированного списка (номер телефона, почта, контакты для месенджерров и т. д.).
На заметку: Для упрощения поиска нужного контакта можно установить маленькую иконку рядом с контактом.
На этом мы заканчиваем повествование о дизайне мобильного приложения. Следите за обновлениями нашего блога, чтобы узнать больше информации по теме. Новая статья выходит 1 раз в неделю. Подписка внизу.
Дизайн мобильных приложений: полный гайд по UX/UI
Дизайн мобильных приложений — это по сути создание мобильной версии сайта с дополнительными возможностями. При этом главная задача разработчиков заключается в создании удобной экосистемы с совершенным UX.
Скачивая какое-либо приложение, юзер по умолчанию лоялен: он уже совершил целевое действие, и если он сможет решить свою проблему с помощью вашего сервиса — то будет пользоваться им на регулярной основе. Однако если хотя бы один раздел на пути клиента не работает или неудобен — человек просто удалит ваше приложение – и не вернется к нему никогда.
В этом заключается принципиальное отличие UX-дизайна сайтов и приложений: как правило, пользователь оценивает удобство нескольких веб-продуктов, и даже если при первом визите человек не совершил целевое действие, всегда есть вероятность, что спустя некоторое время он вернется на ваш сайт. При этом повторное скачивание приложений — это скорее исключение, чем распространенная практика.
Перед тем, как переходить к прототипу, дизайнер должен провести анализ конкурентов, целевой аудитории и задач, которые стоят перед приложением. Например, если ЦА — женщины, то кнопки и другие элементы взаимодействия можно делать меньше, если мужчины — крупнее. Большинство пользователей нажимают на экран большим пальцем, так что такая незначительная деталь поможет мужской аудитории комфортнее взаимодействовать с сервисом.
На этапе UX-разработки дизайнер должен продумать весь путь пользователя от начальных экранов знакомства — и до выполнения целевых действий, которых в приложении может быть несколько. Как правило, User Journey представляет собой ветвистое древо возможностей с разным функционалом: подпиской на приложение, обращением в службу поддержки, чтением текста, оплатой товара и так далее. И каждая “ветвь” должна быть хорошо продумана уже на этапе прототипа.
В проектировании интерфейса есть несколько важных деталей, о которых дизайнер и заказчик должны знать:
После того, как вы спроектировали интерфейс, можно переходить к визуальной составляющей и “вычищать” приложение. Основная задача на данном этапе заключается в том, чтобы привести дизайн к единому Style Guide.
На все приложение желательно использовать не более 5 – 6 типов одного шрифта (разного размера, цветов и толщины) и 4 – 5 цветов. Этого достаточно для расставления акцентов и создания аккуратного интерфейса. Также стоит продумать анимацию перехода с одного экрана на другой: исчезновение, смещение, прелоадер и др. При подборе цветов также стоит учитывать, что цветовая палитра Iphone, как правило, лучше, чем палитра Android-устройств, а значит нужно отказаться от грязных и смежных цветов.
На финальном этапе происходит разработка адаптивных версий. Если приложение будет доступно только для iOS – вам повезло, ведь на этапе создания адаптивов вам достаточно отрисовать только две версии: для Iphone 6 и Iphone X. Однако если ваша задача – это сервис для Android, то придется отобрать 4 – 5 наиболее популярных разрешений в конкретном сегменте целевой аудитории.
Важным этапом UX-дизайна является тестирование юзабилити готового интерфейса. Оно включает в себя оценку прототипа по ряду параметров:
Самым простым вариантом проведения тестовых сессий будет создание кликабельных прототипов в Figma и запись процесса пользования сервисом с получением последующей обратной связи. Однако есть и более продвинутые сервисы, которые в режиме реального времени транслируют процесс взаимодействия пользователя с приложением, например, Userlytics, TryMyUI и UserTesting.
После этого миссия дизайнера в создании мобильных приложений считается выполненной.
Материал подготовлен арт-директором веб-студии IGNI Дмитрием Мурашкиным.
Дизайн мобильных приложений — это по сути создание мобильной версии сайта с дополнительными возможностями.
Лол, правда?
Тогда это объясняет многие проблемы с дизайном у приложений.
шрифты не должны быть необоснованно маленькими
У вас как раз такие. По крайней мере меньше, чем это принято по стандартам iOS.
Кривой UX не учитывающий особенности платформы. Даже в вашем примере, этот гамбургер в правом углу противоречит привычным паттернам взаимодействия с iOS, да и вообще эргономике. Попробуйте воспользоваться этим меню держа телефон в одной руке. И такого много, от основной навигации, до анимации переходов между состояниями. Пренебрежение правилами типографики, игнорирование accessibility standards. Хотя бы это
Ну вот вам скрин приложения VC с закладкой и «поделиться» в верхнем правом углу. Это вполне удобно. И где по-вашему должно быть меню?
Вы сами можете видеть где находится меню на вашем скриншоте (внизу, где и другие часто используемые функции) ред.
Большинство людей правши и используют большой палец для навигации на смартфонах. Не вижу преград располагать бургер в правом верхнем углу. Почему это кривой UX?)
Интересно взглянуть на ваше портфолио))
используют большой палец для навигации на смартфонах.
Вот именно. И в верхний правый угол каждый раз тянуться неудобно (особенно на современных смартфонах с большим экраном). Даже в Андройде перенесли основную навигацию в нижний таб бар.
Интересно взглянуть на ваше портфолио))
А что множество исследований и гайдлайны iOS и Android без моего портфолио уже неубедительны? ред.
Комментарий удален по просьбе пользователя
Вообще сама концепция бургера уже давно себя изжила. Т.к. вы трудитесь в данной сфере, то уверен, что исследования по этому поводу вы читали, посему пруфы искать не буду.
Правый и верхний угол моб устройства попадают в красную зону на устройствах с диагональю выше 5 дюймов (может и больше, точно не помню). Поэтому размещение в углах какого-либо функционала само по себе неоправданно с точки зрения юзабилити.
Такое предоставление информации это полный пи**ец и надругательство над здравым смыслом. Как это расшифровывать? Что означает частично заполненная пробирка фигмы и что означает чуть менее заполненная пробирка скетч? Насколько между ними разница? Как ее понять и посчитать? Как формируется эта пробирка и как считается каждая риска которой эта пробирка заполняется? Если баллами, цифрами или оценками, то может уйти от этой дебильной непонятной графики и написать оценку или баллы?
Есть человеческие понятные значения «хорошо», «плохо», «отлично» и подобные слова. Можно балльную систему, например результат 70 из 100, где будет понятно из чего сложился каждый балл и где можно его улучшить. К какому х*ю эти тупые безликие пробирки где все цветными полосочками заполняется я не понимаю.
Как эту картинку адекватно прочесть? Какие из нее выводы можно сделать? Что типа я вот на именно эту пустоту незаполненную недотягиваю до какой то оценки или что?
Есть дизайн, а есть здравый смысл. Таких дизайнеров как вы надо сначала учить работать с информаций, базами данных и выводом/предоставлением инфы. А это все дизайны месячных выпускников курсов по дизайну для беханса слепленные на коленке. Красиво нарисовано и никакого смысла. Сидят учат как UX делать и не знают про зоны безопасности в iOS. Пи**ец.
32 отличия дизайна мобильного приложения под iOS и Android
Железный дизайнер из Redmadrobot Design Lab Артур Абраров делится наблюдениями.
Адаптировать дизайн под другую платформу — неотъемлемая часть работы дизайнера мобильных приложений. Цель этой работы — органично вписать дизайн в паттерны взаимодействия пользователя. К тому же, проработанная адаптация упрощает разработку за счёт использования нативных компонентов платформы.
Чтобы адаптировать дизайн правильно, нужно соблюдать гайдлайны платформ: Human Interface Guidelines (HIG) у iOS и Material Design у Android. И общаться с разработчиками, в идеале подключать их к дизайну как можно раньше, чтобы они могли сразу задать технические ограничения.
Но в чём именно отличается дизайн под iOS от дизайна под Android? В этой статье я разберу 32 конкретных отличия дизайна под iOS и Android. Они поделены на четыре группы:
Базовые отличия
Human Interface Guidelines vs Material Design
Почти все отличия этой статьи взяты из анализа этих гайдлайнов. Их суть на идейном уровне следующая. HIG — это про плоский, лёгкий, дружелюбный дизайн, пришёл он из постепенного отказа от скевоморфизма.
Material же имеет несколько основополагающих принципов: материал как метафора; смелый, графический, сознательный; осмысленная анимация; гибкая основа и кроссплатформенность. Если вы не знакомы с гайдлайнами, лучше их прочесть до того, как ознакомитесь со статьёй.
2. Единицы измерения: pt vs dp
Дизайн iOS-приложения создаётся в pt, а Android-приложения — в dp. Мы, как правило, создаём дизайн в 1x (или mdpi) и выгружаем в Zeplin. Zeplin отображает для iOS дизайн в pt и генерирует иконки и иллюстрации в 2х и 3х. Под Android отображает дизайн в dp и генерирует графику в hdpi, xhpdi, xxhdpi и xxxhdpi.
3. Размер экрана: 320 pt x 568 pt vs 360 dp x 640 dp
Предпочитаю проектировать iOS-приложение под наименьший размер — iPhone 5 с размером экрана 320pt х 568pt. Делаю это, чтобы избежать некорректного отображения контента на маленьких экранах. Некоторые предпочитают проектировать под iPhone 8.
Под Android есть общепринятый размер экрана — 360dp х 640dp.
При дизайне под iOS иногда создаю дизайн и под iPhone X (375pt х 812 pt). Это нужно, чтобы разработчик понимал, как правильно расставить отступы у экрана этого размера. Ещё при дизайне под iPhone X нужно помнить про Safe area — зону, вне которой не стоит размещать контент.
4. Системный шрифт: San Francisco vs Roboto
5. Android Navigation Bar
В отличие от iOS, у Android есть встроенный инструмент навигации назад. Это Android Navigation Bar.
Он либо физически встроен в смартфон, либо является частью интерфейса. С помощью стрелки пользователь перемещается на один шаг назад в хронологической последовательности (reverse chronological navigation). Навигация происходит как внутри приложения, так и между ними.
В начале профессионального пути в качестве дизайнера мобильных приложений я долго мучил Android-разработчиков вопросом: зачем нужны две кнопки назад? Одна есть внизу в Navigation Bar, вторая появляется в Top App Bar при переходе на дочернюю страницу.
Ответ такой. Есть два вида навигации назад: reverse chronological navigation (её осуществляем с помощью стрелки назад в Navigation Bar, зовем её Back).
И upward navigation (её осуществляем с помощью верхней стрелки, зовем её Up).
Представим, что у нас есть путь A-B-C, где A — это материнская страница, а B и С — дочерние. Представим, что пользователь попал напрямую из A в С. Если он нажмёт на кнопку Back, то вернётся на A. Но если нажмёт Up, то сначала попадёт на B — и уже по второму нажатию попадёт на A.
Это сложно реализовать и путанно для пользователя, поэтому сейчас эти две кнопки назад осуществляют одинаковое действие back, как в iOS. То есть если пришли из A в С, то из С вернёмся обратно в А.
6. Важность Elevation в Material
В iOS принципиально нет теней. Как исключение, тени можно обнаружить на главном экране App Store и в Health. Но в целом HIG никак не прописывает использование теней.
В Material тени играют большую роль. Они добавляют интерфейсу третье пространство (ось Z), за счёт чего у каждого компонента появляется своё строгое место на этой оси (от 0 dp до 24 dp). Причём эта ось Z существует не просто на идейном уровне: у разработчиков есть параметр elevation, в котором они задают положение компонента по этой оси.
Навигация и смена состояний сопровождается изменением elevation компонентов. Поэтому при дизайне под Android нам стоит осознанно подходить к созданию теней.
7. Отличия в нейминге
Отличий в нейминге много. Предлагаю рассмотреть эти пять.
a. Tab Bar vs Bottom Navigation Bar
| |
b. Navigation Bar vs Top App Bar
Этот bar у обеих платформ выполняет примерно одинаковые задачи: сообщает пользователю его текущее местоположение в приложении, даёт возможность вернуться на предыдущий экран и предлагает одно или несколько контекстных действий. Подробнее об отличиях — ниже в статье.
c. Segmented Controls vs Tabs
| |
d. Alerts vs Dialogs
Интересно, что в iOS описан только один инструмент предупреждения пользователя — Alerts. В Android их три: Snackbars, Banners и Dialogs.
Snackbar предназначен для сообщений низкой приоритетности и не требует действий. Dialogs блокирует взаимодействие с интерфейсом и требует совершить действие. Banners находятся между ними: не блокирует взаимодействие, но требует совершить действие.
| |
e. Touch ID vs Android Fingerprint
 | |
Отличия в навигации и паттернах (UX)
8. Способы верхнеуровневой навигации
Начнём с самого верха. iOS рекомендует только один способ верхнеуровневой навигации — через Tab bar. У Android в ответ есть три способа: Navigation Drawer, Bottom Navigation Bar и Tabs.
Если количество верхнеуровневых страниц больше пяти, используем Navigation Drawer. Если меньше — Bottom Navigation Bar. Tabs нечасто применяют для этой навигации, но способ нам доступен. Однако Material рекомендует не совмещать Tabs и Bottom Navigation Bar, так как взаимодействие с данными компонентами влияет на контент страницы и пользователь может запутаться.
9. Отличия в поведении Tab Bar и Bottom Navigation Bar
Это отличие предлагает Material.
Если вы в iOS перейдёте от материнской страницы к дочерней, потом через Tab Bar переключитесь на другую материнскую страницу, то по возвращении на первую материнскую страницу вы всё также будете находиться на дочерней.
В Android всё строже — при переключении через Bottom Navigation Bar вы всегда переключаетесь между материнскими страницами. Если до этого вы были на дочерней, она сбросится.
Наши разработчики Android уверены, что такое поведение системы неверное. В случае переключения по Bottom Navigation стоит сохранять открытые дочерние страницы, как на iOS.
10. Особое поведение Tabs у Android
| |
Это потому, что страницы табов находятся на одной высоте (elevation).
Это важно знать потому, что при использовании табов в Android нам не стоит добавлять в дизайн элементы с похожими жестами. Например, карусель картинок или взаимодействие с карточками с помощью свайпов.
| |
В целом эти два компонента не заменяют друг друга полностью. Segmented control — это control, который управляет контентом страницы. А Tabs — инструмент навигации.
Поэтому стоит советоваться с разработчиками перед тем, как при адаптации рассматривать их как равноценные компоненты. Иногда корректнее заменять андроидовские Tabs на Page Control. Всё зависит от контекста.
11. Отличия в появлении дочернего экрана
В iOS появление дочернего экрана (не считая модалок) происходит только одним образом: дочерняя страница появляется справа поверх материнской с эффектом slide in. Возвращение на материнский экран происходит с эффектом slide out.
Material рекомендует показывать пользователю иерархическую взаимосвязь материнской и дочерней страницы с помощью осмысленной анимации.
Компонент, при взаимодействии с которым пользователь переходит к дочерней странице, раскрывается и покрывает собой материнскую страницу. Так пользователь понимает, откуда и куда он перешёл, почему это произошло и куда он вернётся при нажатии на кнопку «Назад».
Переход происходит с помощью Standard Easing.
| |
12. Особый паттерн вызова Navigation Drawer
При проектировании приложения с Navigation Drawer важно помнить, что этот компонент «забирает» себе жест edge swipe слева вправо. Поэтому не стоит добавлять этому жесту другую логику.
В iOS у этого жеста есть устоявшийся паттерн перехода с дочерней на материнскую страницу. Этот паттерн постепенно перекочевал и во многие андроидовские приложения.
13. Поведение контента при скролле
По HIG контент в iOS при скролле ведёт себя так: Navigation Bar уменьшается в ширине, исчезает Tool Bar. Но в целом iOS-разработчики могут настроить любое поведение контента и баров при скролле.
Material предлагает больше вариантов поведения при скролле. Например, Bottom Navigation Bar, Search и Bottom App Bar при скролле могут исчезать.
| |
Top App Bar может либо исчезать, либо подниматься выше основного контента.
Разное поведение поиска
Интересно, что HIG относит поиск к барам и называет его Search Bar. В Material мы находим поиск в разделе Navigation, не в Components. То есть для Material поиск — это ещё один способ навигации.
Как в iOS, так и в Android поиск может статично присутствовать на экране и, как правило, прибит к Navigation Bar или Top App Bar.
| |
На обеих платформах поиск может быть в виде иконки, только в iOS иконка раскрывается в самостоятельный компонент Search Bar, а в Android поиск раскрывается внутри Top App Bar.
| |
Особенность поиска в iOS — его можно «спрятать» под Navigation Bar и вызывать по жесту Swipe down. Такой же жест типичен и для рефреша (pull to refresh), поэтому не стоит вызывать поиск и рефреш по этому одному действию.
Отличия в компонентах (UI)
15. Каких компонентов нет в iOS
В iOS нет многих нативных компонентов Android. Пробежимся по ним.
a. Navigation Drawer
iOS в принципе не признаёт бургер-меню. Как говорили раньше, в iOS верхнеуровневая навигация только по Tab Bar.
b. Backdrop
Backdrop — самый удивительный для меня компонент в Material. На момент написания статьи Android ещё только планирует реализовать его как нативный. В целом при изучении компонентов Material стоит проверять, доступны ли они уже для использования.
Сам Material любит этот компонент. Посмотрите, например, на победителей Material Design Award 2019.
c. Banner
Banner не найти среди нативных компонентов iOS. С помощью Banner мы сообщаем пользователю важную информацию и предлагаем связанные с ней действия.
d. Snackbar
Как и Banner, Snackbar — не нативный для iOS. Snackbar применяют, чтобы донести до пользователя короткое сообщение о результате его действия.
e. Chips
Chips также отсутствует среди нативных компонентов iOS. Они используются для ввода информации, описания и действия.
f. Bottom App Bar
Тут можно поспорить, что у iOS есть похожий компонент — Tool Bar. Но они разные, вот почему: Toolbar — это бар для контекстных действий. Например, при редактировании списка сообщений в Messages появляется Tool Bar с действиями Read All и Delete.
Bottom App Bar — это перемещение Top App Bar вниз с теми же действиями верхнего уровня: открытие Navigation Drawer, вызов поиска и так далее. Ещё в Bottom App Bar мы размещаем FAB.
g. FAB
Да, FAB тоже нет в iOS. FAB — это кнопка для совершения основного действия на экране. Например, в почтовом приложении FAB будет создавать новое письмо.
Если вы используете в Android FAB для основного действия на экране, то в iOS это основное действие стоит разместить наверху в Navigation Bar справа (смотри пример: iMessages).
h. Bottom Navigation Drawer
Разновидность Navigation Drawer, типичная только для Android. Вызывается нажатием кнопки бургер-меню в Bottom App Bar.
i. Side Sheet
Хоть Material и разрешает использовать этот компонент в мобильном приложении, я бы рекомендовал заменить его на более привычный Bottom Sheet.
j. Expanding Bottom Sheet
Этот очень красивый компонент Android не найти среди нативных для iOS. Expanding Bottom Sheet — это поверхность, которая прибита к низу страницы. При нажатии поверхность расширяется до полноценной страницы.
k. Standard Bottom Sheet
Standard Bottom Sheet — разновидность Bottom Sheet, и его нет среди компонентов iOS.
16. Каких компонентов нет в Android
Теперь рассмотрим, каких компонентов не найти в библиотеке Android.
a. Page Controls
Page Control показывает, на какой из страниц находится пользователь. Его нет среди нативных компонентов Android.
b. Toolbar
Toolbar привычен только для iOS.
c. Steppers
Steppers — стандартный control iOS, не описан в Material. Используем его для ввода небольших значений. Пример: количество копий при печати.
d. Popover
Popover — всплывающая панель, которая в основном используется на iPad.
В iOS есть одно стандартное применение Popover — настройка текста в ридерах или браузерах.
17. Разные Status Bar
| |
Ещё у Status Bar Android есть такая особенность, когда приходит уведомление из приложения, в Status Bar появляется иконка этого приложения. В iOS такого нет.
18. Refresh Content Controls vs Swipe to refresh
Рефрешеры вызываются одним и тем же жестом swipe down на обеих платформах. Но в iOS Refresh Content Control «толкает» остальной контент вниз, в то время как Swipe to refresh у Android появляется поверх контента. Кроме того, рефреш iOS при скроле контента исчезает, а у Android остаётся видимым.
19. Разные Control
| |
Ещё Material предлагает использовать родительский чекбокс, когда нужно дать пользователю возможность быстро выбрать все варианты.
20. Разный вид стрелки «Назад» и положение заголовка
| |
21. Разный вид иконки трёх точек
| |
22. Разный вид Picker
В iOS выбор даты происходит с помощью барабана. Барабан iOS можно использовать для ввода любых других данных. В Android Picker даты имитирует вид физического календаря.
Material также рекомендует давать пользователям возможность вводить дату с помощью Input Field-а.
23. Разные Text Fields
HIG куда менее требователен к Text Fields, по сравнению с Material.
Отличия
В iOS Label находится внутри поля ввода и исчезает во время ввода текста. Material рекомендует поднимать Label при вводе текста.
Схожее
Обе платформы советуют при необходимости добавлять Clear Button.
Что ещё просит Material
Material также рекомендует выделять Label и полосу под Text Field основным цветом — это помогает понять, что поле выделено. Material описывает поведение поля при ошибке ввода. В Material на выбор есть две формы: Filled и Outlined.
24. Context Menus vs Menus
Context Menus появился в iOS 13. Этот контрол предлагает пользователю нескольких контекстных действий, связанных с выбранным элементом. В Android есть частично похожий на него элемент — Menus.
Menus Android применяется в большем числе кейсов: оно предлагает контекстные действия как для выбранного элемента, так и для всей страницы в целом; используется как инпут с несколькими вариантами на выбор (дропдаун меню); применяется для редактирования текста. Context Menus — компонент только iOS. А Menus Android можно использовать как в мобильном приложении, так и на десктопе.
25. Action View/Activity View vs Modal Bottom Sheet
| |
| |
26. Edit Menus vs Text Selection Tool Bar
Помимо визуального отличия Edit Menus и Text Selection Tool Bar отличаются следующим: при долгом нажатии в Android пользователь может продолжить выделение текста. В iOS после долго нажатия возникает лупа для точного выбора места в слове.
Также Android отличается от iOS тем, что при вызове дополнительных действий Text Selection Tool Bar принимает форму Menus.
27. Разный размер divider
В iOS это 0,5 pt, в Android — 1 dp.
Прочие отличия
28. Разные требования к размеру зоны нажатия
По гайдлайнам минимальная зона нажатия в iOS — 44 x 44 pt, а в Android — 48 x 48 dp.
29. App Store vs Google Play
Ваше приложение для iOS будут скачивать из App Store. Приложение для Android — из Google Play. Чтобы разместить приложение в сторах правильно, нужно соблюдать их требования. Требования App Store стоит прочесть здесь, а Google Play — здесь. Там много особенностей, поэтому рекомендую изучить перед публикацией.
30. Особый паттерн в iOS — Undo and Redo
Это особый паттерн iOS: если потрясти смартфон, приложение предложит пользователю отменить или повторить последнее совершенное действие. Как правило, этот жест используется для удаления введённого текста.
31. Отношение к Branded Launch
| |
32. Дополнительные темы Material Design
На сайте Material раскрыты ещё и такие темы, как: Data Formats (разные форматы данных), Data Visualization (правильная инфографика), Empty States (дизайн пустых состояний), Offline States (интерфейс при отсутствии интернета), Accessibility (доступный дизайн) и Bidirectionality (дизайн для читающих справа налево).
Заключение
Знание гайдлайнов повышает наш уровень осознанности. Мы понимаем сложившиеся пользовательские паттерны и создаём приложение, которое органично вписывается в привычки пользователей.
Гайдлайны побуждают нас уважать нативные решения платформ. При адаптации дизайна под другую платформу всегда есть соблазн продублировать дизайн без изменений. Это вредит пользовательскому опыту и усложняет разработку. Но когда мы видим различия в нативных решениях, мы адаптируем дизайн правильно.
А если мы хотим внедрить новое, кастомное решение, знание гайдлайнов помогает аргументировать это нововведение.
Итого: знание гайдлайнов и их отличий — важный навык дизайнера мобильных приложений.
Какие ещё отличия вы знаете? Поделитесь ими в комментариях.