Жесткая приоритизация, или 5 первых шагов к отличному приложению для Windows 8. Функциональность

в 12:01, , рубрики: windows, Windows 8, Блог компании Microsoft, интерфейсы, проектирование, проектирование взаимодействия, метки: , , , ,

From Idea to App

В первой и второй частях статьи мы рассмотрели четыре первых шага на пути проектирования приложения:

  1. Определение целевой аудитории
  2. Формулировка цели приложения
  3. Отбор ключевых сценариев
  4. Планирование навигации

В третьей части мы поговорим о том, как предполагаемая функциональность приложения должна пробрасываться через интерфейс приложения: где ее следует завязывать на системные решения, где использовать специальные элементы управления, а где ее нужно интегрировать в контент.

5. Продумайте функциональность

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

Контент — это самое, самое, самое главное! Контент — это именно то, ради чего пользователи приходят и пользуются вашим приложением (для определенности: в играх контент — это игровой опыт, сама игра).

Тотальный приоритет контента над всем остальным касается как визуально-оформительских вещей, которые мы не будет затрагивать в данной статье, так и внедряемой функциональности и способов ее внедрения, о чем мы собственно и поговорим.

Правило первое. Если функциональность можно интегрировать в контент, сделайте это.

В частности, для организации навигации основной инструмент — это сам контент. Для погружения в контент не нужны никакие дополнительные решения, кроме как использование самого контента. Никаких «читать далее», стрелочек для продолжения и т.п.:

Arrows to continue

Убирайте:

No arrows. Go thru the content itself.

То же самое касается различных оборотов вроде «читать далее» или «подробнее». Пользователь не должен думать, нажимать ему целиком на всю плашку (правильно) или только на стрелочку и, возможно, подпись к ней.

С контентом должно и нужно взаимодействовать напрямую. Этому же способствует правильное планирование навигации, которое мы обсуждали на предыдущем шаге.

Второе правило. Если команды контекстные, они должны быть доступны только в контексте.

Это положение в некотором смысле продолжает идею интеграции функциональности в контент. Ключевой посыл заключается в том, чтобы демонстрировать дополнительные возможные действия только при активации того или иного контентного элемента:

Context Menu

В примере выше всплывающее меню для управления аккаунтом появляется только после нажатия на мой аккаунт. Обратите внимание на две вещи:

  1. Блок с аккаунтом уже представляет часть информации (имя пользователя и аватарку), то есть является контентом.
  2. Меню появляется по запросу пользователя, а не присутствует постоянно на экране, так как играет вторичную роль.

Эта же идея применима и к любым другим вторичным (хоти и, возможно, важным) элементам: они должны появляться по запросу, либо на более низких уровнях иерархии приложения.

Другая частая потребность заключается в том, чтобы навесить некоторое количество действий на регулярные (или не очень регулярные) контентные элементы. Вам, наверняка, знакома эта идея по веб-сайтам и десктопным приложениям — вот свежий пример с сайта Lenovo, с которым я столкнулся, загружая драйвера для ноутбука:

Web Site

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

В первом приближении при переносе на Windows 8 это могло бы выглядеть следующим образом:

Integrated Buttons

Ужасно, не правда ли? Здесь есть как минимум две проблемы: противоречие с прямым взаимодействием с контентом (прежде всего, для погружения в него) и большая захламленность.

На практике, почти наверняка, эти кнопки в таком количестве не нужны — и правильнее их сделать контекстными. В Windows 8 для этого есть два специальных решения:

  • выделение элемента + команды на панели приложения,
  • контекстное меню.

Если вынести действия, привязанные к отдельным элементам, в панель приложения, мы получим примерно следующее решение:

Using AppBar

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

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

Говоря о контексте также хочу отметить, что на каждом текущем экране может быть два контекста: весь экран целиком как совокупность всего (обычно экран также имеет название) и, возможно, выделенные один или несколько элементов. Соответственно и действия (команды) могут иметь смысл как в рамках всего «экрана», так и только относительно текущего выделения.

Правило третье. Если функциональность можно реализовать через чудо-кнопки (charms), контракты или расширения, это нужно сделать.

Charms

В предыдущем разделе я немного говорил о том, что это такое и как наличие чудо-кнопок влияет на проектирование навигацию. Применительно к планированию функциональности, подчеркну это еще раз:

  • Если вы хотите дать возможность искать по контенту вашего приложения, используйте контракт поиска — Search (кроме случаев inline-поиска, эквивалентного контекстному поиску среди информации на экрана — например, в открытом документе).
  • Если вы хотите дать возможность поделиться информацией, например, расшарить в социальные сети или сохранить в другом приложении, используйте контракт общего доступа — Share. (Вторая часть этого контракта работает для приема информации из других приложений, если это имеет смысл в вашем случае.)
  • Если у вас есть настройки, используйте контракт настроек — Settings. Тут надо отметить, что у любого приложения из Windows Store есть панель настроек с быстрым доступом к рейтингу и обзорам, а также может быть панель настроек с разрешениями доступа к тем или иным сервисам (например, геолокации и оповещениями).
  • Если вам нужно выводить на внешние устройства, используйте соответствующие контракты для работы с ними (например, для печати) — весь этот функционал будет собран в чудо-кнопке «Устройства» (Devices).

Схожие соображения применимы и к различным другим контрактам и расширениям, например, выбору файлов или контактов.

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

Правило четвертое. Приоритезируйте действия (команды) и распределяйте их между самим экраном, панелью приложения и корзиной.

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

Например, в приложении «Почта» есть один большой главный контентный элемент — открытое письмо. Для этого открытого письма есть два самых важных действия: ответить и удалить. Команды для этих действий размещены непосредственно на экране (вместе со схожей и более глобальной командой создания нового письма):

