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

Дизайн приложений для Windows Phone. Контрастность и доступность

Константин Кичинский — Mon, 30 Jan 2012 05:13:00 GMT

Цвета на экране и картинке могут отличаться от реальных и воспринимаемых.

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

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

Управление цветом

Люди, так уж сложилась наша природа, по-разному видят. Многим из вас, наверняка, знакомо такое явление как дальтонизм, при котором нарушается цветовое восприятие. По статистике, той или иной форме этого нарушения зрения подвержено около 8% мужского населения и 0.5% женского. И дальтонизм, естественно, далеко не единственное возможное нарушение.

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

Контрастность

Ключевым практическим параметром, на который можно опираться, является соотношение яркости между двумя цветами (например, между цветом фона и цветом текста) — контрастностью. Конкретный алгоритм описан в соответствующей рекомендации W3C — Web Content Accessibility Guidelines (WCAG) 2.0, которая хотя формально и содержит слово "веб" в названии, во многом применима и к другим направлениям, в частности проектированию мобильных и десктопных приложений.

Формула вычисления контрастности выглядит следующим образом:

(L1 + 0.05) / (L2 + 0.05), где

L1 — относительная яркость наиболее светлого цвета из двух,

L2 — относительная яркость наиболее темного цвета из двух.

Относительная яркость L определяется как взвешенная сумма линеаризованных компонент цвета (обратите внимание, что все коэффициенты различны):

L = 0.2126 * R + 0.7152 * G + 0.0722 * B, где

R = (R_sRGB <= 0.03928) ? R_sRGB/12.92 : ((R_sRGB + 0.055)/1.055)^2.4

G = (G_sRGB <= 0.03928) ? G_sRGB/12.92 : ((G_sRGB + 0.055)/1.055)^2.4

B = (B_sRGB <= 0.03928) ? B_sRGB/12.92 : ((B_sRGB + 0.055)/1.055)^2.4

и R_sRGB = R_8bit/256, G_sRGB = G_8bit/256, B_sRGB = B_8bit/256.

Согласен, навряд ли, вы возьметесь каждый раз вычислять это вручную, но, думаю, вам не составит большого труда записать формулу в Excel или, скажем, небольшой js-код. Впрочем, проще всего, воспользоваться готовым online-калькулятором, или специальным приложением — Colour Contrast Analyser.

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

Теперь, когда вы знаете, как считается контрастность, осталось понять, как ее трактовать. Прежде всего, из вида формулы должно быть понятно, что все возможные значения контрастности больше или равны 1 (записывается как 1:1). В этом случае цвет текста и фона совпадает и ничего не видно даже самому зрячему из нас. Максимальное значение (это не так очевидно) равно 21:1 и соответствует белому на черном или черному на белом. Все остальное — между 1:1 и 21:1.

В документе W3C выделяется два уровня контрастности. Минимальному рекомендованному (AA) соответствует контрастность 4.5:1 и 3:1 для крупного текста. Улучшенному (ААА) — 7:1 и 4.5:1, соответственно. (Эти требования не касаются неактивных элементов интерфейса, украшательств, логотипов и других подобных элементов.)

Как это знание применить при разработке интерфейса для Windows Phone? На самом деле, это достаточно просто. Давайте рассмотрим два ключевых сценария.

Темы и акценты Windows Phone

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

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

Первое, что вам должно броситься в глаза, это наличие не только зеленых значений (выше 4.5:1), но и заметной доли желтых (выше 3:1) и красных (все, что ниже). Оказывается, что не все сочетания акцентов и тем оказываются достаточно контрастными, чтобы удовлетворить рекомендациям. Как же так?

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

Это не только нормально, но и правильно (математику не обманешь — нельзя быть высококонтрастным и на светлом, и на темном одновременно). Обратите также внимание в таблице на 4-6 колонки, в которых приведено значение контрастности тех же акцетных цветов на светлом и темном фоне, но уже в случае различных типов дальтонизма. Вы легко можете заметить, что, например, бирюзовый (teal) на белом может неожиданно стать контрастным даже по критерию ААА, что очень здорово. То же самое верно и в отношении богатых на красный оттенок красного и мадженты (magenta) — их контрастность на белом в случае протанопии и дейтеранопии очень сильно повышается.

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

Собственные темы

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

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

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

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

Работа с текстом

Напомню кратко про контрастность текста, прежде, чем дать дополнительные рекомендации. Текст, как одна из основных форм передачи информации в Windows Phone должен быть контрастным. Согласно рекомендации, описанной в WCAG, есть два уровня контрастности:

Минимальный AA: 4.5:1 для обычного текста и 3.0:1 для крупного текста,
Улучшенный AАA: 7:1 для обычного текста и 4.5:1 для крупного текста,

Крупный текст — это все, что выше 18pt или 14pt при использовании жирного начертания (размер в пикселях может варьироваться в зависимости от конкретного шрифта).

Текст и изображения

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

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

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

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

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

Размер текста

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

Тут, собственно, нечего рассказывать кроме того, что минимальный рекомендуемый размер текста для Windows Phone — 15pt.

Если вам удобнее рассчитывать значения в пикселях, вот небольшая схема перевода для Segoe WP (коэффициент — 4/3):

Заключение

Проектируя приложения, пожалуйста, не забывайте о необходимости обеспечения хотя бы минимального уровня доступности вашего приложения для ваших пользователей. Минимальный шрифт — 15pt, минимальный контраст текста — 4.5:1, минимальный контраст иконок — 3:1. Лучше — больше.

