Лого vc.ru

«Дизайн сделает знакомый веб-дизайнер, а мобильную разработку закажем отдельно»

«Дизайн сделает знакомый веб-дизайнер, а мобильную разработку закажем отдельно»

Арт-директор студии разработки WOXAPP Артем Щап о том, почему в мобильной разработке лучше использовать нативный дизайн вместо веб-элементов.

К нам часто приходят клиенты с готовым дизайном, сделанным без учета требований операционных систем iOS и Android. Хорошие веб-дизайнеры рисуют проблемный для мобильной разработки интерфейс.

«Дизайн сделает знакомый веб-дизайнер, а мобильную разработку закажем отдельно» – в итоге в дизайне появляются веб-элементы, которые непригодны для мобильных приложений. Такие элементы непонятны для пользователей, ухудшают опыт взаимодействия с приложением и затягивают сроки разработки.

Собрали несколько рекомендаций, как этого избежать.

Написанное является нашим опытом в нативной мобильной разработке. Будем рады, если поделитесь своим опытом, комментариями и дополнениями.

Следование гайдлайнам

У Apple и Google свои принципы построения интерфейсов и свой визуальный язык.

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

Многие называют это «нативным дизайном».

Использование ненативных элементов в дизайне

Чем грозит использование «ненативных» элементов при создании дизайна?

1) Увеличение и сроков, и затрат.

Например, вам захотелось необычный свитчер, как у вас на сайте. Вместо стандартного элемента, который добавляется одной строчкой кода, вы прорабатываете все состояния элемента (включен, выключен, зажат, неактивен), адаптируете его под ориентации экрана и так далее. Это увеличивает время и деньги. Добавить нативный элемент можно за 0-3 часа, а сделать свой – за 1-2 дня.

2) Поддержание старых версий операционных систем.

С выходом новой операционной системы или API вам придется поддерживать красивый вебовский элемент для всех предыдущих версий.

Давайте на пальцах. Вам нужна переключалка на Android.

Вариант первый. Вы берете нативную переключалку (Switch).

Выходит новая версия Android, и ваша переключалка автоматически отображается согласно требованиям новой операционной системы.

Вариант второй. Вы рисуете «свою», красивую, не как у всех, переключалку. С обновлением операционной системы эта переключалка меняться не будет, она такой и останется. Во-первых, в свежей ОС будет ваш визуально устаревший элемент. Во-вторых, на всех ранних версиях нужно следить за корректностью работы и поддерживать этот элемент. Оно вам надо?

Слева – экран приложения с ненативными элементами. Справа – с нативными.

Два визуально похожих уведомления. Но слева – кастомный алерт, справа – нативный.

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

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

Элементы кочуют с iOS в Android и обратно

Иногда дизайнер переносит свой опыт с Android в iOS, потому что пользуется Android. И наоборот. Например, нарисует поле для ввода, где плейсхолдер поднимается. Это ненативно для iOS, это фишка из Android.

Дизайн для Android и iOS это два разных дизайна. На примере – один экран приложения для такси для разных платформ.

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

Меню «гамбургер»

Глобальная навигация проекта через «гамбургер меню» — это проблема. Например, в iOS это порождает довольно много проблем, так как нативная архитектура приложения строится «веточно» через TabBar, нативного элемента «гамбургер» нет.

Вот статьи тех, кто отказался от гамбургер меню и что получил в итоге.

Изменение паттерна навигации и отказ от «гамбургер меню» повлекли за собой увеличение сеансов (+ 70%) и возвращение пользователей (+ 65% DAU).

Дизайн-архитектура

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

В iOS и Android разная архитектура построения экранов

Для iOS приложений навигация строится линейно при помощи Tapbara. Глобально в приложении существуют несколько главных веток. Находясь на одной ветке, вы не можете перейти на другую.

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

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

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

Анимация

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

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

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

Использовать свою кастомную анимацию дорого. Да, это красиво и создает правильные ожидания, но окупится ли она? Это действительно кратно повлияет на показатели приложения? Желательно использовать нативную анимацию и осторожно относиться к кастомной.

Детализация сценариев

Бывает, клиент приходит с дизайном 10-15 основных экранов, думая, что на этом работа дизайнера завершена. Упущенные состояния и сценарии выливаются в долгий срок доработок и согласований. Нередки такие разговоры:

К: Я думал, после нажатия будет окно с подтверждением!

Р: Так его нет на дизайне.

К: Это стандартная вещь, я думал, и так понятно.

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

Что делать

  1. ​Убедитесь, что дизайнер знает требования операционных систем и использует нативные элементы. Знает особенности логики построения экранов для Android и iOS.
  2. Хотите нарисовать ненативный элемент? Ок, сверьте с бизнес-задачами. Если вы уверены, что это кратно повлияет на показатели приложения (например, увеличит процент регистраций или возвращаемость в приложение) или на продажи (конверсия, покупки), тогда делайте.

