Новый паттерн UI — боковая навигация

Original author: Juhani Lehtimaki
  • Translation
Занимаюсь редизайном приложения 10tracks для Android, и решил позаимствовать красивый интерфейсный ход старших братьев — Facebook и других. На эту тему нашлась хорошая статья, переводом которой спешу поделиться с вами. Между тем эта статья — больше платформа для дискуссии, чем нерушимые устоявишеся правила.


За последний год интерфейс Android улучшался с феноменальной скоростью (я подобрал небольшую галерею приложений, которые мне нравятся в Google+). Много изменений являлись лишь косметическими (тема Holo в ICS, шрифт Roboto, и т.д.). Мы не увидели больших качественных изменений в принципах проектирования интерфейсов. Но, возможно, как раз сейчас происходит одно такое.

Почти одновременно несколько приложений внедрили у себя боковую навигацию как в приложении Facebook. Сначала мы увидели, как она используется в новом дизайне Spotify, а затем почти сразу решение переняли Evernote. Не прошло и года, в новом дизайне приложения Google+ представили аналогичный паттерн.

Реализована боковая навигация в каждом из этих приложений по разному. Она по-разному выглядит, ощущения от использования её разные, хотя фундаментально подход один и тот же. Идея в том, чтобы предоставить пользователю быстрейший способ добраться до важнейших областей приложения без необходимости покидать текущий экран.

Визуальные отличия в реализациях очевидны. Например, в приложении Google+ меню выезжает поверх текущего экрана, а в других приложениях текущий экран сдвигается в сторону. Google+ использует иконку перехода вверх, а Action Bar остается на месте, даже если меню открыто, в то время как в других приложениях — нет.

Интересную дискуссию, которая состоялась не так давно об этом паттерне можно почитать в блоге автора Google+. Ссылка на дискуссию (англ.)



Dashboard мертв


