Для чего нужны гайдлайны мобильным приложениям

Что такое гайдлайны мобильных приложений и зачем они нужны?

Jun 14, 2018 · 4 min read

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

Что это и зачем это вообще нужно?

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

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

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

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

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

На данный момент существуют два гайда под две небезызвестные платформы:

Google Material Design System

Google Material Design был представлен вместе с Android 5.0 в июне 2014 года, а с мая этого года стал полноценной дизайн-системой и уже может быть использован и на других платформах (например, смарт-тв, десктоп- или даже веб-приложение, iOS-устройство). Изначально был направлен только на ОС от Google: Android Wear, Android TV, Android Auto.

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

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

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

В Material Design System есть все. Здесь есть все системные иконки, UI-киты, шрифты, цветовые палитры, и даже плагин для Sketch для генерации кастомного UI. И все это можно скачать прям тут. Здесь вы найдете все размеры для каждого даже самого незначительного элемента интерфейса. Найдете кучу примеров, как делать можно, а как делать нельзя. Увидите кучу анимированных примеров. Найдете инфу про типографику, где и какой шрифт нужно использовать, с каким отступом, интерлиньяжем и кеглем. Везде по всему гайду есть ссылки на нужные разделы и если вы не знаете чего-то, то об этом сразу будет внизу сноска.

Словом, Google сделали самый лучший гайд (а сейчас уже дизайн-систему) в истории мобильного мира.

Apple Human Interface Guidelines

Apple Human Interface Guidelines был представлен вместе с iOS 7 июне 2013 и с тех пор расширился для использования с другими ОС от Apple (watchOS, macOS, tvOS).

Основной идеей Human Interface Guidelines является простота и «воздушность» интерфейса. Во главу угла возводится контент, а интерфейс уходит на второй план. Приветствуется интерактивность (отзывчивость) и анимация изменения состояния элементов интерфейса. Размытие окон на нижнем уровне, градиентные заливки, болдовая типографика в лучших традициях швейцарского стиля.

В отличие от Material Design System в Human Interface Guidelines нет четких правил и конкретных спецификаций. Например, нельзя в гайдах от Apple посмотреть размер кнопок. Некоторые элементы интерфейса просто в гайде отсутствуют, хотя используются в официальных приложениях от Apple. Здесь в отличие от Google, Apple как бы разрешает дизайнеру «поиграть со шрифтами» и дает больше свободы для кастомизации в рамках платформы.

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

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

Почему нужно использовать гайды?

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

Полезные ссылки

Буду рад вашим комментариям 💬 и аплодисментам 👏.

Источник

Гайдлайны мобильных приложений

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

Apple

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

Из минусов стоит отметить отсутствие русского языка, но есть любительский перевод. Почитать: medium.com/ios-guidelines-in-russian.

Обратите внимание на пошаговое руководство по разработке приложений для iOS: https://developer.apple.com/library/ios/referencelibrary/GettingStarted/DevelopiOSAppsSwift/index.html. Руководство поможет человеку, даже мало знакомому с разработкой приложений, позакомиться с этапами разработки. Для этого сначала необходимо скачать главный инструмент разработчика Xcode, а после с пошаговыми инструкциями создать свой первый мини-шедевр.

Совместив гайдлайн с руководством для разработчика, можно постигнуть начальное понимание разработки приложение для iOS. Для всего остального, в том числе разжёвывания прочитанного, естьпрофессия кем работать» rel=»dofollow»> профессия — «Разработчик iOS».

Google

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

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

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

Минус всё тот же: русского языка найти не удалось. Хорошая обзорная статья на русском от Redmadrobot: «Material Design: на Луну и обратно».

Windows Phone

После внимательного изучения и работы с подобными руководствами от Google и Apple, не покидает ощущение некоторой «топорности» гайдлайна Windows Phone. Кажется, что создателям очень не хотелось придерживаться корпоративной политики оформления подобной документации, но начальство настояло.

