Нативний дизайн VS веб-елементи: що краще (Частина 1)

Що краще – нативний дизайн чи веб-елементи – ця суперечка постійно точиться між дизайнерами, розробниками та продакт-менеджерами. Сьогодні ми пропонуємо вам цікаві роздуми дизайнера із Росії Артема Щапа – про те, чому в мобільній розробці краще використовувати нативний дизайн замість веб-елементів.

Частина 1

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

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

Кілька рекомендацій, як цього уникнути.

Дотримання гайдлайнів

У Apple і Google свої принципи побудови інтерфейсів і своя візуальна мова.

Навіщо це зроблено? Наприклад, користувач користується поштою або будильником, він відкриває ваш додаток – і бачить знайомі елементи. Він знає, як їх використовувати, вони передбачувані і зручні. Це робить додаток зрозумілим.

Багато хто називає це «нативним дизайном».


Використання ненативних елементів у дизайні

Чим загрожує використання «ненативних» елементів при створенні дизайну?

1) Збільшення і термінів, і витрат

Наприклад, вам захотілося незвичайний світчер, як у вас на сайті. Замість стандартного елемента, який додається одним рядком коду, ви опрацьовує всі стану елемента (включений, виключений, затиснутий, неактивний), адаптуєте його під орієнтації екрану і так далі. Це збільшує час і витрати. Додати нативний елемент можна за 0-3 години, а зробити свій – за 1-2 дні.

2) Підтримка старих версій операційних систем

З виходом нової операційної системи або API вам доведеться підтримувати гарний вебовський елемент для всіх попередніх версій.

Давайте на пальцях. Вам потрібна світчер на Android.

Варіант перший. Ви берете нативний світчер (Switch).

Виходить нова версія Android, і ваш світчер автоматично відображається відповідно до вимог нової операційної системи.

Варіант другий. Ви малюєте «свій», красивий, не як у всіх, світчер.

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

Зліва – екран управління з ненативним елементами. Праворуч – з нативним.

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

Намалювати в повідомленні елементи вибору – логічно і зручно, але для вебу. У мобільному додатку краще для цього використовувати модальний екран.


Елементи кочують з iOS в Android і назад

Іноді дизайнер переносить свій досвід з Android в iOS, тому що користується Android. І навпаки. Наприклад, намалює поле для введення, де плейсхолдер піднімається. Це ненативним для iOS, це фішка з Android.

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

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

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

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

____

Шукайте продовженняцього цікавого матеріалу у нашій рубриці “Лонгріди

Вам сподобалося?

Читайте щотижня наші кращі статі про дизайн!

email рассылки

Корисна розсилка!

Все найцікавіше про дизайн і дизайнерів!
А ще свіжі вакансії і трішки гумору)

Ваш email:
email рассылки
Позначки:

Залишити відповідь