На сьогоднішній день ми маємо інформацію, що бічні меню - так звані "гамбургерні" меню - ймовірно приносять більше шкоди, ніж користі.
Ось кілька статей на цю тему:
Майте на увазі, що в цьому питанні багато нюансів. Я спостерігав позначені в цій статті проблеми в ході призначених для користувача тестувань, а хтось відчував їх на практиці.
Я просто прошу вас вивчити проблеми і рішення, щоб, віддаючи перевагу цьому паттерну, ви були в курсі всіх можливих наслідків.
Проблеми гамбургерні меню:
- низька виявленню
- Мала ефективність
- Конфлікт з навігаційними паттернами платформи
- Малозрозумілою з першого погляду
низька виявленню
"З очей геть з серця геть"
За замовчуванням бічне меню і весь його вміст приховані.
Тобто люди спочатку повинні виявити, що під кнопкою-гамбургером ховаються якісь функції. Іноді компанії додають до цієї кнопки напис або зринаючі підказки "меню". Це природно і навіть необхідно - адже людина не буде шукати приховані можливості, якщо основні функції вже представлені на головному екрані.
Мала ефективність
Навіть якщо люди знають і люблять цю функцію, факт залишається фактом: такої патерн порушує плавність навігації, змушуючи користувача спочатку відкрити меню і тільки отримати доступ до цікавить його функції.
Нижче ви бачите яскравий приклад того, наскільки миттєвої може бути навігація, коли всі навігаційні елементи розташовані на увазі.
Конфлікт з навігаційними паттернами платформи
Однак найважливішою проблемою є те, що на деяких платформах (на кшталт iOS) не вийде реалізувати гамбургерні меню без конфлікту зі стандартним патерном навігації.
Найлівіша кнопка навігаційної панелі відводиться під гамбургерні меню, але нам потрібно дати користувачеві можливість повернутися назад. Дизайнери або перевантажують панель навігації як показано вище - не залишаючи місця навіть для заголовка сторінки, або змушують користувачів пробиратися через кілька екранів, щоб відкрити меню:
Малозрозумілою з першого погляду
Вам буде складніше надати користувачеві інформацію про конкретний елемент, якщо він буде видно, тільки коли користувач відкриває меню в пошуках іншого елемента.
Можна зробити як в додатку Jawbone Up: показувати іконку, яка відображатиме суть повідомлення поруч з кнопкою бічного меню.
Цей підхід не дуже добре масштабується, так як пов'язаний зі створенням великої кількості спеціальних іконок, а вам, як дизайнеру, іноді доведеться користуватися стандартними іконками, що несуть в собі менше сенсу.
А ось протилежний приклад - панель вкладок Твіттера, яка показує користувачеві контекст повідомлення і дає можливість відразу перейти на відповідний екран.
усвідомлення проблеми
Може здатися, що ви зобов'язані робити все це, щоб заощадити побільше екранного простору, але ми часто неправильно розуміємо, що люди бачать насправді. Вам може здаватися, що люди бачать все, що у них перед очима, а на ділі у нас у всіх є якась зона концентрації, навіть якщо розмір екрану мінімальний (1).
Тому питання економії екранного простору може бути вирішене без нанесення шкоди навігації - і відповідно до базовими принципами HCI (людино-комп'ютерного взаємодії), які вимагають від нас надання зворотного зв'язку і відображення стану програми.
На замітку: можливо вам потрібно освіжити своє розуміння принципів HCI - я майже впевнений, що це допоможе уникнути безлічі дизайнерських помилок, які роблять люди з візуальним підходом до дизайну.
Ми багато говорили про проблему, але рішення досі не ясно.
Коли можна використовувати гамбургерні меню?
У деяких дуже рідкісних випадках цей патерн дійсно виправданий, але в загальному і цілому варто уникати його використання.
IRCCloud - приклад виправданого (в якійсь мірі) використання кнопки-гамбургера: з її допомогою здійснюється навігація між каналами і учасниками каналів.
Це прийнятно, так як у основного екрану немає ніяких дочірніх екранів, яким потрібна ієрархічна навігація; весь вміст представлено в модальному вигляді.
Але навіть в цьому випадку видно, що інтерфейс перевантажений, а інформаційна архітектура потребує перегляду.
Це плавно підводить нас до наступного розділу статті:
Чим замінити кнопку-гамбургер?
Патерн бокового меню тягне за собою погану інформаційну архітектуру: кнопка-гамбургер є ще один елемент інтерфейсу, в якому не проглядається жодна послідовність дій - до тих пір, поки люди їм не скористаються.
"Рішення - в оновленні інформаційної архітектури".
На малюнках вище наведений приклад того, як можна уникнути бокового меню. Кольорові точки допоможуть вам відстежити, як були реорганізовані елементи інтерфейсу.
- Стан представлено на вкладці Повідомлення
- Елементи інтерфейсу завжди видно і доступно
- Немає конфлікту між жестами навігації
На додаток до того, що ми вирішили основні проблеми, ми можемо виграти трохи вертикального простору, якщо сховаємо панель навігації програми при скролінгу вниз (див. Приклад Facebook, але це також використовується і в Safari). Картотека залишається на своєму місці, що дозволяє нам користуватися навігацією, навіть коли панель навігації програми захована.
Якщо у вас мінімалістське настрій, можливо, буде достатньо і панелі інструментів. Суть в тому, щоб винести на чільне місце навігацію, дати прямий доступ до функцій, уникнути конфлікту між жестами навігації і відобразити оповіщення на тих іконах, до яких вони належать.
[Оновлення] У випадку з веб-сайтами, вам також варто переглянути інформаційну архітектуру, але замість використання цих iOS-патернів рекомендую відображати навігацію зверху, у вигляді списку: приклад. Якщо буде очевидно, що це навігація сайту, люди обов'язково проскролят далі і відразу побачать всі інші доступні варіанти.
Крім того, повертаючись до теми веб-сайтів на мобільних пристроях: не забудьте прибрати 300-мілісекундную затримку натискання за допомогою цих рад або з використанням сенсорних подій.
Як це все масштабується?
Я тут наводжу приклади iOS інтерфейсів - кращим рішенням на них є використання панелі з вкладками або інструментами.
Але що, якщо на вашій панелі вкладок більше 5 елементів?
У таких ситуаціях перше, що вам потрібно зробити, - це все-таки переглянути інформаційну архітектуру програми. Але якщо все-таки доводиться вийти за межі п'яти вкладок, зазвичай застосовується такий метод: остання вкладка дає доступ до списку залишилися опцій.
Можете також реалізувати прокручуємо панель інструментів, як у Rookie. Це дозволить вам уникнути проблем гамбургерні меню ціною трохи більше високої складності навігації з більшою ймовірністю помилки (в силу того, що з додатком доведеться розрізняти натискання і прокручування інструментів).
Майте на увазі, що друге рішення більше підходить для списку дій, ніж для елементів навігації.
Така реалізація стикається іншою проблемою: після прокрутки панель інструментів залишається в невизначеному стані. Rookie ховають панель після того, як користувач вибирає одну з дій - обрізати, повернути і т.п. Таким чином, невизначений стан панелі "обнуляється", і при повторному відкритті вона відображається в первісному стані.
висновок
Отже, ви прочитали статтю про проблеми паттерна бічній панелі і про їх вирішенні в рамках iOS, які були закладені в систему з самого початку.
[Оновлення] Тематичний за цією статтею був неймовірним! Більше 24 тисяч читачів і, що ще важливіше, класні обговорення в Твіттері. Я зробив добірку кльових твітів на Storify. Здається, що тема гамбургерні меню залишається відкритою в контексті Андроїда, а особливо в частині навігаційних патернів для Веб.
Інші статті та твіти на цю тему:
- Hamburgers Basements: Why not to use left nav flyouts
- An update on the hamburger menu
- Basement Menus and Breaking the "Rules" of App Design
- Pagebreak Snippet # 150: Why and How to avoid Hamburger Menu
- Who Designed the Hamburger Icon?