Главный плюс гайдлайна — русский язык. Информация изложена подробно, но недостаточно удобно структурирована, многовато «воды» для подобного руководства. Однако, если рассматривать гайдлайн не как учебник, который надо сначала прочитать, а потом приступать к разработке, а как карманный справочник — тогда можно признать, что подобное излишество полезно.

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

Что думаете о гайдлайнах? Рассказывайте.

Обучение по гайдлайнам: факультет «Android-разработчик».

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

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

Apple

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

Из минусов стоит отметить отсутствие русского языка, но есть любительский перевод. Почитать: medium.com/ios-guidelines-in-russian.

Обратите внимание на пошаговое руководство по разработке приложений для iOS: https://developer.apple.com/library/ios/referencelibrary/GettingStarted/DevelopiOSAppsSwift/index.html. Руководство поможет человеку, даже мало знакомому с разработкой приложений, позакомиться с этапами разработки. Для этого сначала необходимо скачать главный инструмент разработчика Xcode, а после с пошаговыми инструкциями создать свой первый мини-шедевр.

Совместив гайдлайн с руководством для разработчика, можно постигнуть начальное понимание разработки приложение для iOS. Для всего остального, в том числе разжёвывания прочитанного, естьпрофессия кем работать» rel=»dofollow»> профессия — «Разработчик iOS».

Google

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

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

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

Минус всё тот же: русского языка найти не удалось. Хорошая обзорная статья на русском от Redmadrobot: «Material Design: на Луну и обратно».

Windows Phone

После внимательного изучения и работы с подобными руководствами от Google и Apple, не покидает ощущение некоторой «топорности» гайдлайна Windows Phone. Кажется, что создателям очень не хотелось придерживаться корпоративной политики оформления подобной документации, но начальство настояло.

Главный плюс гайдлайна — русский язык. Информация изложена подробно, но недостаточно удобно структурирована, многовато «воды» для подобного руководства. Однако, если рассматривать гайдлайн не как учебник, который надо сначала прочитать, а потом приступать к разработке, а как карманный справочник — тогда можно признать, что подобное излишество полезно.

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

Что думаете о гайдлайнах? Рассказывайте.

Обучение по гайдлайнам: факультет «Android-разработчик».

Источник

Гайдлайны для новичков в Android-разработке: что прямо сейчас намотать на ус

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

С первых шагов уделяйте внимание производительности

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

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

Вывод: не заставляйте пользователя и другие программы страдать, грамотно расходуйте оперативную память, CPU, GPU и батарею.

Не допускайте утечек памяти

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

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

Несколько полезных рекомендаций:

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

Создавайте побочные треды

Для того чтобы улучшить производительность приложения, обеспечить хороший отклик и избежать распространенную ошибку ANP («приложение не отвечает»), стоит разделять внутреннюю архитектуру выполнения приложения на потоки (треды). Это позволяет не перегружать главный поток, настроенный по умолчанию. Подробнее про процессы и потоки почитайте на официальном сайте.

Используйте strings.xml

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

Настройте Gradle по умолчанию

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

Садитесь учить паттерны проектирования

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

И учите Kotlin

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

Да и вообще, подходите к обучению комплексно

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

Для этого лучше довериться профессионалам и записаться на программу в онлайн-университете. В отличие от обычных курсов, у вас будет персональный помощник-куратор — он поможет быстро разобраться с вопросами, на которые у новичков часто уходят недели. Помимо этого обучение построено проектно-ориентировано — это значит, что вы будете создавать реальные приложения в процессе прохождения программы. Аналогичный подход используется в ведущих учебных центрах США. Год обучения = год опыта разработки.

Источник

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 (дизайн для читающих справа налево).

Заключение

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

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

А если мы хотим внедрить новое, кастомное решение, знание гайдлайнов помогает аргументировать это нововведение.

Итого: знание гайдлайнов и их отличий — важный навык дизайнера мобильных приложений.

Какие ещё отличия вы знаете? Поделитесь ими в комментариях.

Источник