[#MetroLynch] Forismatic

Константин Кичинский — Fri, 27 Jan 2012 18:13:00 GMT

В шестом метро-линче разбирается приложение Forismatic от Александра Заозерского – клиент для одноименного сервиса цитат.

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

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

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

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

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

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

Рекомендация: свести случайные цитаты и избранное в один Pivot-элемент:

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

Переходы между избранным и цитатами

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

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

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

См. также мою статью «Дизайн приложений для Windows Phone. Навигация. Уровни, назад и циклы».

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

При желании на страницу цитаты из избранного можно добавить кнопки «вперед»/«назад» для перехода по списку аналогично поведению приложения “outlook” при просмотре отдельных писем.

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

Настройки

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

Логика навигации должна быть однозначной: если я нажал настройки, значит, я попаду в настройки и только сюда. Чтобы почитать о приложении, я должен нажать где-то на пункт «о приложении».

Исправление: разбить pivot на две страницы, добавив в меню панели приложения пункт «о программе» (в дополнение к «настройкам») – см. картинку выше.

Дизайн

Иконки приложения

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

Исправление: сделать фон монотонным.

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

Стартовый экран

Стартовый экран приложения (он же Splash screen) содержит явные артефакты сжатия. Возможно, это также связано с использованием градиента в сочетании с 16-битностью режима рендеринга.

Исправление: повысить качество фоновой картинки на стартовом экрана. Как вариант, можно просто убрать градиентный фон. См. также статью «Дизайн приложений для Windows Phone. Практика. Градиенты и 16-битность».

Иконки и панель приложения

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

Общие требования к иконкам следущие:

Иконки представляют собой изображения 48х48px
Визуальная часть иконок (foreground) должна быть белой с прозрачной подложкой, причем она должна умещаться в квадрат 26x26px, и быть ровно по центру круга.

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

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

Рекомендация: для дополнительных тем можно настраивать цвет самой панели задач, сохраняя при этом контрастность иконок и фона панели:

С цветными яркими вариантами нужно быть осторожным, так как фактический контраст может оказаться невысоким (см. например, левый нижний пример – у него contrast ratio между цветом панели и белым цветом иконок 3:1, что представляется минимально достаточным для иконок в интерфейсе).

Нежелательность использования спецэффектов также применима и к иконке сердечка (для добавления в избранное):

Исправление: убрать излишние градиенты и неоновые эффекты:

Также, если это кнопка (а это кнопка), она должна выглядеть как кнопка в Windows Phone:

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

Также стоит обратить внимание на контрастность фона приложения и цвета панели приложения в ночной теме:

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

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

Контрастность текста

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

Рекомендуемое минимальное пороговое значение контрастности между текстом и фоном – 4.5:1.

Исправление: сделать цвет подписи с именем автора цитаты более контрастным.

О программе

На странице о программе (сейчас это часть пивота) в заголовке указана версия программы. Лучше в заголовке ограничиться названием, вынеся версию в описание.

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

Кнопки стоит использовать только для действий, причем название кнопки желательно делать с использованием глагола: «оставить отзыв» -- хорошо, «сайт приложения» -- плохо.

Исправление: заменить кнопку «сайт приложения» на явную ссылку на сайт http://forismatic.com, чтобы пользователю было очевидно, что произойдет после нажатия.

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

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

Выравнивания

Весь контент нужно выровнять по левому краю с одинаковым отступом на всех экранах (рекомендуемый отступ – 24px). Выравнивание по центру (в том числе вертикальное) нежелательно.

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

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

Список цитат

В списке цитат для разделения добавлены линии:

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

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

Брендинг

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

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

Функциональность

Информация об авторе цитаты

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

Удаление из избранного

(В версии 1.3 уже исправлено.)

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

Поиск

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

===

Это был очередной #metrolynch. Если вы хотите, чтобы ваше приложение также было подвергнуто публичному разбору, правила игры описаны тут.

p.s. Все мои оценки и рекомендации субъективны и не являются 100% верными решениями – все нужно тестировать и проверять на живых пользователях :)

Дизайн приложений для Windows Phone. Практика. Градиенты и 16-битность

Константин Кичинский — Thu, 26 Jan 2012 05:33:00 GMT

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

Хранение изображений

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

В принципе, некоторые артефакты в виде небольших полосок видны уже тут (это png), однако, смотрите, что происходит, если изображение хранится в jpg (100%, 80%, 50%):

Обязательно кликните, чтобы увидеть полные версии картинок. Заметили?

Теперь вопрос: если в jpg с градиентами получается хуже, зачем его использовать? Ответ кроется в двух важных аспектах. Во-первых, размер (да!) — это все еще актуально, и чем меньше общий размер вашего приложения, тем быстрее оно скачается на мобильное устройство и тем меньше трафика съест, что особенно критично, если он не безлимитный. Соответственно, если можно без потери визуального качества изображения вместо png использовать jpg, делайте это. Во-вторых, это производительность: скорость обработки jpg выше скорости обработки png. Если вспомнить, что для фоновых картинок в аскетичном Metro-дизайне специально отведено только два места (что, правда, не исключает, что их можно при необходимости использовать и в других): стартовый экран и фон панорамы, то станет понятно, что, учитывая критичность в обоих случаях минимизации затрат на рендеринг, выбора почти и не остается.

Кстати, именно поэтому единсвенный поддерживаемый по умолчанию формат для стартового экрана — это jpg. См. также раздел Images в статье Performance Considerations in Applications for Windows Phone.

Дизеринг

Но, при этом на градиентах в jpg мы стабильно будем получать полоски :) Впрочем, поискав в интернете по ключевым словам "banding", "gradients" и "jpg", вы легко найдете учебные статьи, рассказывающие о том, как с полосками бороться (например, раз и два). Основной вариант решения заключается в намеренном добавлении шума на изображении (т.н. дизеринг). Та же картинка, но с шумом (80% и 50%):

Windows Phone: 16 и 32 бит

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

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

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

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

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

Кстати, XNA для Windows Phone по умолчанию тоже использует 16-битный режим (со вторичным буфером в R5G6B5), что приводит к аналогичным артефактам при использовании градиентных текстур. Поэтому в играх тоже надо думать о том, чтобы 1) использовать 16-битные текстуры и 2) для градиентов использовать оптимизацию с применением дизеринга. См. также статью 16-bit Textures with Dithering.

Лечение

Это можно "лечить" двумя способами. Первый вариант: можно "форсировать" рендеринг приложения в 32-битном режиме. Для этого достаточно выставить в манифесте приложения параметр BitPerPixel="32":

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

Второй вариант: изначально готовить изображение, которое будет хорошо смотреться в 16-битном режиме (не путать с режимом 16 бит на канал вместо традиционных 8). Это не самая тривиальная задача, но можно найти более-менее работающие готовые решения, например, специальный скрипт (action) для Photoshop: Photoshop Action for Windows Phone 7 Dithering. Схема работы такого скрипта в общем-то сводится ко все тому же добавлению шума для сглаживания границ, но предварительно делается "коррекция" изображения с тем, чтобы уменьшить количество используемых цветов.

Для удобства, Adrian Tsai написал небольшую утилиту, которая делает практически то же самое, но без необходимости наличия Photoshop. C png результаты явно получаются лучше (png слева и jpg справа), что в общем-то объяснимо, учитывая особенности алгоритма сжатия:

Тут вы можете подумать, что проще использовать первый вариант, потому что все делается автоматически. На самом же деле, "это автоматически, но за вас". Именно за вас: в зависимости от устройства и драйверов это может быть не просто 32-битный режим, а некоторый алгоритм схожий с дизерингом, применяемый к кистям (brush) и изображениям. Вспомните также, с чего я начал обсуждение 16-битности? Она выгоднее с точки зрения производительности и общих соображений экономии ресурсов! Поэтому на практике, если в ваших изображениях для приложений на Windows Phone вы сталкиваетесь с подобными проблемами, вызванными переходом к 16-битному режиму, постарайтесь сделать максимум возможного, чтобы все-таки остаться именно в этом режиме.

Итоги

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

2. Чтобы уменьшить эффект полосок в градиентах, используйте дизеринг. Обычно, для этого достаточно применить фильтр, добавляющий шум (noise) — 1-2% для Photoshop.

3. Старайтесь оптимизировать изображения с градиентами под использование в 16-битном режиме, а не наоборот. То есть без острой необходимости, не стоит форсировать приложение работать в 32-битном режиме.