Присылайте свои колонки и интерфейсные кейсы на interface@vc.ru.

Теги

Вроде все правильно расписано и хорошо оформлено.. Без воды и по существу) Однако совсем уж понятные вещи любому, кто хоть на 2 минуты задумывался о web app.
Капитан Очевидность одобряет этот пост!

Преимущество нативного приложения перед "ненативным" - скорость работы.
Всё. Больше ничего писать и объяснять не нужно.

Для меня самым ярким и понятным примером нативного приложения являются банковские приложения. - Это те самые случаи, когда нативность просто необходима.

Для остального: суем material design и все дела.

Во-первых, андроид устройств в мире сейчас больше 80%. Очевидное колличественное доминирование. И для всех этих пользователей material будет по дефолту понятен.

Для остальных (невероятно!) тоже. Потому что андроид устройства настолько распространены, что ими обязательно хоть раз в жизни пользовался почти любой яблочник, неговоря уже о других ОС.

Это значит, что material интуитивно понятен ВСЕМ.

Во-вторых, нативная разработка ДОРОЖЕ и ДОЛЬШЕ.
И если говорить совсем грубо, то для нативщины нам нужны: - один дизайнер, один java-программист, и один swift-программист. 3 человека.

А для гибридного вполне хватит двух. При этом мы получаем приложение ДЛЯ ВСЕХ ОС, не только для Android и IOS, а еще и для Windows Mobile. Нативное приложение для которого пишется на C#, кстати, если мне не изменяет память.

Вообще, я обычно очень лояльно отношусь к мнениям специалистов.
Но вот эта вот статья - это какой-то ужас.
Больше похоже на попытку дешево и сердито пропиариться.

Не убедили, короче.
Но желаю удачи.

Material на iOS это совсем зашквар, я думаю Apple скорее всего даже не пропустит его в App Store, даже Гугл использует его на iOS очень умерено, совмещая с гайдлайнами Apple. С гибридными приложениями все не так просто, для какой либо платформоспецифической задачи все равно приходится лезть в objective-c/java, а в результате или используются те же аналоги нативных компонент(react native, xamarin.forms) или приходится все пилить вручную(electron) все равно делая две версии для ios/android. В результате в гибридных приложениях все же лучше использовать не material deisgn, а apple human interface guidelines потому что Apple пропустит, всем будет понятно как пользоваться, а Google наплевать

Андроидов больше, но iOS приносит больше денег.
А кросс-платформ полная херота - не нативно, медленно. Такое подойдёт для прототипирования, или для разработки Just For Fun, не более.

Расскажите про "не более, медленно и хероту" мобильным Facebook и Instagram

А где у них там react native? На не основных экранах только если

0

Разве Фб и инста не нативные?

0

Фейсбук на айос не нативный? Если так, то понятно, почему он весит больше, чем многие игры, когда вк вести всего 17 метров, и почему он так лагает.

не нативный они вообще сделали гибрид между гибридным react-native и нативным. Для чего это сделали сами толком не понимают code.facebook.com/posts/895897210527114/dive-into-react-native-performance/ в инстаграме такая же структура. Из плюсов видно что они быстрее всех вводят новые фичи

Речь не о нативном программировании, а о нативном ДИЗАЙНЕ.

0

Мстислав, спасибо за комментарий.
Использовать material design в iOS или нет – решать Вам. Если дизайнер понимает требования от Apple к элементами навигации и архитектуре приложения и сознательно их не использует, то это его выбор.
Важно, чтобы и клиенты понимали, что делает дизайнер. Это я хотел донести.

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

В целом согласен, основной поинт для меня: если нет целого отдела который будет поддерживать приложения, то ненативный дизайн устареет и будет дороже.
P.S. Гамбургер в андроид это был какой то ужас, с Android N Гугл уже отказывается от него, жду когда окончательно выпилят его из всех приложений

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

0

*наивность = нативность, писал с лопаты

0

потому что лопата не нативная? :)

0

Foma, спасибо за комментарий.
Нативную навигацию можно и нужно совмещать с фирменным стилем. В чем Вы видите противоречие?
Если мы не берем игры или специфические ниши, то привычная понятная навигация облегчает задачу продуктовую дизайну. Не надо учить и объяснять, какой элемент за что отвечает. Но если задача за счет нестандартной навигации и элементов выделиться, то отлично – давайте делать.

> Вы рисуете «свою», красивую, не как у всех, переключалку. С обновлением операционной системы эта переключалка меняться не будет, она такой и останется. Во-первых, в свежей ОС будет ваш визуально устаревший элемент.

Так, ладно, а если она опережает свое время на пару поколений, она все-равно со следующим обновлением будет визуально устаревшей?

