Блог Константина Кичинского

Редизайн. Музыка VK. Часть 1

Константин Кичинский — Thu, 16 May 2013 20:00:01 GMT

В этой не очень большой серии статей, я постараюсь осветить некоторые важные моменты проектирования и дизайна приложений для Windows 8 на одном конкретном примере. С любезного согласия автора приложения, Филиппа Панфилова, я буду разбирать его Музыку VK для Windows 8.

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

Еще важный момент: несмотря на некоторые мнения, лично я не отношу себя к дизайнерам, скорее к просто достаточно разумным для некоторых задач людям. Я также не формулирую гайдлайны для Windows 8 и не имею никакого отношения к разработке каких-либо из упоминаемых приложений.

Давайте двигаться дальше. Первое, что я рекомендую вам сделать, чтобы вы тоже могли прочувствовать мои выводы (кстати, если вы с ними не согласны или у вас есть другие варианты решений/улучшений, и я, и Филипп, будем рады увидеть ваше мнение в комментариях), это поставить себе приложение. Сделать это можно, перейдя по этой ссылке: http://apps.microsoft.com/webpdp/app/f2a74b99-7263-418a-a3d3-4d0c0f69a6b2.

Поиграйтесь с приложением, послушайте любимую музыку, проведите с ним какое-то время. Это неплохое приложение. Да. Хотя местами мрачноватое и несколько неуклюжее в деталях. Но неплохое.

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

Ах да, *just in case*, вся музыка в моих личных аудиозаписях честно куплена. А теперь в бой!

Где север?

