В первой и второй частях статьи мы рассмотрели четыре первых шага на пути проектирования приложения:
- Определение целевой аудитории
- Формулировка цели приложения
- Отбор ключевых сценариев
- Планирование навигации
В третьей части мы поговорим о том, как предполагаемая функциональность приложения должна пробрасываться через интерфейс приложения: где ее следует завязывать на системные решения, где использовать специальные элементы управления, а где ее нужно интегрировать в контент.
5. Продумайте функциональность
Первое и самое главное, что вы должны принять и запомнить: контент должен быть на первом месте.
Контент — это самое, самое, самое главное! Контент — это именно то, ради чего пользователи приходят и пользуются вашим приложением (для определенности: в играх контент — это игровой опыт, сама игра).
Тотальный приоритет контента над всем остальным касается как визуально-оформительских вещей, которые мы не будет затрагивать в данной статье, так и внедряемой функциональности и способов ее внедрения, о чем мы собственно и поговорим.
Правило первое. Если функциональность можно интегрировать в контент, сделайте это.
В частности, для организации навигации основной инструмент — это сам контент. Для погружения в контент не нужны никакие дополнительные решения, кроме как использование самого контента. Никаких «читать далее», стрелочек для продолжения и т.п.:
Убирайте:
То же самое касается различных оборотов вроде «читать далее» или «подробнее». Пользователь не должен думать, нажимать ему целиком на всю плашку (правильно) или только на стрелочку и, возможно, подпись к ней.
С контентом должно и нужно взаимодействовать напрямую. Этому же способствует правильное планирование навигации, которое мы обсуждали на предыдущем шаге.
Второе правило. Если команды контекстные, они должны быть доступны только в контексте.
Это положение в некотором смысле продолжает идею интеграции функциональности в контент. Ключевой посыл заключается в том, чтобы демонстрировать дополнительные возможные действия только при активации того или иного контентного элемента:
В примере выше всплывающее меню для управления аккаунтом появляется только после нажатия на мой аккаунт. Обратите внимание на две вещи:
- Блок с аккаунтом уже представляет часть информации (имя пользователя и аватарку), то есть является контентом.
- Меню появляется по запросу пользователя, а не присутствует постоянно на экране, так как играет вторичную роль.
Эта же идея применима и к любым другим вторичным (хоти и, возможно, важным) элементам: они должны появляться по запросу, либо на более низких уровнях иерархии приложения.
Другая частая потребность заключается в том, чтобы навесить некоторое количество действий на регулярные (или не очень регулярные) контентные элементы. Вам, наверняка, знакома эта идея по веб-сайтам и десктопным приложениям — вот свежий пример с сайта Lenovo, с которым я столкнулся, загружая драйвера для ноутбука:
Здесь такими регулярными действиями являются добавление в список загрузки и непосредственно загрузка. Вы также легко можете представить себе другие действия вроде лайков, твитов и добавления в избранное.
В первом приближении при переносе на Windows 8 это могло бы выглядеть следующим образом:
Ужасно, не правда ли? Здесь есть как минимум две проблемы: противоречие с прямым взаимодействием с контентом (прежде всего, для погружения в него) и большая захламленность.
На практике, почти наверняка, эти кнопки в таком количестве не нужны — и правильнее их сделать контекстными. В Windows 8 для этого есть два специальных решения:
- выделение элемента + команды на панели приложения,
- контекстное меню.
Если вынести действия, привязанные к отдельным элементам, в панель приложения, мы получим примерно следующее решение:
Важно, что при таком подходе не только действия явно привязаны к конкретному контексту — и появляются только по запросу пользователя, но и то, что параллельно мы приобретаем способ организации множественных действий (применимых сразу к нескольким элементам).
Кстати, выделение элементов пальцами делается перпендикулярно направлению прокрутки, с клавиатуры пробелом, а мышкой — просто нажатием правой кнопки.
Говоря о контексте также хочу отметить, что на каждом текущем экране может быть два контекста: весь экран целиком как совокупность всего (обычно экран также имеет название) и, возможно, выделенные один или несколько элементов. Соответственно и действия (команды) могут иметь смысл как в рамках всего «экрана», так и только относительно текущего выделения.
Правило третье. Если функциональность можно реализовать через чудо-кнопки (charms), контракты или расширения, это нужно сделать.
В предыдущем разделе я немного говорил о том, что это такое и как наличие чудо-кнопок влияет на проектирование навигацию. Применительно к планированию функциональности, подчеркну это еще раз:
- Если вы хотите дать возможность искать по контенту вашего приложения, используйте контракт поиска — Search (кроме случаев inline-поиска, эквивалентного контекстному поиску среди информации на экрана — например, в открытом документе).
- Если вы хотите дать возможность поделиться информацией, например, расшарить в социальные сети или сохранить в другом приложении, используйте контракт общего доступа — Share. (Вторая часть этого контракта работает для приема информации из других приложений, если это имеет смысл в вашем случае.)
- Если у вас есть настройки, используйте контракт настроек — Settings. Тут надо отметить, что у любого приложения из Windows Store есть панель настроек с быстрым доступом к рейтингу и обзорам, а также может быть панель настроек с разрешениями доступа к тем или иным сервисам (например, геолокации и оповещениями).
- Если вам нужно выводить на внешние устройства, используйте соответствующие контракты для работы с ними (например, для печати) — весь этот функционал будет собран в чудо-кнопке «Устройства» (Devices).
Схожие соображения применимы и к различным другим контрактам и расширениям, например, выбору файлов или контактов.
Как итог: не дублируйте системную функциональность и не расставляйте дополнительных кнопок для доступа к ней. Например, не делайте в контексте приложения кнопок «поделиться в твиттере».
Правило четвертое. Приоритезируйте действия (команды) и распределяйте их между самим экраном, панелью приложения и корзиной.
Некоторые команды действительно, если они очень важны и привязываются к соразмерному по важности (скорее всего, одному) элементу (в том числе всему документу, например, отправляемому заказу) могут быть размещены непосредственно на экране в виде соответствующих кнопок.
Например, в приложении «Почта» есть один большой главный контентный элемент — открытое письмо. Для этого открытого письма есть два самых важных действия: ответить и удалить. Команды для этих действий размещены непосредственно на экране (вместе со схожей и более глобальной командой создания нового письма):
Вторичные действия, применимые к письму (отметить непрочитанным и переместить), либо почтовому ящику (синхронизировать), либо к папке (закрепить на экране «Пуск») вынесены в панель приложения.
Остальных действий тут нет, хотя они и могут показаться важными. Приоритезация — штука суровая. Постарайтесь придерживаться следующей пропорции (0 — это хорошее число, к которому надо стремится):
Если что-то не влезает и команд становится слишком много, это явный повод задуматься:
- Нужны ли эти команды вообще?
- Нужны ли эти команды на данном экране?
В последнем случае верным решением может быть перенос «лишних» команд во внутренний экран, появляющийся при погружении в контент.
Правило пятое. Разделяй и властвуй — правильно используйте панель приложения.
На этот счет есть два специальных руководства:
В них надо обратить внимание на рекомендации по размещению кнопок на панели, разнесение их по разным углам, разделители и приемы свертывания нескольких схожих кнопок в одну с выпадающим меню. Также отмечу, что кнопки (или совокупности кнопок) панели приложения могут выступать переключателями вида/сортировки/фильтрации и т.п.
Практическое упражнение, которое вам надо проделать, вооружившись этими правилами, заключается в следующем:
- Понять, какую функциональность (действия), помимо навигации по контенту и демонстрации контента вам необходимо реализовать?
- Что применимо ко всему приложению?
- Что применимо к конкретному текущему экрану?
- Что применимо к конкретному выделенному элементу на конкретном экране?
- То, что покрывается системными командами, делать через системные команды.
- Приоритизировать оставшиеся команды для каждого экрана в соответствии с таблицей выше.
Пример. Возвращаемся к виртуальному приложению Movie Meeting. Начнем последовательно отвечать на вопросы.
Что применимо ко всему приложению или является некоторой глобальной функциональностью? Очевидно, поиск. Поиск — это системная функциональность, поэтому в самом приложении он напрямую вызываться не будет, хотя соответствующий экран реализовывать надо.
Что применимо к конкретным экранам (целиком)? Приведу пару примеров:
- Стартовый экран:
- Синхронизация данных
- Вызов сканера (анализа картинки с веб-камеры)
- Экран предложения просмотра:
- Позвать кого-то еще, кого нет в списке
- Проголосовать (иду, не иду)
- Предложить другое время/место
- Расширить встречу друзьям
- Высказаться по фильму
Что применимо к выделенным элементам (и что можно выделять)? Для тех же самых экранов:
- Стартовый экран:
- Ближайшая встреча — добавить напоминание
- Предложение — сразу проголосовать
- Интересный фильм у друга — добавить к себе
- Интересный фильм у себя — удалить из списка
- Интересный фильм — расшарить описание друзьям
- Экран предложения просмотра:
- Участник — подмигнуть и позвать сомневающегося
Сразу можно отметить, что все, что касается расшаривания можно реализовать через системную функцию Share. Поэтому специального решения в интерфейсе не требуется.
Дальше важно расставить приоритеты между оставшимися дополнительными действиями.
Начнем со стартового экрана:
- Никакое из действий не представляется супер-важным, чтобы его сразу размещать на экране.
- Сканер — важно, поэтому размещаем в панели приложения (справа, как что-то близкое к новой заявке и глобальное).
- Синхронизация данных — должна делаться автоматически, поэтому отправляем в корзину.
Выделенные элементы стартового экрана:
- Выделенная встреча — ок, добавляем контекстные кнопки для установки напоминания в панель слева.
- Выделенное предложение — ок, добавляем контекстные кнопки для быстрого голосования в панель слева.
- Выделенные фильмы — ок, добавляем контекстные кнопки добавления к себе или удаления из своего списка в панель слева. Пробуем дублировать контекстным меню.
Экран предложения просмотра кино:
- Голосование за предложение — это самое главное, зачем вообще нужен этот экран, поэтому кнопки должны быть размещены непосредственно на экране.
- Позвать кого-то еще — более быстрое и конкретное действие, чем просто расшарить, и может быть завязано на использование Contacts Picker — размещаем кнопку добавления участников (invite+) на панели приложения справа.
- Предложить другое место/время — требует отдельного анализа. Например, это может привести к пересмотру реализации голосования и вообще планирования встречи. Необходимо тестирование, поэтому надо начать без данной функциональности и смотреть, будут ли пользователи спрашивать ее внедрение.
- Высказаться по фильму — нет, это должно быть на экране самого фильма. И нечего влиять на предпочтения других столь брутальным образом.
Выделенные элементы экрана предложения просмотра кино:
- Выделенный участник — форсировать принятие решения кажется хорошей идей, размещаем в панели приложения контекстную кнопку слева.
Аналогичную работу нужно проделать для всех экранов приложения. Конечно, не стоит забывать также о принципиальной приоритезации функциональности по важности, срокам и сложности реализации, которые могут накладывать свои ограничения.
Итоги
С точки зрения проектирования, к этому моменту вы должны иметь четкое представление о том, как и что делает ваше приложение, как оно устроено с точки зрения пользователя, через какие сценарии и экраны ему предстоит пройти для решения своих задач и вообще, кто является ключевым пользователем вашего приложения.
Напомню еще раз ключевые шаги и результаты на каждом из них, которые вам необходимо получить:
- Знайте своего пользователя.
- Опишите 2-3 ключевых персонажа, достаточно покрывающих целевую аудиторию.
- Вы не можете делать приложение сразу для всех — поэтому надо приоритизировать пользователей и их ключевые характеристики.
- Чем ваше приложение лучше других?
- Сформулируйте “best at statement”.
- Вы не можете быть просто самым-самым лучшим — конкретизируйте, в чем именно вы лучше конкурентов в своей нише.
- Выделите ключевые сценарии
- Отберите 3-4 ключевых сценария, характерных для вашего приложения
- Вы не можете уметь делать все и сразу и лучше всех — приоритизируйте те сценарии, которые помогут вам раскрыться и наилучшим образом удовлетворить пользовательские запросы.
- Спланируйте навигацию
- Нарисуйте информационную карту приложения.
- Решите, какие блоки контента являются наиболее важными и как они соотносятся с ключевыми сценариями. От небольших фрагментов двигайтесь к целостной схеме навигации, убедившись, что доступ к ключевым сценариям всегда под рукой, а сам ход их решения максимально линеен и очевиден.
- Продумайте функциональность
- Контент на первом месте.
- Решите, какие действия вам нужны на каждом из экранов, в том числе действия, применимые контекстно к выделенным элементам. Не дублируйте системные команды, остальное приоритизируйте и смело выкидывайте лишнее. Чем проще пользоваться, тем легче пользователю (слишком большой спектр возможностей, кстати, скорее смущает и тормозит выбор).
Готовы двигаться дальше?
Создавайте приложения и приходите на осенние лабораторные работы.
Ключевые ресурсы
Автор: kichik