4. Помните о принципах Metro-дизайна — и не используйте градиенты без острой на то необходимости. То есть просто градиенты ради градиентов делать явно не стоит.

Дизайн приложений для Windows Phone. Навигация. Уровни, назад и циклы

Константин Кичинский — Wed, 18 Jan 2012 07:56:00 GMT

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

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

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

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

Метро-принципы

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

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

Контент должен ставиться во главу угла. Это означает две вещи:

во-первых, непосредственно сам контент представляет собой путь для погружения в детали (content not chrome) — для этого не нужны дополнительные обертки и кнопки вроде "прочитать подробнее";
во-вторых, нужно стараться избегать явных навигационных элементов, если это возможно. К примеру, не стоит переносить в мобильные приложения на Windows Phone аналогии навигационных меню сайта.

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

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.

— Susan Weinschenk, The Psychologist’s View of UX Design

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

Смотрите также мою статью про metro-подход в дизайне приложений.

Информационная карта, граф приложения и уровни

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

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

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

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

Граф

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

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

В большинстве случаев, приложение для Windows Phone должно проектироваться так, чтобы все переходы были только однонаправленными, то есть можно было бы только погрузиться в дополнительные детали или перейти к связанной информации. Все обратные переходы реализуются путем нажатия аппаратной кнопки "назад". Учитывая, что обратные переходы с одного экрана на другой фактически означают переход с нижнего уровня на верхний, количество уровней погружения с точностью до 1 равно количеству нажатий кнопки "назад", необходимых, чтобы вернуться с самого нижнего уровня на самый верхний. Например, на картинке выше уровней 4, соответственно, будет необходимо 3 раза нажать на кнопку "назад".

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

Повторю, максимум. На практике желательно обходиться 3-4 уровнями глубины.

Уменьшение глубины

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

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

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

Например, представьте, что фрагмент вашей схемы имеет такой вид:

Вам стало понятно, что у вас слишком много уровней в приложении и пользователю трудно выбраться наружу. Скорее всего, зайдя слишком глубоко, чтобы добраться до начальной страницы, часть пользователей может даже решить, что проще заново войти в приложение вместо того, чтобы 6 раз нажимать кнопку назад. (И они будут расстроены!) Что делать? В зависимости от конкретного содержимого, постарайтесь перестроить приложение:

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

Важно направление!

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

И это уже не совсем дерево.

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

Резюме

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

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

Циклы

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

Давайте сначала разберем простой сценарий создания цикла "на пустом месте".

Домой, домой!

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

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

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

Циклы в стеке навигации

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

Теперь вы добавили в этот стройный процесс хак:

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

Поэтому перепрыгивать через стек навигации плохо.

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

Но мне нужен быстрый переход!

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

Что делать в такой ситуации?

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

Что это значит? Фактически это означает, что вам нужно так изменить стек навигации в приложении, чтобы этот ваш прыжок был эквивалентен последовательным возвратам назад:

Это похоже на быструю перемотку назад по истории навигации.

Естественные циклы

Мой рассказ был бы неполным без рассмотрения еще одного сценария появления циклов: иногда они появляются естественным образом.

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

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

Означает, ли это, к примеру, что в таких сценариях нужно добавлять кнопку "домой" или, скажем, "искать", чтобы вернуться к одному из предыдущих экранов? Вообще говоря, нет! На самом деле, надо внимательно разобраться в двух моментах:

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

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

Типичное поведение пользователей можно понять, например, в процессе юзабилити-тестирования приложения или по обобщенным данным телеметрии. Например, если вы видите, что пользователь, чтобы вернуться в начало, выходит из приложения и заходит снова, это верный признак, что есть проблемы.
Во-вторых, надо понять, можно ли действие, ради которого пользователь возвращается наверх, перенести непосредственно в клубок? К примеру, два приложения социальной направленности: facebook и twitter. Оба имеют социальный граф и фактически предоставляют возможность довольно глубоко погружаться в клубке социальных связей.

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

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

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

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

Резюме

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

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

[#MetroLynch] New Year Gifts

Константин Кичинский — Wed, 28 Dec 2011 10:06:35 GMT

Праздник к нам приходит, Праздник к нам приходит… Пятый метро-линч разбирает новогоднее приложение New Year Gifts от ArtMosby.

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

Исправление: сделать панель приложения изначально видимой, перенести about в меню (прозрачность сохранить — иначе фон будет прыгать).

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

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

Контакты

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

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

Исправление: лучше всего, 1) вместо кнопки написать просто ссылку — твиттер: @artmosby и 2) сделать кнопку «рассказать друзьям», которая будет запускать стандартный ShareTask (ShareLinkTask или ShareStatusTask).

Адресат подарка

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

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

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

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

Переход к людям

При нажатии на человека в списке адресатов подарков не происходит никакой реакции, а сам переход выполнен просто в виде смены одного экрана другим:

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

Исправление: элементы списка должны реагировать на нажатие, для элементов списка рекомендуется использовать небольшие наклоны (tilt-анимация):

Рекомендация: для погружения в детали также следует использовать соответствующие переходы (continuum-анимация):

Замечание: для обоих примеров — см. как работает outlook.

Ввод данных

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

Рекомендация: убрать со страниц ввода данных фоновое изображение.

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

Исправление: сделать возможность быстрого переходя от одного поля к другому прокруткой всей области ввода и переход к следующему полю по нажатию return (см. как работает добавление новых контактов в people).

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

Дизайн

Выступающие хвосты слева

На некоторых экранах панорамы с левой стороны страницы выступают окончания предыдущей страницы:

В панораме должен выступать справа только фрагмент следующей страницы.

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

О приложении

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

В Windows Phone рекомендуется выравнивать весь контент по левому краю для создания явной иерархии. В данном случае два способа выравнивая явно конфликтуют между собой.

Исправление: выровнять весь контент, включая кнопки, по левому краю.

Светлая тема

Приложение не вполной мере переопределяет дефолтные значения цветов для системных контролов (поля ввода в активном состоянии, неактивные чекбоксы, панель приложения):

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

Как только в своем приложении вы решаете внедрять собственную тему, независимо от выбора пользователя (это не плохо само по себе!), на ваши плечи также ложится и контроль, что приложение будет выглядеть одинаково хорошо при всех сочетаниях тем и акцентов (см. например, статью “Windows Phone Mango Custom application Theme Step by Step”).

Исправление: использовать кастомную тему для системных контролов.

Карточка человека

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

При детальном рассмотрении оказывается, что надписи размещены несбалансированно: «куплен» смещена относительно иконки влево, «упакован» — вправо, а подпись к удалению вообще отсутствует.

Скорее всего, проблема изначально растет из неполной очевидности иконок (что делает галочка?) и далее необходимости добавления подписей, которая столкнулась с тем, что слово «упакован» слишком большое.

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

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

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

Выравнивание и отступы

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

