За останній рік інтерфейс Android покращувався з феноменальною швидкістю (я підібрав невелику галерею додатків, які мені подобаються в Google+). Багато змін були лише косметичними (тема Holo в ICS, шрифт Roboto, і т.д.). Ми не побачили великих якісних змін в принципах проектування інтерфейсів. Але, можливо, саме зараз проходить одна така.
Майже одночасно декілька додатків задіяли бокову навігацію, як в додатку Facebook. Спочатку ми побачили, як вона використовується в новому дизайні Spotify, а потім, майже відразу рішення перейняли в Evernote. Не пройшло і року, в новому дизайні додатку Google+ представили аналогічне меню.
Реалізована бокова навігація в кожному з цих додатків по-своєму. Вона по-різному виглядає, відчуття від її використання різні, хоча фундаментально підхід однаковий. Ідея в тому, щоб представити користувачеві найшвидший спосіб дістатись до найважливіших областей додатку без необхідності покидати поточний екран.
Візуальні відмінності в реалізаціях очевидні. Наприклад, в додатку Google+ меню з’являється поверх поточного екрану, а в інших — поточний екран змінюється в бік. Google+ використовує іконку переходу вверх, а Action Bar залишається на місці, навіть, якщо меню відкрито, в той час, як в інших додатках — ні.
Цікаву дискусію про цей паттерн можна почитати в блозі (англ.) автора додатку Google+.
Dashboard мертвий
Бокова навігація замінює Dashboard-паттерн, який багато критикують. Основним аргументом було те, що він гальмує дії користувача на шляху до беспосередньо контенту програми. Кожного разу, запускаючи додаток ми повинні спочатку натиснути на іконку, обравши куди ми хочемо перейти.
Dashboard також вимагає повернення на головний екран, якщо ви хочете перейти в іншу частину програми. Ось абстрактний скетч стандартного додатку на Android, тут є dashboard і одна секція додатку, яка є списком елементів; натискання на будь-який елемент списку переносить нас на детальний екран цього елементу (типова структура мобільного додатку). В цьому прикладі користувач спочатку обирає елемент з dashboard’у, потім обирає один елемент із списку і переходить до самого елементу, після того переходить до наступного елементу.
Приклад демонструє складність в пересуванні між секціями додатку, якщо воно спроектовано за принципом dashboard.
Бокова навігація вирішує обидві проблеми. Користувач може напряму перейти у будь-який розділ додатку без необхідності повернення на домашній екран. Водночас, при запуску додатку відкривається один з головних екранів, на якому відразу доступний контент.
Наступний скетч — це приклад того ж додатку, але проектованого з боковою навігацією. По-перше, стартовий екран відразу показує контент і, по-друге, користувач може перейти у будь-яку частину додатку напряму з будь-якого екрану.
Я впевнений, що концепція бокової навігації краща за принцип dashboard’у. Ще залишаються випадки, коли можна задіяти dashboard, але таких ситуації буде все менше. В деяких, рідкісних випадках, не можливо відразу показати якийсь з екранів з контентом. Тоді dashboard залишається чудовим рішенням. Також дуже складні додатки можуть показувати користувачу простий dashboard лише при першому запуску, щоб вивалювати на нього все, що є відразу.
Ймовірно, прийшов час сказати «давайдосвіданія» цьому шаблону проектування, котрий був характерним символом Android ще не так давно.
Проблеми бокової навігації
На жаль, впровадити бокову навігацію правильно набагато складніше, ніж концепцію dashboard в силу деяких причин.
Вгору?
Я ніколи не був фанатом концепції кнопки «вгору» в Android. Я вважаю, що користувач не може зрозуміти різницю між переходами «вгору» і «назад». До того ж Google вирішив «допомогти» цьому тим, що дія «вгору» позначає стрілкою вліво. Кожен користувач, з ким я спілкувався, говорили про цю кнопку «вгору», як про кнопку «назад».
На мою думку, використання бокової навігації робить кнопку «вгору» застарілою і не потрібною. Якщо ваш додаток має гарну структуру, надає легкий доступ до будь-якого ключового екрану через бокову навігацію з будь-якого місця — користувачі ніколи не потрапляють далі, ніж через декілька «кліків» від будь-якого екрану. Кнопка смартфону «назад» вирішить більшість інших потреб навігації.
Якщо поглянути на додаток Google+ і на те, як тут працює бокова навігація, ми побачимо, що спочатку знадобиться перейти вгору на один з екранів категорій, щоб отримати доступ до бокової навігації. Я думаю, це вбиває її суть. Якщо я, наприклад, читаю одну новину і мені захотілося почати відео-конференцію, чому я повинен виходити зі стрічки новин, щоб дістатись до відео-чату?
Замість цього я був би значно більше радий бачити ліву-верхню кнопку Action Bar’а, яка відкривала б мені бокову навігацію, на будь-якому екрані додатку.
Якщо ж ви вирішили використовувати кнопку «вгору» разом з боковою навігацією, ви повинні переконатися в тому, щоб кнопка, яка відкриває бокову навігацію не виглядала, як кнопка для переходу «вгору». Використання кнопок однакового вигляду порушує фундаментальний принцип дизайну інтерфейсів — завжди повинно бути зрозумілим, яку дію виконує кнопка в інтерфейсі. Кнопка «вгору» (котра і так не зрозуміло, що робить) раптово отримує дві різні функції і користувач не може сказати, яку саме дію виконує кнопка в конкретний момент не натиснувши на неї.
Мені здається, нам потрібна інша іконка для бокової навігації, як частина операційної системи, котра додасть послідовність в концепт. Ось сирий ескіз того, що я маю на увазі. Перший малюнок показує, як виглядає домашня кнопка, коли на ній функціонал переходу «вгору» (так вона і виглядає зараз).
Другий малюнок — це ескіз того, як вона може виглядати , якщо на ній функціонал відкриття бокового меню. Це б врятувало користувачів від плутанини в додатках, котрі використовують і переходи «вгору» і бокову навігацію.
Проблеми зворотного стеку
Правильно керувати стеком повернень дуже важливо. Бокова навігація може ускладнити зворотний стек. Олександр Блом написав декілька непоганих заміток про це.
Рекомендую переглянути (англ.):
- Android navigation and Spotify (with friends);
- Slide-out navigation done better.
Що відкриває бокову навігацію?
Як користувачі зможуть відкрити бокову навігацію? Які жести і кнопки використовувати?
Бокова навігація, ймовірно, найважливіший компонент будь-якого додатку, в котрому вирішили її задіяти. Користувачі не зможуть нікуди перейти в програмі, якщо не будуть знати, як відкрити її.
Поекспериментувавши з усіма додатками, котрі використовують цей паттерн, я зрозумів, що у жодному з них не реалізували його ідеально. Найближче до ідеалу підійшов додаток Prixing. У ньому відкинули концепцію переходів «вгору» і зробили домашню кнопку, яка відкриває лише бокову навігацію.
Тут також добавили жест «свайп» від границі екрану (bezel swipe), щоб відкрити меню. Користувач не обов’язково знайде, що цей жест призводить до відкриття бокового меню, але це не є проблемою, так як є домашня кнопка, що відкриває його.
Тут я б хотів покращити лише одне — щоб додаток використовував свою іконку в якості домашньої кнопки, яка б додатково позначала, що вона відкриває саме бокове меню.
Інші додатки використовують різні методи відкриття бокового меню. Evernote, наприклад, використовує звичайний свайп в інтерфейсі. Це викликає проблему послідовності інтерфейсу, так як цей жест вже використовується для переміщення між закладками. Evernote використовує закладки в декількох місцях UI, тому бокова навігація недоступна для відкриття свайпом, якщо ми не знаходимось на крайній-лівій закладці.
Мої рекомендації щодо відкриття бокової навігації — завжди відкривати її з домашньої кнопки і підтримувати свайп від границі екрану. Якщо ж збираєтеся використовувати переходи «вгору», то переконайтеся, що іконки у кнопок «вгору» і «бокове меню» відрізняються.
Дії в боковій навігації
До цього я говорив саме про навігацію, але багато застосувань паттерну лежать за межами навігації. Мені це здається логічним. Action Bar — це місце для контекстних дій на екрані, де він розташований. Але, що робити, якщо у додатку є такі настільки важливі дії, що повинні бути доступними з будь-якого екрану?
Evernote вирішив цю проблему, розмістивши дії в боковому меню. Як на мене, їх рішення чудове. Можливо, здається дещо перевантаженим при першому використанні, але чітке візуальне розділення елементів навігації і дій допомагають користувачу легко представити в голові модель того, де тут навігація, а де конкретні дії.
Як це назвати?
Дуже важливо називати паттерни змістовно і послідовно. Один з плюсів паттернів у тому, що їх легко використовувати в дискусії просто посилаючись їхню назву. Для паттернів, що вже устоялись жодних подальших роз’яснень не потрібно. «Можливо, варто використовувати Action Bar в інтерфейсі?» чи «Як на рахунок списку швидких дій?» — речення, які говорять самі за себе.
Так як же називати цей паттерн? Я посилався на нього як «бокову навігацію» в цій статті, але ось багато інших варіантів:
- Side navigation;
- Fly-in app menu;
- Slide out navigation;
- Sliding navigation bar;
- Slide menu;
- …
Можемо почекати поки Google назве паттерн до того, як одна з назв приживеться сама собою. Демократія тут, скоріше за все, не допоможе. Поки що я буду називати його «боковою навігацією», але готовий прийняти і будь-яку іншу назву.
Технічні рішення
Бокова навігація (на момент написання статті) не входить в Android SDK. Швидкий пошук по github видає один проект, де задіяно цей паттерн: android-fb-like-slideout-navigation at github. Ось відео, яке демонструє його роботу.
Ось ще проекти:
- https://github.com/darvds/RibbonMenu
- https://bitbucket.org/jfeinstein10/slidingmenu/overview
- https://github.com/Gregadeaux/android-fly-in-app-navigation
Кайріл Моттьє також написав про впровадження цього паттерну в своєму блозі (англ.):
- The making of Prixing #1: Fly-in app menu
- The making of Prixing #2: Swiping the fly-in app menu
- The making of Prixing #3: Polishing the sliding app menu
Майбутнє
Я думаю, це великий крок в дизайні інтерфейсу Android. Ми повинні бути дуже обережними, щоб не створити некерований зоопарк різних способів впровадження, котрі будуть виглядати однаково, а вести себе по-різному, заплутуючи користувачів.
Google I|O не за горами (на момент написання статті в червні 2012). Ми, можливо, побачимо анонс наступної версії Android. Я маю надію, що Google продовжить просувати більш складні компоненти в свою ОС. Також маю надію на те, що ми побачимо компонент бокової навігації, як частину нового релізу, що вносить послідовність у використання цього паттерну.
Висновок
Я фанат концепції бокової навігації. Однак, дуже легко підійти до неї неправильно. Якщо ви вирішите включити її в свій додаток, будьте попереджені про можливі проблеми. Проектуйте уважно зворотній стек, жести, взаємодії з переходами вгору і те, як все це виглядає.
Першоджерело — «Emerging UI Pattern — Side Navigation».
Оновлення. Зверніть увагу на те, що «Бокова навігаційна панель може знизити залученість користувачів наполовину».
