Різниця нативного дизайну під iOS та Android: мікровзаємодія

Продовжуємо розповідь про особливості дизайну для платформ та .

Читайте першу частину ТУТ!

Читайте другу частину ТУТ!

Мікровзаємодія

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

Ось чому так важливо з самого початку привернути увагу користувачів. Під час проектування і розробки додатків за допомогою мікровзаємодій і анімацій ми можемо створити для користувачів дійсно захоплюючий досвід.

Давайте визначимо основні правила і рекомендації щодо взаємодій і рухів для обох платформ і розглянемо докладні приклади.

Фокус і важливість. Взаємодії фокусують увагу користувача на те, що дійсно важливо в додатку, тому необхідно використовувати їх тільки тоді, коли це дійсно необхідно. Обидві платформи перешкоджають надмірної анімації, оскільки вона відволікає і напружує користувачів.

Узгодженість та ієрархія. Дуже важливо пам’ятати, що взаємодія допомагає користувачам орієнтуватися в додатку, показуючи, як елементи пов’язані один з одним. Знайомі, плавні і ненав’язливі переходи з одного екрана на інший захоплюють користувачів. Рух вказує, як виконувати дії і пропонує корисні підказки.

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

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

Користувачі iOS звикли до тонких анімацій, наприклад, до плавних переходів, плавних змін в орієнтації пристрою і скролінгу на основі фізики. Користувачі iOS можуть відчувати себе дезорієнтованими, коли руху не мають сенсу або, здається, не відповідають законам фізики. Наприклад, якщо користувач відкриває сторінку, змістивши її вниз з верхньої частини екрану, він очікує, що зможе закрити її, зсунувши в протилежному напрямку назад. рекомендує робити переходи, що можна налаштувати, подібні до вбудованих анімацій, якщо ви не створюєте імерсивні досвід (наприклад, гра).

Відповідно до Material Design Guidelines, в процесі переходу перетворені елементи інтерфейсу класифікуються як вихідні (outgoing), вхідні (incoming) та постійні (permanent). Категорія, до якої належить елемент, впливає на те, як він перетворюється.

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

Переходи навігації є важливим елементом загального взаємодії з інтерфейсом. Вони допомагають користувачам орієнтуватися, висловлюючи ієрархію додатки. Наприклад, коли елемент розкривається, щоб заповнити весь екран, дія розкриття висловлює, що новий екран є дочірнім елементом. Екран, з якого він розкривається, є його батьківським елементом.

Приклад переходу від батьківського екрану до дочірньому (Material Design Guidelines)

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

Екрани, що мають загальний батьківський екран (наприклад, фотографії в альбомі, розділи в профілі), переміщаються в унісон, щоб зміцнити свою взаємозв’язок. Дочірній екран ковзає в одну сторону, в той час, як його родинний екран зміщується в протилежному напрямку.

Вкладки знаходяться на одному рівні і переміщаються разом по горизонталі

На верхньому рівні додатку пункти призначення часто групуються в основні завдання (які можуть бути не пов’язаними один з одним). Ці переходи екранів замінюються шляхом зміни таких значень, як непрозорість і масштаб.

***

Далеко не всі додатки дотримуються нативного підходу, причому зазвичай найбільші і найвідоміші додатки мають однаковий дизайн для всіх платформ. Причому, деякі додатки iOS дотримуються рекомендацій Material Design Guidelines (наприклад, Gmail), а деякі додатки для Android дотримуються рекомендацій Human Interface Guidelines (наприклад, ). 

Але не слід на них орієнтуватися при розробці додатків, адже ставлення до розробки крупних корпорацій та невиликих підприємств/стартапів дуже відрізняється. У Facebook, наприклад, є ціла своя система розробки React-Native, в якій для розробки використовуються ненативні мови програмування для iOS та Android. Але таку розкіш без втрати якості можуть дозволити собі лише дуже крупні компанії. І навіть мостри не завжди в змозі підтримувати розробку додатків на JavaScript. Наприклад, Airbnb цього року відмовилося від використання React-Native і перейшла до нативної розробки.

Тож, краще не пливти проти течії, а використовувати силу нативних можливостей платформ, для забезпечення чудового досвіду своїх користувачів!

За матеріалами: medium.muz.li

Вас також ЗАЦІКАВИТЬ:

 

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

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

email рассылки

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

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

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

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