Во-первых, это внутренние текстовые отступы в списках — они разные для разных элементов:

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

Рекомендация: я бы переименовал «для кого» в «кому», тогда, к слову, и значения полей будут на одном уровне.

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

Исправление: убрать линии и увеличить немного отступы между элементами списка:

Это же сглаживает проблему с внутренними отступами.

В-третьих, это висящие посередине элементов списка кнопки для управления состояниями подарков:

Все бы хорошо, кроме одного момента — заголовок (название подарка) тяготеет над кнопками. Что особенно хорошо видно при длинном названии: нижняя граница текста �� верхняя граница кнопки пересекаются.

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

Фон

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

Исправление: либо использовать 16-битную графику, либо явно прописать в манифесте приложения необходимость использования 32 бит (см. например, заметку “Enable 32-bit Color if Your Application Supports It”).

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

Время до Нового года

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

Во-первых, я снова про выравнивания:

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

Исправление: выровнять с заголовком по одной линии.

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

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

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

Функциональность

Упаковка некупленных подарков

Вот оно! Настоящее новогоднее волшебство! Конечно, можно предположить, что подарок уже может иметься из каких-либо других источников, давно куплен или вообще сделан своими руками, но... Есть в этом что-то неправильное:

Рекомендация: подумать над соблюдением логики «наличие подарка -> упаковка подарка», особенно, если указана цена подарка, отличная от 0.

Новые подарки в списке подарков

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

Исправление: отследить момент обновления списка.

Редактирование подарков

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

Исправление: добавить возможность редактировать подарки полностью, а не только флаги покупки и упаковки.

Перебор бюджета

Приложение спокойно позволяет перебрать отведенный бюджет:

Вообще говоря, понятно, что на счастье не экономят, но, возможно, с этим все же стоит что-то делать...

Рекомендация: ввести контроль расхода средств с мягкой нотификацией о перерасходе относительно отведенного бюджета (его, кстати, изменять тоже нельзя!).

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

===

Иконки рубля и гривны для приложений на Windows Phone

Константин Кичинский — Tue, 27 Dec 2011 22:19:00 GMT

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

В комплекте файлик для Expression Design и готовые иконки, которые можно использовать в приложении.

Rubles-w.png можно использовать в панели приложения:

Скачать: http://narod.ru/disk/35781907001/rubles-wp.zip.html

upd: Попросили добавить иконку для гривны:

Скачать: http://narod.ru/disk/35784234001/Grivna-wp.zip.html

HTML5INSIGHT #3

Константин Кичинский — Fri, 23 Dec 2011 23:47:00 GMT

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

CSS3

Canvas & Web APIs

Размышления о HTML5

Приятного чтения!

[#MetroLynch] .Phone Dialer

Константин Кичинский — Thu, 22 Dec 2011 12:10:00 GMT

Метро-линчи входят в предновогодний сезон, четвертой жертвой стало приложение .phone dialer от Алексея Страха и Александра Сороколетова.

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

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

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

Рекомендация: убрать из настроек все, что не относится к настройкам.

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

Дизайн

Выравнивали, выравнивали, да не выровняли

Я проверяю это очень просто: в угол скриншота ставится квадратик 24x24px и по его правой границе проводится линия. (Ну либо можно просто сетку с шагом в 12 или 24px сделать :)) Сразу видно, где правильно, а где надо поработать:

Исправление: сделать везде левый отступ в 24px.

Иконка приложения

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

Рекомендация:

Убрать подпись “wp7”, так как очевидно, что это приложение для Windows Phone, раз оно находится в Windows Phone Marketplace.
Перерисовать иконку, убрав лишние эффекты и полутона, например, вот так:
Постараться свести все иконки к некоторому единому знаменателю — очевидно, они не обязаны выглядеть полностью одинаковыми и отличаться только размером, но все-таки выдержать их в одном духе.

Далее, с иконкой приложения уже в самом телефоне тоже есть некоторые интересные нюансы, которые лучше поправить.

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

Во-вторых, круг. Круг — это не квадрат. Круглая иконка сильно выбивается на фоне всех остальных квадратных. Круглые иконки и иконки с круглыми краями делать не рекомендуется.

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

Рекомендация:

Сменить иконку.
Убрать круг.
Разобраться с фоном.

Настройки

Кнопка для обновления индекса контактов содержит в себе данные о последнем обновлении индекса, причем в русском интерфейсе форматирование даты некорректное:

Исправление: для русского языка выводить дату в формате 22.12.2011г. 23:45 или любом другом близком. Главное: никаких AM/PM и даты только через точку.

Рекомендация: вынести из кнопки дату последнего обновления, добавив соответствующую подпись:

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

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

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

Это же верно и для раздела «О программе» (см. ниже).

О программе

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

В Windows Phone есть несколько видов кнопок. Среди них в данном контексте нам интересны два: обычные и командные.

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

Исправление: заменить кнопки на обычные, либо для кнопок с пояснением использовать схему размещения текста для командных кнопок:

Меню приложения

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

Исправление: повысить непрозрачность фона.

История звонков

После попытки позвонить на набранный номер он неожиданно повис в списке без видимых способов убрать:

Авторы подсказали, что это история (журнал) звонков.

Исправление: добавить явную подпись, что это история или журнал звонков, тогда будет понятно, что это и не будет навязчивого желания что-то удалять:

Функциональность

Рассказать

Один из пунктов меню приложения предлагает расскать друзьям пользователя о замечательном приложении .phone dialer:

Правда, делает он это всегда на английском.

Рекомендация: для русского интерфейса выдавать текст на русском.

Звонок на набранный номер

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

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

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

Рекомендация: продумать более интуитивное поведение кнопки «звонить» в панели приложения. Например, если остался один номер, звонить именно на него.

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

===

Монетизация приложений — где деньги лежат, или почему это все реклама?

Константин Кичинский — Tue, 20 Dec 2011 22:06:00 GMT

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

Всем хочется кушать.

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

«Платные или бесплатные с рекламой?» — традиционно поднимаемый вопрос. И не случайно! Многие из нас помнят старые добрые времена, когда были десктопные приложения со встроенной рекламой — и сегодня они почти исчезли (как класс). Реклама в приложении кажется нонсенсом и неуважением к пользователю. К рекламе на веб-сайтах мы привычны, причем привычны настолько, что в основном привычны ее игнорировать — и воспринимаем как вполне нормальное проявление стремления владельцев сайта заработать на нем или, скажем, окупить хостинг.

Но реклама в (мобильном) приложении? «Фу!» — наверняка, скажете вы (как пользователь).

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

И они спрашивают у разработчиков, почему же те не вставляют рекламу. А разработчики говорят, что считают её противоестественной и им проще зарабатывать на платных приложениях. (Честно-честно, примерно так все и происходит.) А рекламщики в ответ: «Нууу, давайте считать...»

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

Или это все предубеждения и пора уже осваивать вставку рекламы в мобильных приложениях? Или платные приложений действительно тоже активно покупают?

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

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

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

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