Прежде всего, чтобы двигаться, нам нужно направление. Нужны ориентиры, от которых мы сможем отталкиваться, и цель, к которой мы будем двигаться. С первым все более-менее просто — это наши гайдлайны (http://design.windows.com) и принципы дизайна для Windows 8, вместе задающие рамки, в которые нужно стараться попасть. Со вторым сложнее — и наверняка цель приложения может сформулировать только его автор. Но я все же попытаюсь определить некоторые варианты.

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

Чтобы понять, что какое-то решение является более приемлемым, чем другое, или, например, что какой-то элемент приложения можно спокойно выкинуть, нужно такие решения с чем-то соизмерять. Одним из вариантом соизмерения является формулировка того, в чем ваше приложение лучше других (best at statement). Готовясь к этой серии, я пересмотрел около 20 различных приложений музыкальной направленности, среди которых были и приложения для радио, и для проигрывания музыкальных коллекций из разных источников, и с явным фокусом на тексте песен, и да… несколько музыкальных приложений для Вконтакте.

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

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

Это прекрасно. Это не всем нравится, но это, правда, прекрасно!

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

Ура, у нас есть цель, но…

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

Плеер

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

«С плеером беда», — подумал я, посмотрев на приложение. Нет, это не самый ужасный или плохой плеер, который я видел. Вполне себе плеер.

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

А вот еще регулировка громкости сверху:

Основная проблема этого плеера в том, что он перегружен. В нем слишком много элементов управления, которые неаккуратно разбросаны направо-налево. Элементов так много, что элемент управления уровнем звука оказался вытеснен наверх. Вот как много!

Кстати, в практическом выражении это приводит к некорректной обрезке в Fill-режиме работы приложения:

Не забывайте это тестировать. Минимальное разрешение, которое должно поддерживать ваше приложение: 1024x768.

Есть и еще несколько важных мелочей, но их мы обсудим позже.

Почему плеер?

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

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

(Тут, впрочем, плеер можно спрятать — и тогда останется одна атмосфера, но этот момент мы оставим на потом.)

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

Типичный плеер

Если вы поставите себе с десяток различных музыкальных приложений для Windows 8, вы довольно быстро обнаружите одну закономерность:

Большинство из этих приложений имеют общую схему композиции в части размещения плеера воспроизведения в нижней панели приложения. И это не случайно. Этой же схемы придерживается и автор приложения Музыка ВК.

В целом, схема выглядит примерно так:

Плеер на разных страницах единообразно размещается в панели приложения, поддерживая текущий статус воспроизведения и предоставляя доступ к различным элементам управления. Иногда в панели также можно вызвать вторичны команды вроде показа списка воспроизведения. Сами команды плеера также можно условно разделить на главные (play/pause/stop) и вторичные (prev/next/shuffle/cycle…).

Авторы каждого конкретного приложения сами расставляют приоритеты, но в целом это типовое решение стандартной задачи, думаю, во многом вдохновленное приложением Music, поставляемым вместе с Windows 8:

Вот, например, плеер приложения Gaana:

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

А вот плеер приложения 双子电台 для прослушивания радиостанций:

Здесь плеер небольшой, также нет звука, а слева много пустого пространства.

Еще одно китайское приложение — QQ音乐, уже музыкальное:

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

Кстати, в этом же приложении интересно нетипичное меню для смена цикличности (это не стандартное flyout-меню):

В приложении Multimedia 8 панель приложения двоякая, что связано с сутью приложения. Оно нацелено на управление коллекциями музыки и в частности одной из задач является создание списков воспроизведения. Поэтому на многих страницах вы увидите вот такую композицию:

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

Дополнительные опции спрятаны за многоточием, вперед/назад не в фокусе, а звук, кстати, вынесен отдельно наверх.

И еще один пример — приложение Desi Music из Индии:

Тут плеер занимает значительную часть пространства и отнесен в правую, глобальную, часть. Чем-то напоминает плеер из Music: наиболее частые команды вынесены совсем направо традиционной группой prev/play|pause/next, а вторичные команды смешивания и повторения оказались левее. У меня это вызывает некоторое замешательство, так как я бы переставил эти группы как раз в обратном порядке, но, возможно, тут есть еще какие-то культурные особенности. Слева в панели находится правильно вынесенная отдельно команда доступа к плейлисту (однако, она не контекстная по сути), и рядом с ней — настройки для загрузки композиций.

И еще… тоже из Индии — веселое и яркое приложение Dhingana:

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

И еще… плеер из приложения 8tracks radio:

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

И последний пример в этой подборке — приложение 多米音乐:

Здесь плеер разделен на две части: слева — то, что сейчас происходит + лайк, справа — элементы управления плеером. Панели и кнопки кастомные и весьма своеобразно стилизованные.

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

Мысли про плееры

Прежде, чем мы перейдем непосредственно к плееру приложения Музыка ВК, я постараюсь резюмировать несколько своих мыслей на счет использования для него панели приложения и поведения самого плеера:

В зависимости от природы контента (например, контент радиостанции или музыкальная коллекция) функциональность кнопок вперед/назад может различаться. В большинстве случае обе кнопки являются вторичными и иногда могу опускаться. Особенно это касается кнопки «назад», которая размещается скорее по привычке и для симметрии, а на практике используется редко. К слову, в приложении Музыка ВК кнопка «назад» в плеере отсутствует, хотя это не означает, что нет способа вернуться к предыдущей композиции.
Решение о лево- или правостороннем размещении плеера в панели приложения авторами, похоже, принимается несистемно, но исходя из некоторых представлении о симметрии и эстетики. Тем не менее, общая рекомендация заключается в том, чтобы размещать глобальные команды справа, а контекстные (например, завязанные на текущее состояние или выделение) слева. Также, конечно, следует учитывать стилистические моменты и в целом стремиться к достижению баланса в заполнении панели приложения, чтобы не было больших перекосов в одной из частей.
Визуальный стиль элементов может отличаться, но в целом разнообразие не очень большое и есть стремление к общей стилистике элементов управления в Windows 8: круглые кнопки на панели приложения, простые иконки и т.п. Например, вот так выглядит панель в приложении NRJ:

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

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

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

А на остальных страницах она доступна в панели приложения:

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

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

Это общесистемный уровень громкости. В приложении может быть также свой собственный, что в большинстве случаев является полезным, так как позволяет более тонко регулировать уровень, причем независимо для разных приложений. Обратная сторона встраивания такого регулятора, очевидно, в том, что возникает дополнительная интерфейсная сложность: как расположить ползунок, где разместить кнопку и т.п. Некоторые авторы сразу выставляют шкалу рядом с плеером, некоторые, как в примере выше, прячут ее за кнопкой (мне такой вариант представляется более правильным).
Старайтесь не переусложнять панель приложения и плеер различными опциями. Для музыкальных приложений типичными дополнительными кнопками, например, являются команды перемешивания и режима повторения. В разных приложениях с ними обходятся по-разному: где-то их вообще нет, где-то они спрятаны в дополнительных опциях (например, за многоточием – см. скриншот выше), где-то размещены рядом с командами воспроизведения или напротив разнесены с ними по разные стороны панели. Одна из ключевых минизадач заключается как раз в том, чтобы дать правильную оценку, насколько они важны в вашем приложении. Например, в приложении Qobuz для этих команд явно отдан пониженный приоритет:
Не забывайте про Snap-режим закрепления приложения слева или справа. В этом состоянии панель приложения занимается заметно меньше места, поэтому вам надо будет хорошенько подумать как над тем, что и в каком виде отображается на экране, так и над тем, что осталось от вашей панели приложения. Например, в упоминавшемся выше приложении QQ音乐 в Snap-режиме показывается текст текущей композиции, а кнопки в панели приложения центрированы и имеют несколько другой порядок по сравнению с полной версией:

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

Плеер Музыки ВК

Теперь, когда вы вооружены многими знаниями и примерами, самое время посмотреть еще раз на плеер и панель приложения нашего подопытного кролика:

Я напомню, что в приложении над панелью также показывается список воспроизведения:

И дополнительно есть управление уровнем громкости внутри приложения.

Проблемы:

Панель приложения вместе с плеером оказывается перегруженной. Она также обрезается в Fill-режиме:

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

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

⇒ Желательно отделить явно контекстное от глобального (и самого плеера).

⇒ Навигацию желательно отделить от управления.

Кстати, обратите внимание, что кнопки слева и справа имеют разный размер. Мне это представляется вполне сознательным действием, носящим в значительной степени эстетический характер:

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

Важная мелкая деталь касается самих кнопок, точнее их внутреннего содержания. Здесь есть два момента: 1) выбор подходящих иконок и 2) правильное их размещение внутри круга.

