Hard prioritization, or 5 first steps to an excellent application for Windows 8. Functionality

From Idea to App

In the first and second parts of the article, we examined the four first steps on the path to designing the application:
  1. Target audience definition
  2. Application goal statement
  3. Selecting Key Scenarios
  4. Navigation planning


In the third part, we will talk about how the intended functionality of the application should be forwarded through the application interface: where it should be tied to system solutions, where to use special controls, and where it needs to be integrated into the content.


5. Consider functionality


The first and most important thing that you must accept and remember: content should be in the first place .

Content is the most, most, most important thing! Content is exactly what users come to use your application for (for definiteness: in games, content is the gaming experience, the game itself).

The total priority of content over everything else concerns both visual and design things that we will not touch on in this article, as well as implemented functionality and methods of its implementation, which we will talk about.

The first rule . If functionality can be integrated into content, do it.

In particular, for organizing navigation, the main tool is the content itself. To dive into the content, no additional solutions are needed other than using the content itself. No "read more", arrows to continue, etc.:
Remove :
The same applies to different revolutions like "read more" or "more." The user should not think, press the entire plate to him (correctly) or only the arrow and, possibly, the signature to it.

Content should and should interact directly. Proper navigation planning, which we discussed in the previous step, contributes to this.

The second rule . If the commands are contextual, they should be available only in context.

This provision in a sense continues the idea of ​​integrating functionality into content. The key message is to demonstrate additional possible actions only when activating a particular content element:
In the example above, the pop-up menu for managing your account appears only after clicking on my account. Pay attention to two things:

  1. The block with the account already represents part of the information (username and avatar), that is, it is content.
  2. The menu appears at the request of the user, but is not constantly present on the screen, since it plays a secondary role.


The same idea applies to any other secondary (albeit perhaps important) elements: they should appear on demand, or at lower levels of the application hierarchy.

Another common need is to hang some actions on regular (or not so regular) content elements. You probably are familiar with this idea of ​​websites and desktop applications - here is a recent example from the Lenovo site that I came across when downloading laptop drivers:
Here, such regular actions are adding to the download list and downloading directly. You can also easily imagine other activities like likes, tweets and favorites.

In a first approximation, when porting to Windows 8, it might look like this:
Awful, isn't it? There are at least two problems here: the contradiction with direct interaction with the content (primarily for immersion in it) and a lot of clutter.

In practice, almost certainly, these buttons in such quantity are not needed - and it is more correct to make them contextual. In Windows 8, there are two special solutions for this:

  • selection of an element + command in the application panel,
  • context menu.


If we take actions tied to individual elements to the application panel, we get approximately the following solution:
It is important that with this approach, not only actions are explicitly tied to a specific context - and appear only at the request of the user, but also that in parallel we acquire a way organization of multiple actions (applicable to several elements at once).

By the way, the selection of elements with your fingers is done perpendicular to the direction of scrolling, with the space bar from the keyboard, and with the mouse, simply by pressing the right button.

Speaking about the context, I also want to note that on each current screen there can be two contexts: the entire screen as a set of everything (usually the screen also has a name) and, possibly, one or more elements are highlighted. Accordingly, actions (commands) can make sense both within the entire “screen”, and only relative to the current selection.

The third rule . If the functionality can be implemented through charms, contracts or extensions, you need to do this.

Charms

In the previous section, I talked a little about what it is and how the presence of miracle buttons affects the design of navigation. With regard to planning functionality, I emphasize this again:

  • If you want to give the opportunity to search by the content of your application , use the search contract - Search (except for inline searches equivalent to contextual search among the information on the screen, for example, in an open document).
  • If you want to give the opportunity to share information , for example, share it on social networks or save in another application, use the share contract - Share. (The second part of this contract works to receive information from other applications, if that makes sense in your case.)
  • If you have settings , use the settings contract - Settings. It should be noted that any application from the Windows Store has a settings panel with quick access to ratings and reviews, and there may also be a settings panel with access permissions for certain services (for example, geolocation and notifications).
  • If you need to output to external devices , use the appropriate contracts for working with them (for example, for printing) - all this functionality will be collected in the Devices miracle button.


Similar considerations apply to various other contracts and extensions, such as selecting files or contacts.

As a result: do not duplicate system functionality and do not place additional buttons to access it. For example, do not use the “share on twitter” buttons in the application context.

Rule Four . Prioritize actions (commands) and distribute them between the screen itself, the application panel and the recycle bin.

Some commands are valid, if they are very important and are tied to a proportional (most likely to one) element (including the entire document, for example, the order being sent) can be placed directly on the screen in the form of corresponding buttons.

For example, in the Mail application there is one big main content element - an open letter. There are two most important actions for this open letter: reply and delete. Commands for these actions are placed directly on the screen (together with a similar and more global command to create a new letter):
Secondary actions applicable to the letter (mark it unread and move), either to the mailbox (synchronize) or to the folder (pin to the Start screen ») Moved to the application panel.

There are no other actions here, although they may seem important. Prioritization is a harsh thing. Try to adhere to the following proportion (0 is a good number that you should strive for):

Prioritization

If something does not fit in and there are too many commands, this is a clear reason to think:
  • Do you need these commands at all?
  • Are these commands needed on this screen?


In the latter case, the right decision may be to transfer the "extra" commands to the internal screen that appears when immersed in the content.

The fifth rule . Divide and conquer - use the app bar correctly.
There are two special guidelines on this subject:


In them, you need to pay attention to recommendations for placing buttons on the panel, spacing them at different angles, dividers and methods of folding several similar buttons into one with a drop-down menu. I also note that the buttons (or sets of buttons) of the application panel can act as view / sort / filter switches, etc.



The practical exercise that you need to do, armed with these rules, is as follows:
  1. Understand what functionality (actions), in addition to navigating content and demonstrating content, you need to implement?
    • What applies to the whole application?
    • What applies to a particular current screen?
    • What applies to a particular highlighted item on a particular screen?

  2. What is covered by system commands is done through system commands.
  3. Prioritize the remaining commands for each screen in accordance with the table above.


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



Ready to move on?

Build applications and come to the autumn lab .



Key resources