Mail app

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

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

Prioritization

Если что-то не влезает и команд становится слишком много, это явный повод задуматься:

  • Нужны ли эти команды вообще?
  • Нужны ли эти команды на данном экране?

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

Правило пятое. Разделяй и властвуй — правильно используйте панель приложения.
На этот счет есть два специальных руководства:

В них надо обратить внимание на рекомендации по размещению кнопок на панели, разнесение их по разным углам, разделители и приемы свертывания нескольких схожих кнопок в одну с выпадающим меню. Также отмечу, что кнопки (или совокупности кнопок) панели приложения могут выступать переключателями вида/сортировки/фильтрации и т.п.


Практическое упражнение, которое вам надо проделать, вооружившись этими правилами, заключается в следующем:

  1. Понять, какую функциональность (действия), помимо навигации по контенту и демонстрации контента вам необходимо реализовать?
    • Что применимо ко всему приложению?
    • Что применимо к конкретному текущему экрану?
    • Что применимо к конкретному выделенному элементу на конкретном экране?

  2. То, что покрывается системными командами, делать через системные команды.
  3. Приоритизировать оставшиеся команды для каждого экрана в соответствии с таблицей выше.

Пример. Возвращаемся к виртуальному приложению Movie Meeting. Начнем последовательно отвечать на вопросы.

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

Что применимо к конкретным экранам (целиком)? Приведу пару примеров:

  • Стартовый экран:
    • Синхронизация данных
    • Вызов сканера (анализа картинки с веб-камеры)

    Home Screen

  • Экран предложения просмотра:
    • Позвать кого-то еще, кого нет в списке
    • Проголосовать (иду, не иду)
    • Предложить другое время/место
    • Расширить встречу друзьям
    • Высказаться по фильму

    Preview Screen

Что применимо к выделенным элементам (и что можно выделять)? Для тех же самых экранов:

  • Стартовый экран:
    • Ближайшая встреча — добавить напоминание
    • Предложение — сразу проголосовать
    • Интересный фильм у друга — добавить к себе
    • Интересный фильм у себя — удалить из списка
    • Интересный фильм — расшарить описание друзьям

  • Экран предложения просмотра:
    • Участник — подмигнуть и позвать сомневающегося

Сразу можно отметить, что все, что касается расшаривания можно реализовать через системную функцию Share. Поэтому специального решения в интерфейсе не требуется.

Дальше важно расставить приоритеты между оставшимися дополнительными действиями.

Начнем со стартового экрана:

  • Никакое из действий не представляется супер-важным, чтобы его сразу размещать на экране.
  • Сканер — важно, поэтому размещаем в панели приложения (справа, как что-то близкое к новой заявке и глобальное).
  • Синхронизация данных — должна делаться автоматически, поэтому отправляем в корзину.

Выделенные элементы стартового экрана:

  • Выделенная встреча — ок, добавляем контекстные кнопки для установки напоминания в панель слева.
  • Выделенное предложение — ок, добавляем контекстные кнопки для быстрого голосования в панель слева.
  • Выделенные фильмы — ок, добавляем контекстные кнопки добавления к себе или удаления из своего списка в панель слева. Пробуем дублировать контекстным меню.

Home Screen On Selection

Экран предложения просмотра кино:

  • Голосование за предложение — это самое главное, зачем вообще нужен этот экран, поэтому кнопки должны быть размещены непосредственно на экране.
  • Позвать кого-то еще — более быстрое и конкретное действие, чем просто расшарить, и может быть завязано на использование Contacts Picker — размещаем кнопку добавления участников (invite+) на панели приложения справа.
  • Предложить другое место/время — требует отдельного анализа. Например, это может привести к пересмотру реализации голосования и вообще планирования встречи. Необходимо тестирование, поэтому надо начать без данной функциональности и смотреть, будут ли пользователи спрашивать ее внедрение.
  • Высказаться по фильму — нет, это должно быть на экране самого фильма. И нечего влиять на предпочтения других столь брутальным образом.

Выделенные элементы экрана предложения просмотра кино:

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

Preview Screen On Selection

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

Итоги

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

Напомню еще раз ключевые шаги и результаты на каждом из них, которые вам необходимо получить:

  1. Знайте своего пользователя.
    • Опишите 2-3 ключевых персонажа, достаточно покрывающих целевую аудиторию.
    • Вы не можете делать приложение сразу для всех — поэтому надо приоритизировать пользователей и их ключевые характеристики.

  2. Чем ваше приложение лучше других?
    • Сформулируйте “best at statement”.
    • Вы не можете быть просто самым-самым лучшим — конкретизируйте, в чем именно вы лучше конкурентов в своей нише.

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

  4. Спланируйте навигацию
    • Нарисуйте информационную карту приложения.
    • Решите, какие блоки контента являются наиболее важными и как они соотносятся с ключевыми сценариями. От небольших фрагментов двигайтесь к целостной схеме навигации, убедившись, что доступ к ключевым сценариям всегда под рукой, а сам ход их решения максимально линеен и очевиден.

  5. Продумайте функциональность
    • Контент на первом месте.
    • Решите, какие действия вам нужны на каждом из экранов, в том числе действия, применимые контекстно к выделенным элементам. Не дублируйте системные команды, остальное приоритизируйте и смело выкидывайте лишнее. Чем проще пользоваться, тем легче пользователю (слишком большой спектр возможностей, кстати, скорее смущает и тормозит выбор).

Готовы двигаться дальше?

Создавайте приложения и приходите на осенние лабораторные работы.


Ключевые ресурсы

Автор: kichik

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js