С первым вопросом я бы рекомендовал обратить внимание на иконки для плейлиста и перемешивания. Относительно кассеты я не уверен, а вот для перемешивания лучше использовать классическую (красную):

Вообще, по умолчанию рекомендуется использовать стандартные иконки: http://msdn.microsoft.com/en-us/library/windows/apps/hh770557.aspx

Также некоторые вопросы вызывает иконка добавления к себе. Плюсик — это обычно «добавление нового», а тут явно запоминание/сохранение или добавление в избранное. Для этого больше подходит звездочка или сердечко.
Второй вопрос — более тонкий и требует привлечения некоторой механики, особенно, при ручном задании содержания кнопок/размеров и позиционирования. Я не уверен, что у нас есть попиксельная инструкция для Windows 8, но в целом тут должны быть применимы те же соображения, что и для Windows Phone: желательно, чтобы иконки внутри круга вписывались в некоторую область внутри и были сбалансированы в размере относительно друг друга:

Стандартные кнопки в панели приложения имеют размер 40x40px. Вот как эта схема ложится на кнопки в панели рассматриваемого приложения:

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

Слева направо: текущая кнопка, наложенная центрированная стрелка, кнопка с центрированной стрелкой.
— Ну и что это? Разница всего в один/полтора пикселя, — возможно, скажите вы.

А из таких пикселей и складывается общее впечатление — внимание к мелочам, помните принципы дизайна?

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

Это кажется традиционным вариантом решения, однако, нужно обратить внимание на еще несколько мелочей:

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

⇒ Сам плеер надо отдельно оптимизировать

Еще из важных деталей, которые нужно учитывать:

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

Самое время распечатать банку с красками!

Колдовство

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

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

Обновленная панель:

С логической точки зрения нужно начать с разделения всех элементов на отдельные связанные группы:

Действия с текущей песней, не связанные с плеером:

добавление к себе,
информация о песне;

Действия с воспроизведением (плеер):