> Глобальная навигация проекта через «гамбургер меню» — это проблема.

Для iOS проблема, а для Android норм?

> Используя кнопку «Вверх», вы попадаете из любого экрана в начало ветки.

material.io/guidelines/patterns/navigation.html#navigation-up-back-buttons в документации написано по-другому — up возвращает пользователя по экранам внутри приложения, back - то же самое, но по глобальной истории переходов (может быть через несколько приложений)

Хотелось бы пожелать авторам статьи больше работать над аргументацией и языком (а то большая часть аргументов выглядит как "надо делать вот так, потому что так вот надо делать"), а редакторам vc не пропускать подобный шлак

А еще у авторов сайт будто бы семилетней давности и с лобстером и гельветикой, оок)

0

Filipp,
сапожники без сапог, скоро будет новый

0

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

Да хотя бы вот на этот пример из статьи посмотрите: png.cmtt.space/paper-media/fb/e6/4f/9bc4213289ae45.png

Там где your switcher - это свичер очень напоминающий айосный, но видно что нативный свичер приблизился к нему по дизайну, в ранних версиях там вообще другой принцип был.

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

Ну и вообще сам подход "переключалка устареет когда придет обновление оси" нелогичный - как она устареет, если у нее принципиально другой дизайн?

0

Filipp, спасибо за комментарий.

«Так, ладно, а если она опережает свое время на пару поколений, она все-равно со следующим обновлением будет визуально устаревшей?»

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

«Для iOS проблема, а для Android норм?»
Если структура контента позволяет уйти от этого элемента, лучше это сделать. Это касается iOS и Android.

> Используя кнопку «Вверх», вы попадаете из любого экрана в начало ветки.
«material.io/guidelines/patterns/navigation.html#navigation-up-back-buttons в документации написано по-другому — up возвращает пользователя по экранам внутри приложения, back - то же самое, но по глобальной истории переходов (может быть через несколько приложений)»

Уточните, в чем Вы видите несхожесть?

Если пользователь перешел с ветки на ветку внутри приложения, то используя «Вверх» он пойдет по ветке, а «Назад» - по истории (при условии, что разработчик никак не кастомизировал эти события).

В случае, если мы говорим про переход из приложения в приложение, то «Назад» может переводить в другое приложение, если мы его вызвали в текущем приложении. Например, при шаринге или вызове камеры. Или, например, после установки с Google Play «Назад» переведет с приложения обратно в Google Play. Если вызова не было, то история обрывается при выходе на рабочий стол.
Поправьте, если не прав.

0

> Если структура контента позволяет уйти от этого элемента, лучше это сделать. Это касается iOS и Android.

Но это же противоречит смыслу статьи, поскольку в Андроид вокруг гамбургера строится вся навигация:)

> Уточните, в чем Вы видите несхожесть?

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

В общем от статьи осталось несколько скомканное впечатление и аргументация не всегда достаточно раскрыта.

0

Filipp, спасибо за уточнение.

«Но это же противоречит смыслу статьи, поскольку в Андроид вокруг гамбургера строится вся навигация:)»

Уточните, из какого тезиса в статье сделан такой вывод?

«В общем от статьи осталось несколько скомканное впечатление и аргументация не всегда достаточно раскрыта.»
По аргументации принял. Действительно, можно было более подробно описать.

0

Сбербанк уже сделали редизайн приложения, как они говорят "для соблюдения гайдов ios". В итоге пользоваться стало вообще невозможно.

0

Они похоже там свои собственные гайдлайны для ios разработали. Вот нахрена у них экран приложения с закруглёнными краями.

Я думаю, это потому, что веб-дизайнер делал дизайн iOS приложения,. В России вообще не преподают iOS дизайн, потому что не MIT. В принципе - все - "самоучки". Кто как понял, так и сделал.

Гамбургер и в андроиде полное говно с точки зрения юзабилити - пользователю сложнее найти нужные ему вещи, и нужно делать доп клики.
Такое меню было оправдано, когда экраны были маленькими. Сейчас, в век лопат, такая экономия совсем ни к чему.

Очень радовался факту появления нативного таб бара в ведроиде, но, имхо, у гугла не получилось - перемудрили они там со скрытием тайтлов, и пользоваться из-за этого неудобно. Почему было нельзя просто перенести таббар из айоси в материал дезигн - непонятно.

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

Бургер меню само по себе не опасно, это довольно устоявшийся паттерн сквозной навигации. Опасно совмещать и табы и бургер (есть печальные примеры), вот тут и начинается трэш. Ради 4-5 пунктов бургер не нужен, это факт. Но когда есть много контента (предположим приложения для трейдинга, различные информационные системы), то с табами можно жёстко обосраться, и никакая карточная сортировка не поможет уложить это всё в 4-5 вкладок.

