Арт-директор студии разработки WOXAPP Артем Щап о том, почему в мобильной разработке лучше использовать нативный дизайн вместо веб-элементов.
Арт-директор студии разработки WOXAPP Артем Щап о том, почему в мобильной разработке лучше использовать нативный дизайн вместо веб-элементов.
Почему в примерах "натив/не натив" приятнее смотреть на ненативный дизайн?
наверное, потому что вы смотрите на дизайн моб. приложения, удобно расположившись перед компом. В реальной жизни в приложении редко рассматривают "приятность", а требуется функциональность и понятность.
Автор говорит о том, что если вы делаете дизайн приложения - делайте в соответствии с гайдлайнами, т. е. обратитесь к тому, кто знает их.
Отступать от них можно, если знать, зачем. Отступление предполагает удорожание разработки и поддержки.
По-моему, это очевидно)
Встречаю приложения, которые вообще выглядят, как моб. версия сайта.
Foma, спасибо за комментарий.
Нативную навигацию можно и нужно совмещать с фирменным стилем. В чем Вы видите противоречие?
Если мы не берем игры или специфические ниши, то привычная понятная навигация облегчает задачу продуктовую дизайну. Не надо учить и объяснять, какой элемент за что отвечает. Но если задача за счет нестандартной навигации и элементов выделиться, то отлично – давайте делать.
Вы рисуете «свою», красивую, не как у всех, переключалку. С обновлением операционной системы эта переключалка меняться не будет, она такой и останется. Во-первых, в свежей ОС будет ваш визуально устаревший элемент.
Так, ладно, а если она опережает свое время на пару поколений, она все-равно со следующим обновлением будет визуально устаревшей?
Глобальная навигация проекта через «гамбургер меню» — это проблема.
Для iOS проблема, а для Android норм?
Используя кнопку «Вверх», вы попадаете из любого экрана в начало ветки.
https://material.io/guidelines/patterns/navigation.html#navigation-up-back-buttons в документации написано по-другому — up возвращает пользователя по экранам внутри приложения, back - то же самое, но по глобальной истории переходов (может быть через несколько приложений)
Хотелось бы пожелать авторам статьи больше работать над аргументацией и языком (а то большая часть аргументов выглядит как "надо делать вот так, потому что так вот надо делать"), а редакторам vc не пропускать подобный шлак
А еще у авторов сайт будто бы семилетней давности и с лобстером и гельветикой, оок)
Как нарисовать переключалку которая опережает время? )) Это нужно быть дизайнером из гугла который знает что его переключалку скоро выкатят. Да и она будет смотреться не актуально в данный момент, среди современных переключалок.
Filipp, спасибо за комментарий.
«Так, ладно, а если она опережает свое время на пару поколений, она все-равно со следующим обновлением будет визуально устаревшей?»
Если дизайнер в ней уверен и понимает какую задачу она решит, то проблем нет. Единственное, придется ее поддерживать на всех версиях.
«Для iOS проблема, а для Android норм?»
Если структура контента позволяет уйти от этого элемента, лучше это сделать. Это касается iOS и Android.
Используя кнопку «Вверх», вы попадаете из любого экрана в начало ветки.«material.io/guidelines/patterns/navigation.html#navigation-up-back-buttons в документации написано по-другому — up возвращает пользователя по экранам внутри приложения, back - то же самое, но по глобальной истории переходов (может быть через несколько приложений)»
Уточните, в чем Вы видите несхожесть?
Если пользователь перешел с ветки на ветку внутри приложения, то используя «Вверх» он пойдет по ветке, а «Назад» - по истории (при условии, что разработчик никак не кастомизировал эти события).
В случае, если мы говорим про переход из приложения в приложение, то «Назад» может переводить в другое приложение, если мы его вызвали в текущем приложении. Например, при шаринге или вызове камеры. Или, например, после установки с Google Play «Назад» переведет с приложения обратно в Google Play. Если вызова не было, то история обрывается при выходе на рабочий стол.
Поправьте, если не прав.
Преимущество нативного приложения перед "ненативным" - скорость работы.
Всё. Больше ничего писать и объяснять не нужно.
Для меня самым ярким и понятным примером нативного приложения являются банковские приложения. - Это те самые случаи, когда нативность просто необходима.
Для остального: суем 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, не более.
Мстислав, спасибо за комментарий.
Использовать material design в iOS или нет – решать Вам. Если дизайнер понимает требования от Apple к элементами навигации и архитектуре приложения и сознательно их не использует, то это его выбор.
Важно, чтобы и клиенты понимали, что делает дизайнер. Это я хотел донести.
Вроде все правильно расписано и хорошо оформлено.. Без воды и по существу) Однако совсем уж понятные вещи любому, кто хоть на 2 минуты задумывался о web app.
Капитан Очевидность одобряет этот пост!
Гамбургер и в андроиде полное говно с точки зрения юзабилити - пользователю сложнее найти нужные ему вещи, и нужно делать доп клики.
Такое меню было оправдано, когда экраны были маленькими. Сейчас, в век лопат, такая экономия совсем ни к чему.
Очень радовался факту появления нативного таб бара в ведроиде, но, имхо, у гугла не получилось - перемудрили они там со скрытием тайтлов, и пользоваться из-за этого неудобно. Почему было нельзя просто перенести таббар из айоси в материал дезигн - непонятно.
Бургер меню само по себе не опасно, это довольно устоявшийся паттерн сквозной навигации. Опасно совмещать и табы и бургер (есть печальные примеры), вот тут и начинается трэш. Ради 4-5 пунктов бургер не нужен, это факт. Но когда есть много контента (предположим приложения для трейдинга, различные информационные системы), то с табами можно жёстко обосраться, и никакая карточная сортировка не поможет уложить это всё в 4-5 вкладок.
Согласен, в большинстве случаев, когда навигацию можно сократить до 5 пунктов, нижний навбар очень удобен.
В последних версиях названия разделов не скрываются - например, в ютубе, книгах, прочем.
Кстати, упомянутые лишние тапы по экрану сами по себе не являются юзабилити проблемой до тех пор, пока понятны. К примеру, присутствие вкладок и снизу и сверху создают массу проблем, в частности - продуктивность сходит на нет.
В целом согласен, основной поинт для меня: если нет целого отдела который будет поддерживать приложения, то ненативный дизайн устареет и будет дороже.
P.S. Гамбургер в андроид это был какой то ужас, с Android N Гугл уже отказывается от него, жду когда окончательно выпилят его из всех приложений
У кого есть 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 очень даже хорош. Но с момента, когда они внедрили этот дизайн, до момента, когда он стал наконец-то допиленным прошло очень много времени, и пользоваться их приложением до этого момента была не очень приятно.
Радуют комментаторы, которые к статье про "дизайн сделает знакомый дизайнер" достают из широких штанин приложения сбербанка и альфа-банка.
Статья о том, что при ограниченном бюджете делайте по гайдам с дизайнером, который их знает. Сделайте отступления от гайдов по согласованию с разработчиком. Не делайте отсебятины, не зная гайдов.
Люди, вы вообще работали в отрасли, сталкивались с реальными клиентами, которым нужно приложение для каких-то целей, которые считают деньги и заказывают бюджетную разработку? Или тут онли продакты банков, аэрофлотов и Правительства РФ?
Сбербанк уже сделали редизайн приложения, как они говорят "для соблюдения гайдов ios". В итоге пользоваться стало вообще невозможно.
Они похоже там свои собственные гайдлайны для ios разработали. Вот нахрена у них экран приложения с закруглёнными краями.