название композиции + обложка,
текущий прогресс воспроизведения,
проигрывание/пауза;

Действия с плейлистом (плеер):

перейти к следующей песне,
посмотреть список воспроизведения;

Настройки режима воспроизведения (плеер):

перемешивать,
повторять.

И отдельно звук!

10 элементов — многовато, конечно. И это еще нет кнопки «назад»!

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

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

Мой первый шаг — временно выкинуть из панели то, что не связано с плеером, так как плеер и все, что с ним связано, определенно занимает большую часть пространства. (Попутно себя ловлю на мысли, что нет ничего более постоянного, чем временное.)

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

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

Теперь правая часть мне нравится сильно больше. Зато левая стала заметно хуже, давайте попробуем уменьшить ее сложность и улучшить визуальное представление.

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

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

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

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

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

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

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

Компактнее.

Внезапно возникают вопросы:

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

Пробуем. Удобнее для пальцев, значит, нужно увеличить область касания, и ее контрастность относительно фона и самой линии:

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

Играемся с деталями, пробуем добавить время:

Получается нагромождение подписей, экспериментируем дальше:

Да, похоже на то, что нужно.

Смотрим вариант без ползунка:

Стало пустовато, но тоже работает. Двигаемся дальше.

Начинает раздражать одиноко висящая кнопка «вперед» — надо с ней что-то сделать. Раздражают три вещи:

Без подписи она не похожа на кнопки справа, а подпись к ней делать бессмысленно.
Она одиноко висит справа от текущей песни, это по-прежнему одиноко висящая кнопка. Возможно, к ней надо добавить кнопки плейлиста или еще что-то из того, что мы временно выкинули. Однако при этом не хочется вклиниваться между традиционным порядком “prev, play/pause, next”, поэтому если добавлять, то правее от нее.
Она ничего не значит, кроме как «эй стоп, то есть вперед! Мне надоела текущая песня». В кнопке нет содержания, кроме действия.

Смотрю на скриншоты других приложений. Подглядываю интересную идею в приложении 8tracks radio: что если явно показать, что там впереди? Только пойти еще дальше — и вообще выкинуть кнопку вперед?

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

Ловлю себя на мысли, что как здорово, что мы фактически только что выкинули одну кнопку, а перед этим еще одну интегрировали в контент — и сэкономили тем самым место. Это ли не волшебство?

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

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

Остались избранное, информация о песне и плейлист.

Начнем с первых двух — тут в моей голове случается большая коллизия:

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

или

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

Смотрим на экран: куда же их впихнуть?

«На экран и впихнуть», — решаю я и перекидываю кнопки наверх.

Думаем над эстетикой. Возможно, можно выкинуть подписи или разместить кнопки сбоку?

Или внутри?

Запоминаем оба варианта, останавливаемся пока на последнем.

Теперь плейлист. Пробуем с простого варианта — добавляем его в ряд кнопок справа:

Кажется, не так уж и плохо. Даем себе еще пару минут на подумать, прежде, чем принять текущий вариант как достаточно разумный.

Что, если эту кнопку тоже сделать контекстной?

Оставляем, как потенциально работающий вариант. Смотрим на то, что получилось:

или

Радуемся.

Можно потратить еще несколько часов и отточить отдельные детали: отступы, подписи и т.п. Также стоит продумать какие-то интересные моменты: например, как происходит смена трека, меняется ли порядок иконок в «далее» и плейлисте при нажатии на кнопку случайно, если нажата кнопка «повторять текущую композицию», надо ли это как-то дополнительно отмечать?

p.s. Плейлист все же раздражает – хочется его в навигацию перенести. Посмотрим…

В следующих частях мы посмотрим,

как можно улучшить отображение плейлиста и дополнительной информации о песне;
альтернативные варианты размещения плеера, переворачивающие все с ног на голову;
дизайн главной страницы приложения;
snap-view, контракты, плитки и т.п.

Pre-Devcon дизайн-акция!

Константин Кичинский — Thu, 18 Apr 2013 18:27:00 GMT