Про табы в определенных случаях все так, само собой. Правда, в случае контентного приложения, где есть скролл, проблема отжирания нужного места решается автоскрытием табов и тулбара при скролле.
А с бургером лично сталкивался с тем, что после введения навигации табами в Android-приложении существенно выросло время, проведенное в приложении в среднем — стали смотреть больше контента.

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

0

Кол-во просмотров за сессию тоже выросло, пропрорционально времени :)

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

0

Согласен, в конечном случае, всё решают пользователи. Особенно убивает стандартное всплывающее сообщение об ошибке в каком-нибудь кастомном дизайне в iOS. Особенно если это финансовое, транспортное и прочее функциональное приложение или магазин. То есть не игры и развлечения. Это шок и боль. А если еще и с ошибкой - приложение удаляется со свистом и более никогда не устанавливается повторно. Так что рекомендация использовать стандартные "нативные" сообщения для пользователей это очень не продуманный шаг, по моему. Лучше вообще не пугать пользователя. Подальше разместить ссылку на экран с информацией или статусом доставки, доп. информацией, не надо показывать всплывающие окна в принципе, они нарушают всё - принципы навигации, они воспринимаются как экстраординарное событие, ошибка, нарушающее привычную навигацию. Что-то вроде emergency-call

0

На самом деле всё зависит от проектируемой системы.
Однозначно ошибки и сбои иногда могут происходить, но сообщения об ошибке:
1. Должны быть переведены на язык пользователя;
2. Должны содержать информацию о том, как их избежать в будущем/исправить.

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

0

Артур, спасибо за комментарий.
Вопрос «показывать или не показывать» не стоит. Вопрос, если дизайнер решил что надо показывать алерт, зачем его делать кастомным?

0

У кого есть Alfa-Bank, посмотрите на свои приложения в Android и в Google. Если нет - не комментируйте. Далее. Это - пример "ненативного" дизайна, однако регулярно обновляемого. В котором есть все от чего комментаторы выше падают в обморок, однако это совершенно не мешает пользоваться приложением а наоборот - придает ему исключительность и уникальность. Выводы: если пользователи хотят исключительный экспириенс, и он им нравится, выкиньте этот гайдлайн в трубу, потому что в конечном счете решают не корпорации а люди, для которыъх всё это сощдается. А вопросы дизайна, бюджета и сроков - это проблемы разработчиков, а не пользователей. Другимим словами, если целевая аудитория сидит на iOS, но жаждет элементы "Material Design", она получит "Material Design", потому что имиджевые придукты и брендирование никуда не девается. Люди узнают в дизайне приложения бренд Альфа-Групп, и доверяют ему. А "нативный дизайн" размазывает бренд, и такое приложение становтися неотличимым от приложения школьника Васи c Vasiliy LTD, вчера научившемуся делать переходы между экранами и нативные элементы в Android, и к которому соответственно доверия у пользователя этой поделки на скорую руку не будет. Так что быть 100% нативным в Android - это очень дешево, однако за дешевизной не всегда стоит гнаться, IMHO. Для каждого приложения должен быть баланс 80-20, и в случае больших бюджетов - 60-40, 50-50, в соотношении "нативного" и "брендированного" дизайна. Что касается выплывающих окон - это вообще недопустимо, по моему. Только в крайних случаях. В лучшем случае - как шаг Wizard-а, User Guid-а при вервом использовании, которое можно целиком пропустить или Соглашения об использовании, но не как рядовой элемент.

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

0

Да, сохранилось большинство экранов и переходов. Что есть плюс, добавилось несколько новых, пользоваться стало проще. Думаю, что у Альфа-Групп вообще бюджет не лимитирован для мобильного приложения, потому что мне не верится, в то, что они смогли сделать улучшения в достаточно, на мой взгляд хорошем приложении (в предыдущем дизайне). Он очень хорош, это да. Возможно, (это предположение), он выполнен не российскими специалистами, а только лишь "допилен". Но это внутреннее ощущение. Возможно заказали именно дизайн, а реализовали тут. Сложно в России найти дизайн-студию, кроме всем известной, а мобильных дизайнеров просто не обучают, по-моему.

0

Радуют комментаторы, которые к статье про "дизайн сделает знакомый дизайнер" достают из широких штанин приложения сбербанка и альфа-банка.
Статья о том, что при ограниченном бюджете делайте по гайдам с дизайнером, который их знает. Сделайте отступления от гайдов по согласованию с разработчиком. Не делайте отсебятины, не зная гайдов.
Люди, вы вообще работали в отрасли, сталкивались с реальными клиентами, которым нужно приложение для каких-то целей, которые считают деньги и заказывают бюджетную разработку? Или тут онли продакты банков, аэрофлотов и Правительства РФ?

Прямой эфир
Приложение-плацебо скачали
больше миллиона раз
Подписаться на push-уведомления