Смотрите!

Бесплатное и расширенное платное

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

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

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

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

Возможно, вам даже будет проще думать о своих творениях не в терминах приложения “A” и расширенного “A+”, а в терминах приложений “A” и “B”, в одном из которых вы продаете рекламу другого.

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

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

Пример

gMaps и gMaps Pro — популярные картографические приложения на базе сервисов Google Maps. Первое из них бесплатное с рекламой, второе платное без рекламы и с расширенным функционалом.

Триалы и дополнительный функционал

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

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

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

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

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

Триал — это способ попасть на вашу дорогу.

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

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

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

В чем разница между платой за функционал и free+paid версиями? Ну помимо чисто технических различий реализации? На мой взгляд, есть два ключевых момента. С одной стороны, это как раз нюанс, указанный выше: бесплатное + платное более четко разделает, за что платит пользователь. Если вы оцениваете ваше полное приложение, скажем, в $2, то в случае триала это будет $2 за дополнительный функционал, а в случае платного — $2 за все приложение. С другой стороны, реализация в виде единого приложения со встроенной возможностью докупить функционал заметно ближе к пользователю, чем отдельное приложение с полным функционалом, и это должно давать большую конверсию.

На практике надо экспериментировать.

Пример

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

Подробнее о создании триальных приложений для Windows Phone читайте на MSDN.

Продажа контента

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

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

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

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

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

Продажа сервиса

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

Вы тут снова скажете, что это всего лишь клиент для сервиса — и будете правы, но…

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

Даже сам факт наличия лиента к вашему сервису в магазине приложений есть самое что ни на есть реклама сервиса.

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

Пример

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

Использование пользовательской базы

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

Как тут не вспомнить: «если вам что-то дали бесплатно, вполне вероятно, что продают не вам, а вас».

Вы, наверное, уже гадаете, что я тут могу нового рассказать, кроме вставки традиционных рекламных блоков, которые мы обсуждали в самом начале? Сейчас, сейчас…

Сценарий 1. Классика

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

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

Например, вы делаете геотаргетированный сервис, тогда ваше приложение может предлагать приложения, связанные с тем или иным местом (приложение конкретного ресторана, музея и т.д.).

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

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

Пример

Для вставки рекламы в приложение можно использовать как собственные, возможно, более контекстные и адаптированные специально под вашу аудиторию решения, так и готовые платформы вроде Microsoft Advertising (SDK, справка) или российского Begun.

Это классика жанра. Думайте, это все? Как бы ни так!

Сценарий 2. Брендирование и интеграция

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

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

Но для начала, конечно, вам потребуется популярное приложение или, что более вероятно, популярная игрушка.

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

Сценарий 3. Магазин контента

Как на счет продажи чужого контента в вашем приложении с соответствующими отчислениями?

Что? Вы уже продаете чужой контент, так как мы это уже обсудили несколько минут назад? Нет-нет. Мы говорили про ваш собственный контент. А вот что вы думаете именно о площадке с вашими пользователями для предоставления места для чужого контента?

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

Шире ассортимент — больше пользователей. И наоборот.

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

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

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

А могут быть и просто брендированные морковки для огорода…

Пример

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

Сценарий 4. Эксплуатация сервисов и бартер

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

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

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

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

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

пользователи платят премиум-услуги — например, увеличение сетевого хранилища (классика жанра — Dropbox),
пользователи самого сервиса видят рекламу и/или сервису нужна дополнительная аудитория или постоянное взамодействие с аудиторией (например, Twitter).

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

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

Возможно, есть какие-то интересные примеры, когда сервис будет вам доплачивать за использование его API, но мне такие примеры (кроме, собственно, вставки рекламы ) неизвестны. Если знаете, расскажите мне!

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

Бонус!

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

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

Табличка

Суммирая все сказанное выше, вот небольшая табличка:

	Свое	Чужое
Место	Free+ Paid: бесплатное приложение рекламирует платное.	Приложение рекламирует чужие приложения или предложения.
Функционал	Триальная версия рекламирует платный функционал.	В приложение интегрируется дополнительный «чужой» функционал, рекламирующий спонсора или необходимый пользователю.
Контент	Приложение продвигает дополнительный контент: статьи, книгу, морковку.	Приложение является площадкой для продажи чужого контента.
Сервис	Приложение рекламирует платный уровень вашего сервиса.	Приложение использует бесплатно чужой сервис, получая дополнительную ценность, или получает доход от продвижения сервиса.
Приложения	Разработка приложений для продвижения себя как разработчика приложений: трудойстройство или разработка приложений на заказ.	Магазин приложений с заработком на доле от продажи приложений или рекламы.

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

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

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

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

Заключение

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

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

Интервью Steve Kaneko /Microsoft Design Director/ о дизайне в Microsoft

Константин Кичинский — Tue, 20 Dec 2011 22:03:51 GMT

Книга-курс: Designing for Windows Phone

Константин Кичинский — Sun, 18 Dec 2011 19:47:32 GMT

Содержание:

METRO Design
Building WP7 Assets
Layout Controls in Expression Blend
Creating Animation & Basic Interactivity
Working with the Visual State Manager
Adding Data to your Application
Creating the Flickr4Fun app

Качать тут: https://www.facultyresourcecenter.com/curriculum/pfv.aspx?ID=8825

Почему иконки в панели приложения Windows Phone имеют круг вокруг?

Константин Кичинский — Sun, 18 Dec 2011 16:34:30 GMT

У меня об этом тоже спрашивают -- и вот вам ответ от Arturo Toledo (Sr. User Experience Designer at Microsoft for the Windows Phone Design
Studio):

Мы смотрим на них как на кнопки, а не иконки -- хотя я понимаю, что это не вопрос терминологии :) Это кнопки с маленькими иконками внутри. Метро-язык дизайна, предлагаемый Microsoft, несет в себе последовательный подход к отображению контролов-кнопок. Будь это обычная кнопка (Push Button), переключаемая кнопка (Toggle Button), командная кнопка (Command Button), кнопки медиа-плеера или кнопки-иконки (Icon Buttons) -- все они в метро-языке для Windows Phone имеют рамку, задающую их границу. Таким образом, кнопки-иконки в панели приложения просто следуют тому же языку, как и другие типы кнопок.

Мы запустили Metro-хаб на MSDN

Константин Кичинский — Fri, 02 Dec 2011 13:34:22 GMT

Друзья! Видя большой интерес к платформе Windows Phone и повышенный спрос на дизайнерские ресурсы, мы решили запустить отдельный центр на MSDN, посвященный именно вопросам metro-дизайна (короткая ссылка: bit.ly/metrodesignhub).

Сегодня мы выложили ссылки на основные видео-материалы, гайдлайны и шаблоны. В планах дополнительные статьи по отдельным аспектам дизайна для Windows Phone и Windows.

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