Мы тут думали с коллегами, что бы хорошего рассказать на DevCon про дизайн приложений под Windows Phone и Windows 8. Потом мы с Аленой подумали над этой светлой мыслью еще немножко и поняли, что нет ничего лучше, чем рассказать практические истории из вашей жизни. Еще мы подумали, что было бы замечательно заодно помочь вам сделать ваши приложения под наши платформы еще лучше и удобнее для их пользователей. Поэтому...

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

Напишите в комментарии ссылку на приложение (или две ссылки, если оно есть под W8 и WP) и коротко, что вы бы хотели в нем переделать или что вам не нравится (ответ "все" или "дизайн" не подходит). Ну и какой-нибудь контакт для связи не забудьте.

p.s. Скажу честно, что мы потянем до DevCon только 2-3 приложения в дополнение к тем, которые мы уже запланировали проанализировать, поэтому приоритет будет отдаваться тем приложениям, относительно которых нам явно будет что сказать и что предложить (это сугубо субъективно), и если у вас комбинированная история WP+W8, нам это тоже более интересно (это не исключает из рассмотрения приложения только под одну из платформ).

p.p.s. Если вы хотите понять, что мы понимаем под "распотрошить", то это примерно вот так: http://blogs.msdn.com/b/kichinsky/archive/tags/_2300_metrolynch/ -- конечно, в обновленных реалиях :)

Ресурсы по учету специальных возможностей для Windows 8

Константин Кичинский — Wed, 09 Jan 2013 07:12:00 GMT

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

Разработка с учетом специальных возможностей (MSDN)
Windows 8 fact sheet for printing and and Accessibility guide for Windows 8
Introduction to Accessibility (Channel 9)
Designing with Narrator in mind (Channel 9)
Создание доступных приложений (C#, VB, C++, MSDN)
Специальные возможности в приложениях (JavaScript, MSDN)

Как стать ближе к пользователю?

Константин Кичинский — Fri, 28 Dec 2012 07:53:00 GMT

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

Как я писал, в современном мобильном мире особенно критично уметь одновременно решать две конфликтующие за место под солнцем задачи: 1) обеспечивать быстрый доступ к актуальной информации, самым важным действиям и в целом высокую скорость выполнения ключевых сценариев – и в то же время 2) позволять пользователям погружаться в детали, узнавать подробности и реализовывать важные, но все же вторичные действия.

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

В принципе, необходимость совмещения обозначенных выше задач родилась не сегодня — и обсуждать их, соответственно, начали довольно давно. Здесь я хочу сослаться на статью Susan Weinschenk “The psychologists 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.

А тем, кто заинтересован в подробностях с точки зрения юзабилити, рекомендую соответствующую статью Якоба Нильсена – “Progressive Disclosure”.

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

Время

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

Другой важной проекцией информации является ее временная составляющая: когда та или иная информация появляется в процессе взаимодействия с приложением.

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

есть поле для ключевой активности приложения, которая завязана на, скажем, собирание «яблок»;
собранные «яблоки» заносятся в ящики;
логика приложения такова, что пользователь, заинтересованный в ключевой активности, собирает «яблоки», однако, количество ящиков ограничено – и чтобы снять это ограничение он должен зарегистрироваться/заплатить/сделать дополнительное действие.

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

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

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

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

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

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

А можно вывести предупреждение за шаг или несколько до наступления события, заблокировав дальнейшие действия:

Или сделать и то, и другое сразу:

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

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

Я не думаю, что описанное выше должно быть для вас большим откровением, тем не менее, надеюсь, мне удалось проиллюстрировать общую идею.

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

Контекст

Давайте рассмотрим еще один интересный пример и поговорим о географии, точнее о геопривязке. Тема эта известная, возможно, даже чуть-чуть поднадоевшая, но надеюсь, окажется тоже достаточно прозрачной.

Представьте, что вы решили предоставить пользователю доступ к каталогу каких-то географических объектов, скажем, кафе/ресторанов с живой музыкой или чего-то более зимнего, например, катков в г. М.

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

Далее по нажатию на любой из объектов можно показывать сопутствующую информацию (описание, адрес, средний размер чека, время работы и т.п.), либо непосредственно переводить на карточку объекта.

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

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

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

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

