Источник: habrahabr
kichik
В предыдущей части мы рассмотрели три первых шага на пути проектирования приложения:
- Определение целевой аудитории
- Формулировка цели приложения
- Отбор ключевых сценариев
Как вы могли заметить, первые три шага действительно можно смело применять к любым проектам,
я думаю, они от этого только выиграют. В этой части мы рассмотрим четвертый шаг - планирование навигации в приложении, и на этот раз нам никак не обойтись без понимания специфики Windows 8.
4. Спланируйте навигацию
Вы, наверное, если прочитали целиком первую часть статьи, удивлены, что мы все еще не нарисовали ни одного экрана и ни разу не взглянули в сторону конкретной реализации чего бы то ни было. Не удивляйтесь - в этой статье мы не будем рисовать в деталях экраны и тем более не будем писать код. Тем не менее все, что мы проделаем в последующих двух шагах будет играть крайне важную роль для всего дальнейшего проектирования интерфейса и непосредственно разработки приложения.
Конечной целью четвертого шага является формирование понимания относительного того, какие экраны будут в вашем приложении, как по ним будет распределена информация и как будут осуществляться переходы между ними. Нам нужно сделать информационную карту (она же информационная архитектура).
В принципе, если у вас уже есть 1) достаточно четкое представление того, как должно выглядеть приложение, и 2) понимание того, как работает Windows 8, вы можете нарисовать схему сразу: нужно нарисовать все ключевые экраны, показать, как между ними распределяется информация и обозначить переходы между экранами, привязав их к триггерам перехода (элементы, кнопки, ссылки, жесты и т.п.).
Мы же пойдем с двух сторон: попробуем понять, какие экраны нужны для нашего виртуального приложения, чтобы покрыть ключевые сценарии, и я расскажу, на что нужно обратить внимание с точки зрения проектирования приложений конкретно для Windows 8.
Экраны приложения
Начнем с экранов - и тут могут быть разные стратегии. Например, можно сразу пытаться нарисовать информационную схему, начиная с самого главного экрана и постепенно погружаясь в детали. Этот подход, в принципе, может сработать, если у вас уже выработалось общее представление о том, как должно выглядеть приложение - и, прежде всего, какие информационные блоки в нем будут и как с ними должно взаимодействовать. Я думаю, что для этого у вас также должен быть некоторый опыт проектирования.
Для незнакомых задач, прежде чем складывать весь пазл в единую картинку, можно начать с отдельных кусков/фрагментов. Это в чем-то действительно напоминает складывание пазла (мозаики): из отдельных небольших кусочков вы сначала складываете отдельные фрагменты, а потом сводите эти фрагменты в единую картину.
Чтобы начать эту работу, нужно вернуться к своим историям - и постараться их зафиксировать в упрощенном и последовательном виде в соответствии с различными сценариями.
Пример. Продолжаем разбираться с Movie Meeting - мою историю кратко можно записать так:
- Я: увидел постер → узнал фильм
- Я: создать встречу
- Отправить приглашения
- Сделать видимым интерес
- Друзья: получили приглашения → детали
- Друзья: получили напоминания → детали
- Я: вижу статус, детали, заказываю еду
- Я+друзья: наслаждаемся фильмом с расширенным вовлечением
Здесь первые два пункта относятся к первому сценарию, вторые два ко второму, пятый - к вторичному заказа еды, шестой пункт записываем на счет третьего сценария.
Теперь можно постараться перевести эти истории в отдельные небольшие схемы - экраны, на которых необходимо обозначить основные блоки информации, важные для принятия решений или удовлетворения пользователя, и переходы между экранами, отражающие последовательность перемещения (поток приложения):
Буквой "A" я обозначил возникшее ощущение, что на этих экранах могут потребоваться дополнительные явные действия со стороны пользователя (actions).
В предположении, что ваши истории по-разному раскрывают ключевые сценарии, вы можете получить различные наборы мини-схем, более полно раскрывающие суть вашего приложения.
Теперь, чтобы двигаться дальше, нам необходимо прояснить несколько важных нюансов относительно шаблонов навигации в Windows 8. Ключевая статья на тему навигации -Проектирование навигации для приложений в стиле Metro. Я отмечу несколько важных моментов и несколько дополнительных нюансов, которые также стоит иметь в виду.
Навигация в Windows 8.
Прежде всего, надо сказать (и подчеркнуть), что в основе проектирования навигации также должна лежать жесткая приоритизация. Надо любыми путями бороться с навязчивым желанием разместить на одном экране как можно больше информации, действий, ссылок и т.п.
В этом смысле мне очень нравится следующая цитата из статьи Susan Weinschenk "The Psychologist"s View of UX Design":
"People will do the least amount of work possible to get a task done. It is better to show people a little bit of information and let them choose if they want more details. The fancy term for this is progressive disclosure."
Выносите наверх и в самое доступное место только то, что действительно необходимо - и позвольте пользователю при необходимости легко погрузиться в детали. Вместе с этим старайтесь показывать пользователю, где он находится, а не куда ему стоит пойти (эту мысль я еще поясню, но если вы ее сразу схватили - вы на верном пути).
В приложениях для Windows 8 есть два ключевых шаблона навигации: иерархический и плоский. (В принципе, отдельным типом можно рассматривать вариант Master-Details, используемый, например, в приложении "Почта", однако, этот вопрос мы оставим за рамками данной статьи.)
Иерархическая модель навигации предполагает, что пользователь на каждом шаге видит некоторый срез информации с некоторой степенью детализации и, если необходимо, может последовательно погружаться в детали.
Например, в новостном приложении на первом уровне я вижу самые свежие и главные новости - заголовками и картинками, разбитые по отдельным группам. Если мне не достаточно только последних 5-10 новостей и я хочу узнать все последние новости про политику, я могу перейти в соответствующий раздел (на второй уровень) - и увидеть там список всех политических новостей. Если мне не достаточно заголовка и картинки, чтобы понять, что происходит, и какая-то новость меня зацепила, я могу спуститься на третий уровень (с первого или второго) - и прочитать всю новость целиком.
Тот факт, что я на каждом уровне уже получаю некоторую порцию информации, как раз и соответствует идее показать, где я есть, а не куда я могу пойти. Здесь также важно отметить, что погружение на уровень ниже осуществляется непосредственно через контент.
В конкретном приложении уровней может быть и больше чем три, но всегда важно помнить о приоритизации. Вы можете думать об этом так, что на каждый следующий уровень в глубину нужно в два раза больше весомых причин его наличия. (Однако нужно также и удерживать себя от стремления разместить вообще всю информацию на одном первом экране.)
Для возврата по стеку навигации рядом с заголовком может располагаться стрелка "назад". Также для быстрого перехода в соседние разделы и на главную страницу приложения можно использовать меню заголовка (выпадающий список 5 на картинке ниже).
Иерархическая модель навигации хорошо подходит для больших коллекций контента и множества секций или категорий.
Плоская модель навигации для перехода между различными экранами использует специальный интерфейсный элемент - панель навигации (navigation bar), которая появляется сверху при соответствующем жесте пальцами, либо нажатии правой кнопки мыши, либо по команде с клавиатуры (Win + Z):
Обратите внимание на то, что этот элемент не является постоянно присутствующим на экране и вызывается только по запросу пользователя.
Панель навигации хорошо подходит, если вам нужно переключаться между множеством вкладок (например, в браузере), диалогами IM, документами, игровыми сессиями и т.п., а также для быстрого доступа в небольшое количество специальных разделов.
В конкретном приложении обе модели могут сочетаться и использоваться одновременно. Например, в приложении Bing News иерархическая модель используется для погружения в отдельные разделы новостей и конкретные новости, а плоская - для быстрого переключения между общим потоком, отобранными новостями и управлением источниками новостей.
Контекстное масштабирование (semantic zoom). В приложениях для Windows 8 есть еще одна особенность, связанная с основным способом расположения информации (горизонтальным с горизонтальной же прокруткой). Как только ваша информация выходит за пределы экрана, вы столкнетесь с необходимостью 1) подсказать пользователю, что там находится дальше, и 2) помочь быстро перейти в нужную секцию контента.
Для решения обеих этих задач используется специальный прием, который называется контекстным масштабированием, срабатывающим при сжатии пальцами, ctrl + скролл мышкой, ctrl + "+" или нажатии на специальную кнопку, если ее предоставил разработчик:
В таком режиме становятся видными сразу (или почти сразу) все секции - и пользователь может легко выбрать нужную. Хорошим приемом считается отображение не просто заголовков секций, но и какой-то полезной мета-информации.
Важно отметить, что контекстное масштабирование не меняет контекста и не осуществляет перехода на другие страницы - оно только помогает быстро разобраться с текущей страницей. При этом этот прием может использовать на любой странице в приложении, если это имеет смысл:
Пивоты (pivots), возможно, знакомые вам по Windows Phone, также могут иметь место в приложениях для Windows 8. Например, вы легко встретите их в Windows Store, перейдя к тому или иному приложению:
Вы можете воспринимать это решение как "интерфейс с табами", но хочу подчеркнуть, что основное предназначение его такое же, как и в Windows Phone: переключение между разными фильтрами либо срезами (группами) информации о каком-то объекте. Например, в случае магазина приложений это переключение между обзором, деталями и отзывами по конкретному (одному) приложению.
Чудо-кнопки и контракты (прежде всего, это search, share и settings) являются также важной составляющей вашего приложения, которая берет на себя часть функциональности, или, точнее, ее активацию.
Чудо-кнопки располагаются на специальной панели, выдвигающейся справа, и представляют собой единообразное решение для четырех типовых задач: поиск в приложении, расшаривание (передача) информации с другими приложениями, взаимодействие с внешними устройствами (например, вывод на второй экран или печать) и вызов настроек.
С точки зрения информационной архитектуры, это означает, что, к примеру, вызов настроек приложения будет инициализироваться не какой-то ссылкой или кнопкой внутри приложения, а нажатием на соответствующую чудо-кнопку. Это легко изобразить, но просто нужно помнить, что это должно работать именно так.
Поиск и расшаривание (общий доступ) играют еще одну важную роль, о которой вам нужно помнить: они могут быть активаторами вашего приложения. Например, если вы показываете пользователю новости, он может зайти в ваше приложение как с плитки на стартовом экране (или выбрав приложение в списке приложений), так и напрямую вбив поисковый запрос в панели поиска и выбрав ваше приложение. В этом случае откроется (должна открыться) сразу страница результатов поиска из вашего приложения. Аналогичный сценарий работает и для передачи данных, если ваше приложение может их принимать.
(В принципе, могут быть и другие активаторы, о которых вам имеет смысл знать - смотрите раздел про контракты на MSDN, но это выходит за рамки настоящей статьи).
Плитки и оповещения, как вы легко могли уже догадаться также могут быть дополнительными точками входа в приложение и в целом частью решения задачи информирования пользователя о текущем состоянии тех или иных сущностей вашего приложения. Я не буду на этом специально останавливаться, однако, не забудьте про это при проектировании.
Еще одна важная вещь, которая может влиять на структуру навигации, но требует отдельного рассмотрения, - это режим прикрепления (snapped mode), в котором ваше приложение закрепляется параллельно с другим приложением в виде узкой полоски справа или слева. В этом случае вам нужно перепроектировать экраны и навигацию (возможно, вставив дополнительные промежуточные экраны) с учетом меньшего доступного пространства и преимущественно вертикальной прокрутки - активно вспоминаем про необходимость расставления жестких приоритетов.
На этом наше краткое погружение в элементы системы навигации в приложениях для Windows 8 закончено и мы можем вернуться к основной задаче проектирования информационной архитектуры нашего виртуального приложения.
Пример. Напомню, мы рассматриваем некоторое приложение Movie Meeting, которое помогает организовать совместный с друзьями просмотр интересного кино и у него есть три ключевых сценария:
- Найти интересный фильм для просмотра
- Договориться о совместном просмотре с друзьями
- Получить массу впечатлений от просмотра
На этапе фиксации мини-схем мы должны были получить первичное представление о том, как работают данные сценарии (последовательность действий/экранов) и необходимые для них блоки информации.
(Проектировщики с обстоятельным подходом могут смело также зафиксировать подробные пользовательские сценарии в любом привычном виде.)
Изучая природу и время жизни всех этих сценариев, мы можем понять, что все они накладываются друг на друга, организуя некоторую пирамиду:
- "Просмотр фильма" важен накануне и во время просмотра.
- "Планирование просмотра/обсуждение/голосование" важно примерно в течение недели до принятия решения и параллельно с "просмотром" для любых будущих просмотров.
- "Отбор интересного" важен все время для формирования своих предпочтений и пожеланий (как пул идей, что посмотреть).
Это наводит на мысль о том, что все три сценария потенциально должны быть доступны со стартового экрана (landing page), причем, возвращаясь к вопросу о представлении контента, доступны сразу: не ссылками, а именно непосредственно доступны, хотя и в упрощенном или поверхностном представлении. Другими словами, будет необходимо свести входные точки для всех трех сценариев в один экран.
В данном случае приоритизация действий (контента) по степени вовлеченности пользователя и скорости (времени жизни) сценария строится от просмотра кино к планированию и далее к формированию интересов, поэтому ближайшие просмотры, на которые собирается пользователь, должны быть на первом месте, планируемые мероприятия на втором и только после этого предпочтения/интересы пользователя и его друзей.
В первом приближении получается вот такая совокупность экранов (вместо множества стрелок-переходов я использовал цветовое кодирование) - здесь как основная используется иерархическая модель навигации:
На этом этапе важно сходу прогнать наши основные сценарии и убедиться, что они работают и мы ничего принципиального не забыли:
В дальнейшей проработке и детализации могут быть внесены различные изменения.
Например, в данном конкретном случае, наверняка, будет целесообразно:
- разнести сканер (фото) и поиск на различные экраны,
- разделить экраны моих интересов и интересов друзей (на втором в отличие от первого имеет смысл показывать планы просмотров, а свои я вижу со стартового экрана приложения),
- добавить отдельный экран непосредственно просмотра,
- добавить экран заказа еды/напитков,
- продумать, откуда берутся друзья (и вообще социальная составляющая), например, это может быть интеграция с системным Contacts Picker,
- добавить нотификации, как дополнительные точки входа,
- добавить промотируемый или рекомендованный контент,
- добавить поддержку контекстного масштабирования во всех длинных списках,
- добавить панели настроек,
- продумать историю с покупкой билетов (включая возможности печати через соответствующий контракт),
- и еще по мелочам…
Однако во всем этом благолепии будет важно помнить о приоритетности основных задач и сценариев и, еще раз повторю, соотносить с ними каждое принимаемое решение, не забывая прогонять через информационную карту свои истории с придуманными персонажами.
В этой связи одна из самых важных задач - постараться распутать схему, сделав ее более прямолинейной и, соответственно, максимально убрав циклы.
Пример. На одной из следующих итераций я получил следующую информационную схему экранов:
То же самое с переходами:
На что важно обратить внимание:
- ключевые сценарии должны решаться максимально прямолинейно (очевидно);
- сценарии с наименьшим временем жизни (оперативные) должны разрешаться максимально быстро, то есть быть под рукой;
- любые вторичные сценарии не должны отвлекать пользователя, хотя и должны быть достаточно легко доступны (скорее всего, не с первого уровня), если они важны.
Продолжение следует...
Отлично, теперь мы готовы подумать о функциональности, чем и займемся в следующей части ;)
Ключевые ресурсы
Дизайн для Windows 8Разработка для Windows 8
Разработка приложения на платформе Microsoft
Ссылки по теме