Боковая навигация заменяет много критикуемый 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), чтобы открыть меню. Пользователь не обязательно найдет что этот жест приводит к открытию бокового меню, но это не проблема, так как есть домашняя кнопка, открывающая его. (Статья автора на английском про 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 продолжит продвигать более сложные компоненты в свою ОС (как они сделали с Action Bar в ICS / Honeycomb). Я также надеюсь, что мы увидим компонент боковой навигации как часть нового релиза, вносящий последовательность в применении этого паттерна.

Заключение


Я фанат концепции боковой навигации. Однако, очень легко подойти к ней не правильно. Если Вы решите включить её в свое приложение, будьте осведомлены о возможных проблемах. Проектируйте обратный стек, жесты и взаимодействия с переходами вверх и то, как это выглядит внимательно.
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 40

    +15
    а ведь многим очень ненравились такие «обрезанные» экраны windows phone. А сейчас получается, что MS создала «тренд»?
      –2
      При чем тут обрезанные?
      Фейсбук создал тренд и ничего обещнго с обрезками в винфо он не имеет
        +5
        facebook в очередной раз удачно попал в волну.
          +1
          Точно ничего общего?
          image
            +16
            А вы вообще статью читали?
            Или действительно не видите разницы между цепочкой связанных экранов в винфо и раздельными самостоятельными экранами с боковым глобальным меню, вызываемым кнопкой или жестом, описанным в статье?
              –4
              ну я не вижу разницы
                +12
                Без разницы как оно называется и как оно работает. Главное как оно выглядит и какие «ощущения» производит. Выглядит оно «разделённым» экраном. Ощущения производит «подвинь (дотронься до) меня и я откроюсь». Одинаково.
                Большинству нелюбителей WinPhone резала глаза именно эта «разделённость» экрана. «Нахрена мне обрезанные буквы».
                  0
                  Мне до сих пор не нравятся обрезанные буквы и экраны. На самом деле как я понимаю это GooglePlay аналог в Android. Несомненно идея похоже из Метро, двигать «плоские» экраны влево/вправо, но вот обрезанные буквы просто съедают часть экрана и выглядят ужасно. Непонятно как это выглядит если на экране карта, которую изначально можно двигать в 4х направлениях…
                    0
                    Ну, карту просто выносят на отдельную страницу. Двигающиеся экраны в WP — это специальный контролы, которые никто не обязан пихать куда попало.
                    0
                    Визуально идеи похожи, но ощущения от использования разные. Если бы WP добавили границу разделитель между экранами и сделали их наползающими друг на друга — они были бы в тренде. :) А так близко, но мимо.
                      0
                      Эх. Ну как вы не понимаете… Разница заключается в контексте использования. Ощущение «дотронься до меня и я откроюсь» на основном экране и в меню — две большие разницы. В первом случае — это нервы и ощущение нестабильности ситуации.
                      +2
                      Поддержу Terion, что этот тренд/паттерн отличается от направления UI windows phone. Лучше ассоциация — status bar в Android.
                      0
                      Чтобы понять разницу, стоит открыть небольшое демо на сайте Sparrow и покликать на экране воображаемого iPhone (в Opera не работает). Разница с Windows Phone очевидна.
                      +1
                      А когда в FB появился этот патерн?

                      Пока читал статью, вспомнил что в старой версии мобильного FF было похожее, но как выглядело на тот момент приложение FB не припомню
                      +6
                      все уже отвыкли что МС создаёт тренды, типа неповоротливый монстр. Нет, есть ещё порох в пороховницах.
                      +6
                      Наилучшая реализация этой концепции, которую я видел — в iOS Sparrow. Там вообще идеальный тач-интерфейс, как мне кажется
                        +8
                        Этот паттерн называется off canvas и относится не только к андроиду. Люк Вроблевски очень хорошо про него пишет, а Джейсон Вивер приводит интересный вариант реализации для веба.
                          –3
                          не всегда удобно это, хочешь экран пальцем протереть, а оно тебя кудато переключает, особенно в браузерах некоторых это заменяет кнопки навигации вперед\назад
                            +6
                            Блокировка!
                            с ув. ваш К.О.
                              –5
                              ну да, так гораздо удобнее, тянуться до кнопки чтобы заблокировать экран, протирать его, потом опять до кнопки чтобы разблокировать его
                              +4
                              Очень вас понимаю.
                              Захочешь, бывает, протереть клавиатуру на нотубуке, ну или почесать этой клавиатурой затылок (благо ноут лёгкий), а он возьми, да фигню какую-то при этом делает. Непорядок!
                                0
                                вам квм поможет, переключаешся на свободный порт и делаешь с ней что угодно!
                                  0
                                  вернее это вариант для пк
                              +1
                              Информация о Google+-клиенте немного устарела — теперь там список не выпадающий, а так же выезжающий слева.
                                –1
                                Клиент Steam на iOS один из самых лучших примеров я считаю.
                                  +2
                                  Фреймворк для построения мобильных веб-приложений LungoJS уже давно использует такой вид навигации. И да, чаще всего это удобнее дашборда.
                                    0
                                    Какой интересный фреймворк… Спасибо за ссылку)
                                    +1
                                    Этот паттерн спасает, когда дизайнер не может совладать с контентом. Помогает избежать перекрестных переходов между таббарах из нижних слоев навигации и т.п. В общем, для соцсетей — самое то, когда от со страницы друга попадаешь на еще друга, а потом к себе, при чем у тебя уже стек вьюшек в штук 10 «за спиной» и возвращаться кнопкой «Back» долго.
                                      +2
                                      Больше всего понравилась реализация github.com/jfeinstein10/SlidingMenu
                                        0
                                        Выглядит уродски — рассеивает внимание, показывает обрезанный контент, еще и в другом стиле и цветовой гамме.
                                        Это как в раме картины оставлять справа немного места для списка других картин, биографии автора и покупки пиццы.
                                          +6
                                          У меня складывается стойкое впечатление, что комментаторы выше не прочитали ни строчки из статьи, а только посмотрели картинки и давай флудить не по теме
                                            0
                                            Я вот чего не понял: какая пренципиальная разница между такой панелькой и дашбордом? Да, в панельке пользователь как бы не покидает экран где он находится, но на практике панель закрывает (или сдвигает) большую его часть, не давая больше с ним взаимодействовать. Возможн я ошибаюсь, но кроме более понятного поведения кнопки «обратно» (закрыть панель) она по сути мало чем отличается от дашборда, кроме оформления. Или есть что-то еще?
                                              +1
                                              Всё очень просто: используя дашборд, вы можете углубляться в экраны приложения, но потом будете вынуждены возвращаться обратно. Например: Дашборд → Новости → Конкретные новости → Открываете ссылку во встроенном в приложение браузере. Что вам нужно сделать теперь, чтобы попасть в другую часть приложения, например, группу? Правильно, 3 раза жмёте «назад».

                                              А с панелькой всё просто: где бы вы ни были, смело жмите кнопку, и вся структура приложения у вас перед глазами. Передумали? Нажмите кнопку ещё раз и вернётесь обратно.

                                              С дашбордом сложнее. Предположим, у вас есть кнопка, которая есть везде и доставляет вас к дашборду. Вот вы нажали на неё, но передумали и хотите продолжить просмотр новости. При нажатии на кнопку «новости» непонятно куда вы попадёте: или на ленту, или на сохранённое место, откуда вышли. И ладно, если у вас андроид — там есть кнопка «назад», но есть ещё и iOS.

                                              Вот и вся разница, которую автор осветил соответствующими изображениями в статье.
                                                0
                                                в iOS дашборд паттерн почти не применяют, стандартное решение: тулбар в котором последнюю кнопку можно сделать "… Еще" при нажатии на которую выйдет список с доп. функциями (какие-то функции перенести на тулбар) + тулбар можно сделать скрываемым в дочерних окнах + навигейшен контроллер (стек окон с кнопкой назад) в главных окнах — по функциям делают все то же что и боковая навигация. Пример — стандартное приложение Музыка.
                                                +1
                                                Прочтите статью, поймете что еще.
                                                +1
                                                Почему-то мне кажется, что большинство юзеров держат телефон в правой руке. Было бы логично выдвигать меню справа, и сами пункты меню рисовать снизу вверх.
                                                  0
                                                  EnyoJS предлагает более интересный подход.
                                                    0
                                                    Эх, а я вот сам с нуля писал такую штуку, тогда библиотек ещё не было :)
                                                      +1
                                                      А мы отказались от боковой навигации в своем приложении.
                                                      Поначалу этот паттерн тоже показался оригинальным, но при его внедрении выяснился ряд нюансов. По сути каждый экран должен состоять из 2 фремов, собственно фрейма текущего экрана и фрейма меню. В результате код становится довольно перегруженным и видимо по этой причине боковую панель реализую как правило только на основных, домашних экранах, на которые еще нужно вернуться с дополнительных экранов бэком. Например посмотрите тот же фейсбук или вконтакте, у дочерних окон нет бокового меню. В результате мы решили немного переработать паттерн бокового меню на паттерн всплывающего в попапе меню.

                                                      Плюс в том, что на все экраны добавлена кнопка меню справа и при клике меню открывается в попапе. В итоге это пара строк кода в каждом экране, примерно так:

                                                      actionBar.addAction(new MenuAction());

                                                      private class MenuAction extends AbstractAction {

                                                      public MenuAction() {
                                                      super(R.drawable.menu_icon);
                                                      }

                                                      Override
                                                      public void performAction(View view) {
                                                      final PopupAction quickAction = new PopupAction(BuyActivity.this,app,false);
                                                      quickAction.show(view);
                                                      quickAction.setAnimStyle(PopupAction.ANIM_GROW_FROM_RIGHT);
                                                      }
                                                      }

                                                      Можно было и их вынести, но в приложении есть несколько окон без меню (всего в приложении около 20 экранов)

                                                      Само всплывающее меню для пользователя выглядит примерно так:
                                                      image
                                                      Причем меню разное для зарегистрированных и незарегистрированных пользователей. Ну в общем лучше 1 раз посмотреть в деле чем полчаса читать описание: play.google.com/store/apps/details?id=com.imobilco.bigbuzzy
                                                        0
                                                        Override доставил:)

                                                      Only users with full accounts can post comments. Log in, please.