В итоге мы получим географическую близость объектов к пользователю. Если расширить это понятие, то можно говорить о том, что мы ближе к пользователю вытаскиваем то, что ближе ему по текущему контексту.

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

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

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

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

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

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

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

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

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

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

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

Действия

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

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

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

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

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

На первый уровень, или основное состояние экрана, выносится основная функциональность, вторичная – появляется по запросу пользователя.

Давайте рассмотрим еще один пример. Представьте, что на экране описания какого-то товара в магазине вы предоставляете пользователю возможность сделать несколько действий с ним. Например,

добавить в корзину (это самое важное действие!),
отложить в закладки,
отправить информацию друзьям (ориентируемся на контракт «Общий доступ») и
сообщить о поступлении в продажу, если товара нет в наличии,
закрепить на экране «Пуск».

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

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

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

Можем ли мы вытянуть действия, находящиеся на уровне ниже наверх? Технически, да: мы могли бы рядом с каждым товаром поставить три-четыре кнопочки:

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

Тем не менее идея вынести возможность делать быстрые действия на уровень выше остается разумной. Что же делать?

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

Так, кстати, сделали в приложении «ЛитРес» — кнопка «читать книгу» сразу переводит к режиму чтения без промежуточных страниц описания:

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

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

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

Наконец, давайте вкратце рассмотрим еще один интересный срез.

Сущность

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

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

Во многих случаях такое решение оказывается подходящим под задачу и в целом весьма хорошим.

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

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

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

на самом нижнем экране вы выводите все параметры какой-то конкретной перевозки,
на уровне выше вы говорите о каком-то направлении (например, перевозки по северо-западному региону), выводя также кратко информацию по происходящем в регионе перевозкам;
на первом уровне вы выводите регионы, суммируя информацию с уровней ниже.

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

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

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

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

«Не говорите мне, куда мне идти», — ваш пользователь

Константин Кичинский — Mon, 24 Dec 2012 05:11:06 GMT

В серии статей про принципы дизайна для Windows 8 мы рассмотрели ключевые идеи и подходы, лежащие в основе всей платформы и задающие язык дизайна для Windows. Чуть ранее, обсуждая процесс проектирования приложения, мы рассматривали в общем-то эти же принципы, но уже в разрезе правильной расстановки приоритетов.

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

Ссылки

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

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

Когда разработчики и дизайнеры увидели «плиточный» интерфейс Windows Phone и Windows 8, они быстро смекнули визуальную составляющую, однако, суть часто оставалась прежней:

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

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

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

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

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

По-умному это называется “progressive disclosure”, а по-простому это означает, что пользователю необходимо обеспечить как возможность быстро разобраться, что к чему, так и спокойно погружаться к деталям, переходя к исследованию контента. Важно и то, и другое.

Отсюда возникает вопрос: как добиться обеих задач одновременно? Если исходить из идей приоритизации целей пользователя и важности контента, ответ напрашивается сам собой.

Контент находится на самом последнем уровне? — Не вопрос! Давайте вытащим его наверх!

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

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

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

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

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

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

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

Хаб становится проекцией всех ключевых сценариев, вынося на поверхность ключевую информацию из нижних уровней:

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

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

Несколько дополнительных сценариев, развивающих эту идею, мы рассмотрим в следующей статье.

Записи с Windows Phone Design Bootcamp

Константин Кичинский — Tue, 18 Dec 2012 08:01:00 GMT

На Channel 9 стали доступны записи буткампа по дизайну для Windows Phone. Лекции читает Jared T Potter, руководивший в течение трех лет интеграцией дизайна в команде Windows Phone, а сейчас главный дизайнер в SixThAveStudios.com:

101

201

Design Camp + Зимняя школа по дизайну для Windows 8

Константин Кичинский — Mon, 03 Dec 2012 08:07:00 GMT

13 декабря,
Digital October, Москва

Design Camp — это профессиональная конференция Microsoft, проводимая при поддержке Британской высшей школы дизайна и посвященная дизайну и проектированию современных приложений.