[#MetroLynch] Biorhythmics

Константин Кичинский — Fri, 02 Dec 2011 09:00:00 GMT

Метро-линчи продолжаются – и третьей жертвой стало приложение Biorhythmics от Oogway.

Навигация и управление

Список профилей

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

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

Подтверждение изменений в профиле

При редактировании или создании профиля в панели приложения появляются три кнопки: сохранение, отмена и удаление профиля.

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

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

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

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

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

Изменение «даты для отображения»

(Оставляя за рамками ревью выбор названия «дата для отображения»...)

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

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

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

Исправление: для выбора даты использовать иконку календаря , для выбора сегодняшей даты в идеале надо использовать решение, аналогичное выбору даты в приложении “Calendar” (Календарь) с отображением именно текущей даты.

Добавление первого профиля

При начале работы с приложением (или просто отсутствии людей в списке) пользователя встречает предложение добавить людей: «Необходимо добавить хотя бы одного человека. Изменить список людей».

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

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

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

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

Или все то же самое, но без подложки.

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

Исправление: убрать промежуточный переход.

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

Дизайн

Выравнивание элементов

При дизайне приложений для Windows Phone рекомендуется выравнивать элементы по левому краю со стандартным отступом в 24px.

Исправление: выровнять элементы на всех экранах, включая различные ориентации.

Выбор среза: плитки, список

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

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

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

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

Отображение выбранного среза

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

Рекомендация: сделать линию акцентным цветом.

Отображение текущего уровня

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

Если не вдаваться в теорию биоритмов, отрицательный уровень любого состояния — это большая непонятность. В идеале лучше делать нормировку от 0 до 100 или до 10.

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

Или без динамичного заполнения подложки, но с полной заливкой:

Человек в фоне

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

Большого смысла в этой фишке нет, но внимание она отвлекает.

Рекомендация: убрать человека в фоне :)

Иконка приложения

Иконка приложения что-то напоминает :)

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

Загрузочный экран

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

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

Функциональность

Прокрутка биоритмов

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

Рекомендация: сделать прокрутку потенциально бесконечной в обе стороны.

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

Биоритмы в дату рождения

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

Исправление: найти, в чем ошибка и исправить.

Дата для отображения

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

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

===

Дизайн приложений для WP7. Темы и акценты

Константин Кичинский — Sat, 19 Nov 2011 16:47:00 GMT

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

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

Скажем, сегодня у меня светлое весеннее настроение — и мой Windows Phone сегодня в белом с лаймовым акцентом. Или, скажем, вы девушка, сегодня вы в красном с темными оттенками — таким же может быть и ваш телефон — темным с красном акцентом.

Отображение цвета на экране монитора и экране телефона может отличаться.

Эта персонализация темой и акцентом является сквозной для всей платформы: от цвета тайлов до цвета системных контролов и ссылок. Стоит вам сменить цвет с magenta на teal — и многие элементы внутри Windows Phone подстроятся под ваше предпочтение. Это делает платформу живой и адаптивной.

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

Доступные акценты

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

