Пользователь
0,0
рейтинг
19 февраля 2014 в 00:18

Разработка → 10 анти-паттернов навигации в Android перевод



В данной статье мы рассмотрим 10 анти-паттернов навигации в Android, которые допускают многие новички (и не только) в создании интерфейсов Android-приложений.







Мы встретили несколько приложений, в которых основная навигация (например: главный экран, магазин, мои заказы и т.д.) была размещена в action bar overflow. Это не самое лучшее место для такого типа навигации. Главная причина не использования overflow для основной навигации, это то, что сейчас многие приложения, которые прислушиваются к рекомендациям по созданию интерфейса пользователя не делают это. Для этой цели рекомендовано использовать navigation drawer или вкладки. Другая причина — старые устройства не имеют action bar overflow и чтобы открыть меню, требуется нажать на хардварную кнопку «меню».


В Android есть множество UI шаблонов навигации. Например, navigation drawer, action bar spinner и табы. Существует строгий порядок, в котором эти шаблоны должны использоваться. Взглянув на приложение можно сразу определить некую информационную иерархию, что-то вроде дерева. В корне — главный экран, второй уровень — категории, а в каждой категории могут быть подкатегории и т.д. И чтобы упорядочить эту информацию используются данные шаблоны. Неправильное их использование (например, вкладки для навигации верхнего уровня, action bar spinner для следующего уровня и navigation drawer для самого глубокого уровня) может запутать пользователя. Это неправильный вариант организации навигации:



Правильный вариант:



Navigation drawer всегда должен представлять самый верхний уровень, action bar spinner второй уровень и, наконец, вкладки должны быть на третьем уровне навигации. И если вы не используете action bar spinner и у вас есть только drawer и табы (как Google Play Music), то главная навигация должна осуществляться в navigation drawer и только потом во вкладках.


Вкладки в Android имеют свой определенный жест — свайп влево или вправо. Когда вы видите табы, вы должны быть уверены, что с помощью жестов горизонтальной прокрутки, вы сможете перемещаться между вкладками. В данном случае, если у нас есть постраничный контент, который листается с помощью горизонтальных свайпов, это создает конфликт жестов.



Чтобы исправить это, можно разделить контент на несколько экранов или поменять горизонтальную навигацию в вертикальную:



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


Во вкладках не должно быть слишком много навигации. Можно использовать такие вещи как изменение порядка сортировки элементов или прокрутку контента. Но настоятельно не рекомендуется использовать какую-либо иерархическую навигацию. Например, в данном примере когда вы выбираете один из элементов GridView, контент появляется прямо в текущей вкладке и при нажатии на кнопку «назад», снова появляется GridView.



Это пример навигации вглубь во вкладках. Первая причина это то, что для платформы это ненормальное поведение приложения. Вторая причина — неизвестно что произойдет, если перейти к другой вкладке. Предыдущая вкладка будет в неясном для пользователя состоянии. Также не определено действие, которое должно происходить по нажатию на кнопку «назад».

Еще один пример анти-паттерна — постоянные вкладки. Это такие табы, который предоставляют глобальную навигацию во всем приложении. Здесь также всплывает проблема неопределенного действия для кнопки «назад». И поэтому был создан navigation drawer, который позволяет сменить контекст.

Правильная версия примера:




Перемещение по вкладкам не должно сохранятся в истории действий. В нашем примере, при нажатии на кнопку «назад», происходит переход на предыдущую вкладку. Вместо этого следует перемещаться на предыдущий экран.




Похожий анти-паттерн и с navigation drawer. Хорошим примером правильного проектирования является приложение Google+. При переходе по пункту в navigation drawer, вы как бы открываете отдельное приложение. Поэтому, при открытии очередного пункта в navigation drawer, должен очищаться back stack задач и при нажатии на кнопку «назад», приложение должно закрываться. Или, если это будет не очевидно для пользователя, можно показать главный экран приложения.







Navigation drawer был создан для четкой и стабильной навигации между отдельными частями приложения. Вы должны избегать многоуровневые navigation drawer.

Но свертывающиеся подпункты вполне приемлемы:



Другое решение этой проблемы — при выборе пункта в navigation drawer, открывается экран с поднавигацией:




Здесь слово «переходы» означает как анимацию, так и сам переход между экранами. Например, если вы откроете navigation drawer и нажмете на пункт «Section 1», не должен открываться новый экран с кнопкой «назад» в action bar:



По правилам, каждый экран, присутствующий в navigation drawer должен содержать индикатор drawer'а. В примере используется кнопка «назад» вместо иконки navigation drawer. Правильный вариант:



Также немаловажна анимация появления экрана. Когда вы выбираете пункт в navigation drawer, не должно быть никакой анимации появления нового экрана. Нормальным поведением в данном случае будет «уезжание» navigation drawer и простое плавное увеличение прозрачности экрана.

Еще у разработчиков может возникнуть вопрос — что лучше использовать: разные активити или фрагменты для разделов в navigation drawer. На этот вопрос нет какого-либо абсолютно правильного ответа. Это сильно зависит от ситуации. Но в основном, решение исходит от того, насколько сложны различные части приложения.


По правилам, как уже было сказано выше, каждый экран, присутствующий в navigation drawer должен содержать индикатор drawer'а. В нашем примере, на определенном открытом экране с подробным контетом (на иллюстрации) не должно быть иконки navigation drawer.



Вместо этого требуется использовать кнопку переход в на предыдущий уровень приложения в action bar. Правильный вариант:







Последний анти-паттерн — использование правосторонней навигации. Категорически не рекомендуется использовать правостороннюю навигацию в своих приложениях. При использовании модели «заголовки-подробности», заголовки всегда должны быть справа, а подробная информация по пункту, должна быть слева, так как практически все мы читаем слева направо и только для языков, где письменность справа налево, можно сделать правостороннюю навигацию.

Правильный вариант:



Надеюсь данные анти-паттерны помогут вам лучше продумать навигацию и структуру приложения. Некоторые из них не всегда следует выполнять строго, поэтому сначала вы можете посмотреть на существующие приложения, чтобы реализовать понятные пользователям шаблоны пользовательского интерфейса.
Перевод: Join Nick Butcher and Roman Nurik
Николай @lukaville
карма
36,5
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (26)

  • +12
    Примеры из жизни (реальные приложения) были бы полезны
    • –1
      Talon for twitter.
      Отличный пример, по моему скромному мнению, правильной реализации навигации.
      К тому же отличный пример по использованию всех возможностей 4.4.
    • +3
      Собственно, Google Play (Play Маркет) — пример приложения, созданного в соответствии с UI гайдлайнами.
      • +2
        Google Play – отличный пример антипаттерна номер 6.
        • 0
          То же относится к клиенту ВКонтакте. При попытке выйти обратно в «Новости» из переписки, приложение раз десять откроет тебе окна переписки с другими собеседниками или даже с тем же самым, только проскроллив историю сообщений повыше.
          • +2
            ВКонтакте — это вообще кладезь. При выходе из той же переписки Up сработает как Back и покажет сперва каждый твой активный чат, прежде чем откроет-таки список чатов. Фантомные пропадания приложения из Recents тоже доставляют часто — нажал Back, приложение закрылось, в backstack'е нет — до свидания.
        • 0
          А Chrome – номера 3.
  • +8
    Статья хорошая, но вы бы её кинули в хаб Разработка под Android. Там ей самое место
  • 0
    Спасибо, чертовски полезный пост, также реквестую живые примеры.
  • +3
    Можете, пожалуйста, подробнее описать последний пункт? Не уверен что понимаю о чём там речь.
    • +1
      Видимо, имеется в виду, что на экране все навигационные элементы (navigation drawer, fragment с менюхами и т.п.) должны размещаться по возможности слева.
      Мне представляется картинка с планшета, где меню постоянно на экране и находится справа от контента (прилепленным к правому краю экрана). Выглядит и правда не очень удобно.
    • 0
      Например, меню настроек на планшете — слева категории, справа — содержимое выбранной категории.
      Аналогично в почтовом клиенте: заголовки писем слева, содержимое — справа.

      Очевидно, про это речь.
    • 0
      Добавил иллюстрации. Это в основном касается различных планшетных устройств.
    • 0
      The drawer view (the ListView) must specify its horizontal gravity with the android:layout_gravity attribute. To support right-to-left (RTL) languages, specify the value with «start» instead of «left» (so the drawer appears on the right when the layout is RTL).

      Получается, что практике просто используем layout_gravity — «start» и Android сам, в зависимости от текущей локали будет показывать navigation drawer слева или справа. Для большинства языков предпочтительнее иметь navigation drawer слева (из-за направления чтения).
  • +1
    Пора заводить отдельный раздел переводов презентаций Романа Нурика и Ко Android Design in Action
  • 0
    Большое спасибо за статью, очень удобно и наглядно.
  • +1
    Советы хорошие, хотелось бы только надеяться, что она не потеряет актуальности, скажем, за год. А то гуглы горазды выдумать ещё какой-нибудь навигационный элемент и снова переделать все свои приложения.
  • +1
    главная навигация должна осуществляться в navigation drawer и только потом во вкладках

    Ага, на картинке-то все круто. Вот только Navigation Drawer нельзя сделать над вкладками. И Roman Nurik говорит: «You shouldn't use navigation drawers with action bar tabs. If you're aiming for a UI similar to that of Google Play Music, you should implement tabs manually». Вот почему поведение стандартных компонентов так запутывает (знаю, что вопрос риторический)?
  • 0
    Последнее время начал встречать все больше приложений, построенных аккурат по принципу номер 1. Точнее, против принципа — зачем-то в это меню выносится все и вся.

    Меню же настолько далеко от большого пальца руки, который держишь телефон (я правша, и телефон чаще держу левой), а любой экран нынче велик изрядно — так что тыкнуть в кнопку вызова меню можно только второй рукой. Что, конечно, fail юзабилити.

    Так что, ваш бы список да разрабам в уши! Точнее, перед глазами иметь всегда, и — думать над ним!

    P.S. Кстати, по пункту 3 добавлю — иные особо одаренные производители устройств настраивают тач-сенсор так, что попытка проскролить (просвайпать) экран вправо-влево нередко приводит к выбору элемента, поверх которого свайпаешь. Так что дизайнеру нужно либо оставить область, где свайп гарантированно сработает как свайп, либо уже программисту обрабатывать такие косяки производителей на программном уровне.
    • 0
      Я не думаю, что тут есть проблема с «дотягиванием» до меню действий — ведь на последних трубках с большим экраном, держа её в правой ладони, всё-равно верхняя половина экрана остаётся недоступной.

      Кроме того, навигация находится в верхней части, до которой «одной рукой» не дотянешься — кнопка Up, спиннер или табы. Поэтому вряд ли с этим есть проблема.

      • +1
        Во-первых, я его в левой руке держу, во-вторых, «меню из правого вернего угла» в приличных программах заменяется «меню из нижнего левого угла» — эта тадиция идет давно, удобна для рук (для левой тем более). Правый верхний угол — это, на мой взгляд, вообще ляп UI-дизайнеров гайдлайна, в это меню можно вынести суперредкие действия, вроде «удалить все данные приложения».
        • 0
          Здесь сильно от способа взаимодействия с устройством зависит.
          Если (для правши) держать в левой ладони, а пальцами правой руки — общаться с девайсом, проблема вряд ли будет иметь место.

          Правый верхний угол — это место, куда обычно смотрят в первую очередь, так что положить список того, что можно сделать прямо сейчас, наверное, логичен.
          Кроме того, наиболее частые действия показываются иконками на action-bar, за ними в выпадающий список и ходить не надо.

          Реализация «меню из нижнего левого угла» имела место с выделенной кнопкой «Меню» по факту.

          Что же касается планшетов, то там про работу одной рукой говорить вообще не приходится — если не использовать его, планшет, в качестве веера.
  • +2
    Вообще-то это не статья, а набор переведенных слайдов с комментариями с вчерашнего шоу Android Design In Action
    Интересующимся советую посмотреть предыдущие выпуски
  • +8
    Круть. Еще бы пальцы отбить дизайнерам интерфейсов, которые так не делают. С 2009 года борюсь с кальками на айфон с глобальными табами, функциями кнопки back и т.п.

    Зачем вам новый дизайн? Просто сделайте как на айфоне!
    • +4
      Цены нет твоим словам!
  • 0
    В мемориз!

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.