Регистрация: events.techdays.ru/descamp/2012-12/

Зачем мы ее проводим?

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

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

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

Что будет?

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

Специально для вас мы позвали экспертов из Mail.ru Group, Яндекса, Usabilitylab, UIDesign, Parcsis и ведущих преподавателей Британской высшей школы дизайна. Специальный гость — Евгений Гаврилов из команды Windows Phone Design (Microsoft), который расскажет о том, как картинки превращаются в жизнь и об опыте их команды по интеграции дизайна.

Регистрация: events.techdays.ru/descamp/2012-12/

И еще! Тренинг!

В выходные после конференции мы организуем Зимнюю школу по дизайну для Windows 8. Это двухдневное бесплатное мероприятие, проводимое при поддержке компании ITMozg.

Попадут не все, подать заявку на участие можно тут: msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032537874&Culture=ru-RU&community=0

История Windows 8

Константин Кичинский — Thu, 22 Nov 2012 08:34:51 GMT

На конференции UXWeek 2012 Jensen Harris, Director of Program Management из команды Windows UX, рассказал о том, как создавалась новая версия Windows и принципах, которым следовала команда в процессе разработки.

UX Week 2012 | Jensen Harris | The Story of Windows 8 from Adaptive Path on Vimeo.

Обязательно посмотрите! Это увлекательная история о том, как и почему иногда можно отказываться от привычного в пользу современного, отвечающего текущим реалиями и видению будущего.

Принципы дизайна приложений для Windows 8. Выигрывайте вместе

Константин Кичинский — Mon, 12 Nov 2012 15:02:49 GMT

Это заключительная статья в серии про принципы дизайна для Windows 8. Сегодня мы поговорим об экосистеме и важности интеграции.

Сегодня, как никогда раньше, важно постоянно помнить о том, что ваше приложение не живет одиноко в вакууме, в котором нет никого и ничего, кроме него. Да, конечно, оно монопольно занимает весь экран, но это немного другая история.

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

Экосистема

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

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

На втором уровне лежит операционная система, вернее, две ее версии: Windows 8 и Windows RT. Для большинства WinRT-приложений, поставляемых из Windows Store, разница будет незначительной, но важно помнить, что производительность ARM-процессоров и Intel/AMD-процессоров может заметно отличаться (хотя должен отметить, что отрисовка интерфейса в значительной степени лежит на GPU, а не CPU), что в свою очередь может сказаться на отзывчивости вашего приложения.

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

Наконец, на третьем уровне лежит постоянно растущая экосистема приложений, с которыми вам придется конкурировать за внимание пользователей. Часть из этих приложений может оказаться вам полезной.

Интеграция

Приложения для Windows 8 живут в песочнице, изолированно от операционной системы и других приложений. Однако платформа представляет вам некоторое количество специальных механизмов, позволяющих интегрироваться с ними на взаимовыгодных услови��х. Такие механизмы, как правило, называются контрактами и расширениями.

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

Общий доступ

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

Эта функциональность и потребность настолько важна, что в Windows 8 она обобщена и встроена на уровне операционной системы через чудо-кнопку «Общий доступ». Чтобы сработала магия общего доступа, нужны два игрока: приложение, которое делится информацией, и приложение, которое ее принимает. Ваше приложение может быть выступать как отправителем или получателем информации, так и сразу с обеих сторон.

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

Поиск

Еще одна важная потребность — искать нужную информацию. В Windows 8 решение задачи поиска информации также вынесено на уровень системы через соответствующий контракт. Например, если я хочу узнать погоду в Москве, мне достаточно вбить в поиск нужный город и выбрать приложение, в котором я ожидаю найти нужную мне информацию. Скорее всего, это профильное приложение, соответствующее поисковому запросу (т.н. вертикальный поиск), но также может быть и общее приложение для поиска, например, от Bing или Яндекса.

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

Люди и файлы