Blue — rgb(27,161,226), hex(#FF1BA1E2)
Brown — rgb(160,80,0), hex(#FFA05000)
Green — rgb(51,153,51), hex(#FF339933)
Lime — rgb(162,193,57), hex(#FFA2C139)
Magenta — rgb(216,0,115), hex(#FFD80073)
Mango — rgb(240,150,9), hex(#FFF09609)
Pink — rgb(230,113,184), hex(#FFE671B8)
Purple — rgb(162,0,255), hex(#FFA200FF)
Red — rgb(229,20,0), hex(#FFE51400)
Teal — rgb(0,171,169), hex(#FF00ABA9)

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

Разработка и дизайн

С точки зрения разработки важно понимать две вещи:

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

Дизайнеру тоже есть над чем подумать:

Никто не обязывает вас использовать в вашем приложении текущую тему и акцентный цвет — это возможность подстроиться под приложение, но не догма и обязанность. Например, если вы посмотрите на офицальное приложение twitter, то независимо от настроек темы и акцента оно всегда выглядит одинаково — #33cсff (он же новомодный цвет твиттера) на белом. Каждый раз это ваше личное решение в поиске баланса между брендбуком или какими-либо другими ограничениями и стремлением к согласованности с персональными предпочтениями пользователя и интергацией в экосистему Windows Phone.
Если в дизайне вашего приложения вы начинаете использовать ваши собственные (фиксированные) настройки цвета, то это ваша личная обязанность: убедиться, что при разных настройках темы и акцента приложение остается удобным в работе (например, обеспечен достаточный контраст цвета).

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

С точки зрения инструментов обратите внимание на два важные возможности, которые вам предоставляет Expression Blend для работы с цветами.

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

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

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

Работа с тема��и и акцентами из кода

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

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

// Determine the visibility of the dark background.
Visibility darkBackgroundVisibility = 
    (Visibility)Application.Current.Resources["PhoneDarkThemeVisibility"];

// Write the theme background value.
if (darkBackgroundVisibility == Visibility.Visible)
{
    currentThemeTB.Text = "background = dark";
}
else
{
    currentThemeTB.Text = "background = light";
}

Аналогично, можно вытащить текущий акцентный цвет:

// Determine the accent color.
Color currentAccentColorHex = 
    (Color)Application.Current.Resources["PhoneAccentColor"];

Описание доступных системных ресурсов, можно найти в MSDN в статье Theme Resources for Windows Phone.

Тайлы

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

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

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

Резюме

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

#metrosovet

[#MetroLynch] Radar

Константин Кичинский — Mon, 07 Nov 2011 05:54:57 GMT

Метро-линчи (переименовал с подачи @mixen) продолжаются – и второй жертвой стало приложение Radar (Радар) от Sibity.

Навигация и управление

Панель приложения

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

Рекомендация: вынести эти кнопки в меню панели приложения, чтобы они не занимали свободное пространство.

Настройки

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

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

Авторы и ссылки на авторов

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

Рекомендация: заменить название раздела (включая ссылку из главного меню) на «О приложении», привести содержание в соответствие с названием.

Для раздела «Авторы» надо сразу показывать информацию об авторах, как вариант, раздел «О приложении» можно разбить на три вкладки пивота «О приложении» - «Авторы» - «Справка».

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

Исправление: заменить имена авторов с текста на ссылки:

Кнопки для ссылок

На экране «Авторы» кнопки используются для ссылок на внешний функционал – «обратная связь» (отправляется email) и «оставить отзыв» (открывается marketplace). Это вводит пользователя в заблуждение, так как кнопки должны обозначать действия совершаемые внутри приложения.

Рекомендация: заменить кнопки на ссылки (HyperlinkButton) и выровнять по левому краю, например, так:

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

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

Отправка сообщения об ошибке после сбоя

После сбоя (если о, ужас, такое случается) приложение предлагает рассказать о проблеме. Однако, кнопки «Ок» и «Отмена» не отвечают на вопрос «Хотите отправить отчет об ошибке?»

Исправление: изменить названия кнопок на «Да» и «Нет» или «Отправить отчет» и «Закрыть» — в общем, сделать их более понятными пользователю, либо адаптировать текст под варианты ответа.

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

Сообщения для пользователя

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

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

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

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

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

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

Дизайн

Выравнивание элементов

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

Исправление: необходимо выровнять элементы слева по заголовкам страниц. Рекомендуемый отступ от границы экрана — 24px.

На экране «Авторы» содержимое также необходимо выровнить по левому краю, это касается как надписи «кто они?», так и кнопок (про кнопки также см. дальше).

Рекомендация: на экране с радаром также желательно выдержать правый отступ от границы экрана в 24px.

Замечание: желательно также обновить скриншоты в marketplace: в доступном мне скриншоте экрана «Цели» выравнивание слева сделано верно в отличие от того скриншота, что размещен в магазине приложений. И наоборот: на экране с радаром отступы на скриншоте в маркетплейсе правильные в отличие от реального приложения.

На экране «Цели» пункты выбора новой цели должны быть визуально выровнены по вехнему краю со своими иконками.

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

На экране «Справка» пункты и текст должны быть визуально выровнены, как с заголовком экрана, там и между собой:

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

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

Иконки целей

Для иконок целей на странице «Цели» используется характерное изображение объекта в черном/белом круге. В Windows Phone такая визуальная схема распложения иконок используется для кнопок (см. например, кнопки в панели приложения). В итоге текущий вариант вводит пользователя в заблуждение — нажать можно на весь пункт, а не только на «кнопку с иконкой».

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

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

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

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

Экран настроек

На экране настроек отступы между различными пунктами меню отличаются: см. расстояние между «Единицы измерения» и «Определять направление по» и далее отступ между «Показывать путь» и «Звук».

Исправление: сделать все вертикальные отступы одинаковыми.

Замечание: также нежелательно делать подписи в две строчки (см. «службы определения местоположения»).

Наложение целей на экране радара

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

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

Функциональность

Добавление целей

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

«Другая цель» — это роспись в собственном бессилии указать все возможные цели.

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

Удаление целей

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

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

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

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

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

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

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

===

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

[#MetroLynch] TranslateThis

Константин Кичинский — Wed, 02 Nov 2011 14:27:00 GMT

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

Дизайн

Экран загрузки

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

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

Панель приложения

В панели приложения использует полупрозначный фон, однако, выставленный уровень прозрачности (непрозрачности -- opacity) делает панель в развернутом состоянии малоконтрастной, что мешает восприятию, особенно если в поле вывода (output) есть какой-то текст.

Исправление: убрать прозрачность совсем или уменьшить уровень прозрачности.

Выравнивание элементов

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

Исправление: выровнять элементы по левому краю на всех страницах.

Для экранов “history” и “favorites” оригинальный текст и перевод нужно также выровнять по левому краю.
Для экрана “gratitudes” сделать внутреннее выравнивание контента также по левому краю, выделив заголовок размером текста (двоеточние нужно убрать).
Иконка проигрывания текста на экранах “history” и “favorites” должна быть выровнена по верхнему краю с блоками текста, а не посередине как сейчас.
Подписи к текстовым блокам должны прилипать к ним, например, надписи “input text” и “result” надо опустить ниже — ближе к полям ввода.

Названия полей ввода

Поля ввода в приложении имеют гиковские названия input, output, result.

Рекомендация: переименовать их в более привычные для обычного пользователя (см. например, google translate или bing translate: from, to.

См. также следующий пункт.

Иконка воспроизведения текста на экране “translate”

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

Исправление: как минимум иконку нужно опустить ниже. Также ее можно разместить справа от поля ввода/вывода результата:

Экран “History”

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

Исправление: изменить отображение элементов списка. Схлопывать одинаковые запросы. Объединять переводы одного и того же слова на разные языки. Отображать языки перевода. Например:

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

Замечание: аналогично можно делать для экрана “favorites”.

Слишком длинные тексты для перевода

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

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

Длинные тексты также неадекватно отображаются в “history” и “favorites”, так как выводятся целиком, с повторами и большим шрифтом:

Исправление: см. выше в «Экран “history”». Рекомендую попробовать выводить только первую строчку на языке оригинала и при разворачивании элемента списка показывать уже текст целиком.

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

Функциональность

Проигрывание текста голосом

Повторное нажатие на кнопку проигрывания приводит к запуску воспроизведения текста голосом поверх уже проигрываемого. Аналогично с проигрыванием текста в истории или избранном.

Исправление: не запускать повторное воспроизведение до окончания проигрывания текущего ролика.

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

Замечение: это желательно протестировать на пользователях прежде, чем внедрять.

p.s. Google звучит как “Гоогле”.

Проигрывание текста на неподдерживаемых языках

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

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

Ввод текста

Клавиатура содержит кнопку “return”, по нажатию на которую очевидно должно что-то происходить, но ничего не происходит.

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

Панель приложения

В панели приложения используется иконка сохранения для добавления в избранное. Для избранного традиционно используется другая иконка.

Рекомендация: либо “favorites” — это не избранное, а список сохраненных переводов, либо должна быть другая иконка (звездочка)

Рекомендация: возможно, стоит подумать над тем, чтобы добавить возможность поделиться переводом с друзьями – см. ShareStatusTask. «Поделиться с друзьями» или «отправить перевод» вполне можно вынести в панель приложения соответствующей иконкой.

===

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

[Windows Phone #MetroLynch] Правила игры

Константин Кичинский — Tue, 01 Nov 2011 18:29:00 GMT

Друзья! У нас тут родилась прекрасная идея делать публичные ревью дизайна и удобства приложений для Windows Phone для тех, кто не боится правды и хочет сделать свое приложение лучше. Мне быстро сказали, что это "линч" и что это жутко интересно и полезно, поэтому идею решено воплотить.

Самое главное правило

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

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

Что нужно от вас

Для разбора приложения мне нужно само приложение -- ссылка для установки из marketplace. Также мне нужны будут скриншоты всех экранов, либо xap-файл, чтобы эти скриншоты можно было удобно сделать.

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

Что вы получаете

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

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

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

Как я буду работать

Заявки на линчевание принимаются на konkich [at] microsoft.com с темой "[WP7 App Lynch] Название вашего приложения"
Заявки принимаются только от авторов -- мне не интересно рассматривать чужие приложения без возможности пообщаться с автором, который может внести изменения
Я буду публиковать 3-4 обзора в месяц (при наличии желающих и времени), возможно чаще.

p.s. П��авила могут меняться на основании ваших отзывов.

Запись мастер-класса по дизайну приложений для Windows Phone

Константин Кичинский — Sun, 30 Oct 2011 14:37:00 GMT

Ура-ура! У нас готова запись моего мастер-класса по дизайну-приложений для Windows Phone.

Запись в двух частях:

Часть 1 (techdays, youtube)
Часть 2 (techdays, youtube)
Презентация

Где взять иконки для Windows Phone приложений?

Константин Кичинский — Sun, 23 Oct 2011 23:18:07 GMT

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

Стандартные иконки

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

Если вам требуется слегка изменить одну из стандартных иконок или вы хотите использовать их как фрагменты для ваших собственных, вы можете найти их в виде растра и вектора (ai) в папке C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v7.1\Icons.

Project: Windows Phone Icons

Windows Phone Icons – проект, цель которого собрать в одном месте иконки для Windows Phone, лицензируемые под Сreative Сommons. На текущий момент пакет содержит около 300 различных иконок.

Также дла вашего удобства доступны исходники, которые вы сможете редактировать в Expression Design. Кстати, на сайте проекта вы также найдете учебник по созданию собственных иконок.

The Noun Project

The Noun Project – это открытый для участия всех желающих проект, цель которого – собрать бесплатную коллекцию иконок, понятных каждому. Хотя данные иконкци и не предназначены сами по себе для Windows Phone, многие из них замечательно могут подойти.

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

MetroStation Icons Pack

MetroStation – проект Yanko Andreev (из Болгарии). Пакет иконок содержит около 200 различных иконок, выдержанных в metro-стиле для Windows Phone. Учтите, что иконки содержат круглую рамку и для использования напрямую непосредственно в панели задач не подходят.

(Для коммерческого использования иконок свяжитесь с автором.)

WP7.1 Application Bar Icons

WP7.1 Application Bar Icons -- коллекция иконок от Pedro Lamas, которые “извлечены из операционной системы”.

И последнее: не забывайте про лицензии, применимые к различным иконкам.

UX-гайдлайны для "Metro style"-приложений

Константин Кичинский — Sun, 23 Oct 2011 20:00:00 GMT

Если вы уже изучаете, как разрабатывать приложения для Windows 8, в блоге BlendInsider для вас собрана хорошая подборка ссылок на статьи в MSDN по проектированию дизайна: UX guidelines for Metro style app development.

Expression Design September 2011 Preview

Константин Кичинский — Thu, 20 Oct 2011 14:57:17 GMT

Кстати, если вы пользуетесь Expression Design, не забудьте попробовать сентябрьское обновление (знаю-знаю, уже скоро закончится октябрь, но лучше об этом написать, чем не написать).

В обновлении есть несколько очень приятных плюшек:

Import EPS files
Make multiple selection in the Layers palette
Retain the adjusted position of an object’s registration point.
Export documents to the SVG format

Скачать можно тут: http://www.microsoft.com/download/en/details.aspx?id=27579

Второй мастер-класс "Дизайн для Windows Phone"

Константин Кичинский — Thu, 20 Oct 2011 14:39:31 GMT

Друзья, хорошая новость :) Учитывая большой спрос, мы решили провести еще один мастер-класс по дизайну приложений для Windows Phone.

Основные темы:

Metro-дизайн, идеология и основные концепции
Особенности платформы Windows Phone c точки зрения дизайна и UX
Нововведения Mango-обновления, важные для дизайна приложений
Использование Expression Blend для разработки интерфейса
Классические ошибки в проектировании UI и UX приложений для WP7

Для участия требуется регистрация (само участие бесплатное): http://careerlab.ru/education/guru-academy/kichinsky/sem1/

Мастер-класс будет проходить 29 октября (суббота) в нашем московском офисе в Крылатском.

Если у вас есть вопросы или специальные пожелания к мастер-классу, их можно оставлять в комментариях.

appmakr: Как сделать приложение для Windows Phone за 10 минут и без программирования

Константин Кичинский — Tue, 27 Sep 2011 14:28:00 GMT

Что такое appmakr?

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

Как это работает?

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

Чтобы сделать приложение под Windows Phone, выберите соответствующую опцию:

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

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

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

Далее можно перейти к настройкам содержания (вкладка Tabs). Здесь можно скорректировать и добавить источники для контента (я добавлю RSS для постов и комментариев, а также RSS нашего твиттера Imagine Cup):

Следующий пункт — кастомизация приложения. Здесь можно изменить шапку приложения, а также поменять цвета:

Дальше остается добавить описание и во вкладке Publish сгенерировать приложение:

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

Готовый файл, генерируемый appmakr — это обычный zip-архив, который необходимо переименовать в xap-файл.

При большом желании приложение можно дополнительно настроить с помощью CSS и JavaScript.

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

Ссылка для загрузки: http://www.windowsphone.com/ru-RU/apps/4d7fd0e6-81f0-4cff-b8b0-b001bdeed765

Если вы хотите больше узнать про Metro-дизайн

Константин Кичинский — Thu, 22 Sep 2011 15:14:34 GMT

На прошедшей конференции Build было объявлено много нового и чрезвычайно интерсного. Записи сессий уже доступны для просмотра на Channel 9. Если же вы интересуетесь дизайном и хотите лучше понимать концепцию Metro, очень рекомендую вот эту сессию с первого дня конференции:

8 traits of great Metro style apps //by Jensen Harris

Также обратите внимание на доклад "Windows Phone user experience design" от Bryan Agnetta.

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

Дизайн приложений для Windows Phone. Контрастность и доступность

Управление цветом

Контрастность

Темы и акценты Windows Phone

Собственные темы

Работа с текстом

Текст и изображения

Размер текста

Заключение

[#MetroLynch] Forismatic

Навигация

Приоритезация действий в панели приложения

Переходы между избранным и цитатами

Настройки

Дизайн

Иконки приложения

Стартовый экран

Иконки и панель приложения

Контрастность текста

О программе

Выравнивания

Список цитат

Брендинг

Функциональность

Информация об авторе цитаты

Удаление из избранного

Поиск

Дизайн приложений для Windows Phone. Практика. Градиенты и 16-битность

Хранение изображений

Дизеринг

Windows Phone: 16 и 32 бит

Лечение

Итоги

Дизайн приложений для Windows Phone. Навигация. Уровни, назад и циклы

Метро-принципы

Информационная карта, граф приложения и уровни

Граф

Уменьшение глубины

Важно направление!

Резюме

Циклы

Домой, домой!

Циклы в стеке навигации

Но мне нужен быстрый переход!

Естественные циклы

Резюме

[#MetroLynch] New Year Gifts

Навигация

Добавление людей и подарков

Контакты

Адресат подарка

Переход к людям

Ввод данных

Дизайн

Выступающие хвосты слева

О приложении

Светлая тема

Карточка человека

Выравнивание и отступы

Фон

Время до Нового года

Функциональность

Упаковка некупленных подарков

Новые подарки в списке подарков

Редактирование подарков

Перебор бюджета

Иконки рубля и гривны для приложений на Windows Phone

HTML5INSIGHT #3

[#MetroLynch] .Phone Dialer

Навигация

Настройки, о программе и меню

Дизайн

Выравнивали, выравнивали, да не выровняли

Иконка приложения

Настройки

О программе

Меню приложения

История звонков

Функциональность