Другой пример. Если вы откроете приложение «Почта» (Mail), создадите новое письмо и попробуете добавить адресатов, нажав на плюсик, вы увидите перед собой специальный интерфейс другого приложения – «Люди» (People), которое в данном случае выступает поставщиком контактов. Почтовое приложение собственной адресной книги не имеет. Если вы поставите, например, приложение "Почта Mail.ru", то оно также сможет использовать в качестве адресной книги приложение "Люди", а также само выставить список контактов для других приложений.

Если вы в этом же почтовом приложении попробуете добавить к письму вложение, вам откроется интерфейс выбора файлов (File Picker). Интересной особенностью этого интерфейса является то, что поставщиком файлов выступает не только сама операционная система, но и другие приложения. Например, приложения "Камера" умеет выдавать файлы на лету, а приложения SkyDrive или Яндекс.Диск поставлять файлы из облачного хранилища.

Есть и много других сценариев интеграции с операционной системой и приложениями в ней.

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

Инструменты

Напоследок, чтобы сказка стала былью, несколько слов об инструментах.

Пользуйтесь шаблонами (как в Visual Studio, так и дизайнерскими для Adobe Photoshop), изучайте примеры и руководства по проектированию (ключевой сайт — design.windows.com) и научитесь работать с Expression Blend (для XAML или HTML) — это ваш главный инструмент для реализации интерфейса приложения.

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

Итоги

Подводя итоги, напомню еще раз базовые принципы проектирования современных приложений для Windows:

Будьте искусными в деталях. Помните о сетке и правильном использовании шрифтов, делайте удобным и безопасным. Приложение должно быть вкусным.
Достигайте большего меньшими средствами. Ставьте на первое место контент, расставляйте приоритеты и избавляйтесь от лишнего, скрывая или убирая вовсе.
Делайте по-настоящему цифровым. Пользуйтесь возможностями цифрового мира, не бойтесь вырваться за рамки физических ограничений, расширяйтесь с облаком.
Делайте быстрым и подвижным. Делайте приложение отзывчивым и динамичным, вдохните в него жизнь и актуальность, адаптивность к контексту.
Выигрывайте вместе. Windows и приложения для Windows – огромная экосистема, интернируясь с ней вы можете приобрести дополнительные преимущества.

Принципы дизайна приложений для Windows 8. Делайте быстрым и подвижным

Константин Кичинский — Wed, 07 Nov 2012 12:09:43 GMT

Продолжая серию статей про принципы дизайна для Windows 8, сегодня мы поговорим о важности скорости и отзывчивости.

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

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

Приложение должно быть шустрым, живым. Или, по крайне мере, казаться таковым.

Отзывчивость

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

Теперь, когда в обиход вошли устройства с сенсорным (прямым пальцевым) вводом, мы ожидаем, что интерфейс будет мгновенно реагировать на каждое движение пальцев по экрану, как это происходит в реальном мире, когда мы что-то трогаем. Если интерфейс не реагирует на наши движения, он кажется мертвым, хотя внутри компьютера это все те же команды, посылаемые на обработку в приложение.

Думая о приложениях для Windows 8, вы всерьез должны рассматривать сенсорный ввод как основной, не забывая, однако, о мышке и клавиатуре. Все операции должны быть продублированы для разных способов ввода.

Если элементы можно перетаскивать пальцами, они должны следовать без задержек за нашими движениями. Элементы должны реагировать на нажатие или выделение, подсказывать, что с ними можно что-то сделать.

Проектируя для пальцев, помните о том, что в Windows 8 есть свой язык жестов, которому д��лжны следовать все приложения, а также об общих соображениях о размерах целей, удобных для попадания пальцами (минимальный рекомендуемый размер – 7мм), и эргономичности размещения информации на экране, в том числе с учетом типичных способов держания различных устройств и характерных зон перекрытия.

Движение

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

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

Для того, чтобы однотипные задачи решались схожим образом и в разных приложениях для них применялись одинаковые анимации, в Windows 8 для разработчиков есть библиотека анимации (Animation Library) – набор методов внутри WinJS.UI.Animation для приложений на HTML/JS и набор классов в пространстве Windows.UI.Xaml.Media.Animation для приложений на XAML/C#.

Жизнь

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

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

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

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

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

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

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

Ключевой ресурс по дизайну для Windows — design.windows.com