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

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

Допустим, у вас сложилась следующая ситуация: ваш дизайнер-проектировщик сидит в Фотошопе/Скетче/Иллюстраторе и создает общее стилистическое направление. Это хорошо, от этого никуда не деться, это основа профессии. Но результатом должны быть не макеты, а продукт. Чтобы бесконечное обслуживание однотипного дизайна не требовало огромных трудозатрат и разработчики сами могли справляться с этой задачей, ваши специалисты должны разработать спецификации. Спецификации это некий документ в confluence или любой другой wiki, который содержит следующие разделы:

Концепция экосистемы. Услуги, предоставляемые компаниями, многоканальные. Одновременно с этим все существующие устройства для предоставления услуг разные, обладают разными экранами и разными юзер-кейсами. Пример: у касс самообслуживания есть сканер, банковский пан-пин, фискальный регистратор, весы, люди смотрят на экран такого устройства урывками и линейная подача информации здесь неактуальна. Необходимы постоянные картинки, звуки при ошибках, голосовые подсказки, видео. Интерфейсы для автомобилей вообще не должны привлекать на себя внимание. На привычных рынках тоже полно нюансов, хотя Bootstrap и Foundation отлично решают часть задач, помогая в описании принципов дизайна в коде «живыми» гайдлайнами. Когда вы открываете сайт на мобильных платформах в некоторых браузерах, то вы не видите ничего, потому что разработчик/дизайнер сделал сайт на клиентском шаблонизаторе. А ничего на сайте не показывается потому что не работает динамический javaScript. Даже привычный иконочный шрифт (меняйте на SVG), скругленные уголки и градиенты не работают в прокси-браузерах. В браузерах на умных часах нельзя пользоваться клавиатурой (клавиатура используется на телефоне). Добавьте проблемы smartTV. Добавим людей, которые живут в mobile only. Мобильный сайт отличается не шириной экрана, он отличается другим поведением пользователя. Пользователь айфона нуждается в быстром получении информации. Если запланированы большие тач-экраны (Small kiosk или настенный дисплей), то важно учесть нюансы разворота экрана на 45 градусов для уменьшения внимания окружающих к вводимой информации, уменьшение важных данных вроде E-mail, чтобы издалека нельзя было различить. Учесть расстояние до экрана, размах движения руки.

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

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


Вводная часть.

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

Аудитория и персонажи

Цели и задачи аудитории, сегментация. Разработайте персонажей. Не зависимо от того, делалась сегментация по наитию или по математике, продумайте, какие пользователи будут пользоваться вашим продуктам. Не бойтесь доходить до крайностей в предполагаемом поведении пользователей, повесьте картинки с придуманными персонажами перед собой и проводите ресерч с оглядкой на этих персонажей. Вам нужны фотография, профайл, имя, национальность, возраст, личные качества, используемые операционные системы и экосистемы, цели, мотивация, подверженность общественному мнению, девизы по жизни. В общем вам нужен профиль из Вконтакте на человека. И не забудьте про вывод: этому чуваку нужен наш сервис, чтобы достичь желаемого результата. И пользоваться он им будет по определенному принципу. Например, агрегаторы магазинов нужны не только для того, чтобы сравнить товары, но и посмотреть скидки или убить офисное время. Нельзя забывать и про Customer development—тестирование идеи или прототипа будущего продукта на потенциальных потребителях. Много ресурсов не потребуется, так как для качественного исследования (не количественного) достаточно 6 +-2 респондента из целевой группы.

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

Нельзя забывать о незрячих пользователях, слабовидящих, дальтониках, с расстройством когнитивных функций или нарушением опорно-двигательного аппарата (это от 10% пользователей). Эти категории людей нацелена исключительно на контент, и получают его с помощью экранной лупы, только клавиатуры, экрана Брайля, аудио-читалок, шрифтовых и контрастных настроек. Фокус на полях обязательно нужно оставлять, оставьте outline в покое. Чек-лист для очистки совести перед заказчиком. tabindex делаем логичным и отрицательным. Дальтоники зеленый и красный цвета могут видеть одинаково, поэтому все ошибки нужно не только подсвечивать цветом, но и подписывать.

Бизнес и данные

Бизнес модель и бизнес-процессы. Используйте логотипы тех клиентов, кому доверяют. Проанализируйте все реальные таблицы, параметры, характеристики, XML/JSON с реальным контентом. В прототипе также должны быть только реальные данные. У ноутбука одни параметры, у смартфона похожие, но другие, и отображать фильтры по параметрам придется по разному. Нельзя забывать о доступности информации при выключенных картинках (alt для тех же незрячих пользователей), версии для печати.

Если продукт будет мультиязычным, нужно задокументировать на всех нужных языках ключевую информацию, которая будет использована в продукте. Не весь текст нужно переводить, названия мотоциклов и автомобилей не переводятся, города переводятся (Russia = Россия). Транскрипция недопустима. Важно понимать, что большая часть российской аудитории оценивает свой уровень знания английского как «ниже среднего» (по рейтингу EF EPI). Поэтому влияние непереведенного текста на понимание продукта может быть критичным.

Аналитика

Здесь собираем все отчеты, метрики, маркетинговые исследования, карточные сортировки, точки контакта, выводы. Гипотезы, описание, на какое состояние рынка аналитика производилась. Если вы сделали макет в Photoshop, то используйте sticky notes для указания краткого описания, почему принято то или иное решение, это нужно всей остальной рисующей команде и помогает в жарких спорах. Нужны продуманные сценарии, какой человек будет проходить сценарий (информация берется из раздела «Аудитория»), как будет работать кроссканальная конверсия. Так, нервный человек заслуживает оранжевую кнопку, так как это цвет спешки (см. фастфуды), а если человеку нужно все спокойное и вдумчивое, то цвет синий или зеленый.  Цель проекта и ожидания пользователя у нас уже есть, но реальные впечатления от пользования продуктом появятся много позже, выводы по которым тоже заносятся в раздел аналитики: что было хорошего и главное — что было плохого в продукте. Аналитику нужно собирать и хранить в том же amazon redshift, или просто в mySQL или даже в postgreSQL. Можно заложиться на использование рекомендательного движка. Наличие uml-редактора при аналитике спасает много жизней нервных клеток.

Концепция

Здесь описана ключевая идея продукта, информационная архитектура, общие принципы взаимодействия. Этот раздел описывает функции, уже с прототипами. Этот раздел должен идти перед описание UI kit, потому что в дизайне функции диктуют форму, а форма диктует цвет. Также, в этот раздел можно вынести совсем базовые вещи, например, сетку. Сейчас наиболее популярна 8-пиксельная, которую пропогандирует Google, 8-пиксельный шаг особенно удобен тем, что хорошо делится на 2. Например, можно получить 2-пиксельное скругление блоков или банально проще резать иконки pixel-perfect в векторе. iOS базируется на 11- пиксельной, Windows 8 – 5-пиксельной. Если запускать все продукты на базе одних и тех же компонентов, то помимо унификации мы получим еще и унылизацию – такие сервисы выглядят однояйцевыми. Поэтому платформа должна давать возможность стилизации продуктов без изменения общих принципов работы компонентов. Для мобильных приложений компонентами служат бандлы, т.е. распространяемые библиотеки с уже зашитым дизайном. DOC type используемый обоговорить с разработчиком, XHTML 1.0 или HTML 5. Если вы используете CMS, то нужно выбрать: wordpress /ModX это небольшие сайты и блоги, для порталов подойдет Joomla! и Drupal, соц. сети это Drupal и LiveStreet, интернет-магазины делают на Magento и Joomla!.

Логика стандартных функций

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

Экраны

Конечный дизайн продукта. Самый большой и трудоемкий раздел, более 70% всего документа. Разумеется, на этом этапе уже должно быть не только продумано, но и красиво. Ведь красота является одной из составляющих дизайна, которая вызывает у людей радость за счет воздействия на бессознательные установки. Прототипы это хорошо когда много денег и времени, или когда кейс совершенно не понятен (в тех же играх). Но прототип не является обязательной частью разработки. Если вы все же решились делать прототип, то он должен быть интерактивным и отвечать на конкретные вопросы. Для Photoshop: вы загоняете весь растр в smartobject, все размеры и все шрифты кратны двум (дизайнер выбирает размеры не на глаз, а по единым правилам), и вся другая графика в векторе, по крайней мере для адаптивных веб-сайтов (в дальнейшем вы сделаете SVG, внутрь которого при разработке можно поместить несколько растровых картинок). Экранов иногда приходится делать много: вы сделали экран 320px, и клиент говорит что на его современном телефоне все выглядит размытым, вы сделали для клиента экран 640px, и верстальщик ругается и требует 320px.

Тексты

Этот раздел содержит тексты для СМС, уведомлений, ошибок, подсказок, описывает стилистику языка и тон, настроения, степень панибратства по отношению к пользователю. На данном этапе кнопки уже должны быть масштабируемыми и гибкими, умещать текст, с учетом конфликта базовой линии шрифта  (overflow:hidden или vertical aligne: middle а на самом деле inline:flex, и все это в дополнительных обертках, генерированных через препроцессоры).  Никогда не пишите длинных текстов, 1000 символов — хороший формат. Больше одной запятой в предложении — это проявление особенностей клипового мышления. Люди готовы регулярно читать вашу текстовую рассылку, если в ней есть польза. Польза формируется в виде простой фразы: быстро узнать актуальные новости, лучшие фильмы в кинотеатре, скидки на интересующие товары. Если в аналитике вы видите, что человек прокручивает текст до середины экрана и водит по нему мышкой, значит текст был прочитал. Много сил отнимает проработка краевых состояний и выбор ограничений на кол-во символов, быстрая подстановка данных в интерактивный прототип позволит быстрее проверять их.

UI Kit

Этап визуального воплощения знаменитой фразы основателя Lotus Колина Чепмена: «Упростить, а затем добавить лёгкости». У нас есть набросанная широкими мазками общая архитектура проекта, а при отсутствии выдрюченного прототипа отсутствуют надуманные ограничения. Самое время делать дизайн. Создается одним из последних этапов и идет в портфолио в виде картинок, содержит информацию о полях, списках, переключателях, таблицах, диаграммах, толщине линий, цветовой палитре, методах передачи объема, правилах размещения в интерфейсе. К этому моменту интерфейсные иконки должны развиться в универсальный набор, должен быть разработанный гайд для создания новых иконок (углы линий, радиусы скругления, аллегории иконок). Иллюстрации и инфографика должны вписываться в общую стилистику, это нужно описать в виде стандартного ТЗ для иллюстраторов/дизайнеров. Все исходники должны быть готовы к локализации (текст не растрирован, шрифты приложены). UI kit это не просто файл с состояниями стандартных элементов интерфейса, а информация о задержке уведомлений, примерами ресайза элементов под разные разрешения и ориентации экрана.

В процессе разработки дизайнер обязан отлаживать код в браузере, devtools во всех браузерах примерно одинаковые и простые. Учитываем, как будут реагировать контролы на swipe, flick, drag, pinch и unpinch. Все вышеописанное можно назвать компонентным дизайном (методология БЭМ). Вы должны отказаться от растровой графики, ведь вектор хорошо поддается сжатию и масштабированию (sketch и illustrator). В все это обязательно должно вписываться в колоночную сетку. После завершения верстки можно прогнать сайт stylifyme и убедиться, что все соответствует гайдам.

Анимационная модель и интерактивность

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

Требования

Общие аспекты качества продукта. Описываются требования к материалам, к платформе, к дизайну, аллегориям иконок, представление по умолчанию (идеальный вид страницы). Необходимо описать всю дизайн-теорию, информационную архитектуру. Так что количество споров и ошибок по мелочам падает на порядок. Не забываем проверять верстку: как ведет себя макет при увеличении шрифтов, насколько точно сверстан дизайн (попиксельная верстка это извращение отечественных заказчиков). Расположение блоков, кроссбраузерность, микроблоки/microdata, WCAG2. Прописать, что тэги вроде header, footer, aside, section лучше, чем div. И мелочи, вроде logo = h1, на внутряках H1=заголовок контента,  Logo=div, реакция на :hover, :active и :focus, не забыть про favicon.ico (желательно с включенными внутрь неё 32×32, 48×48 и 64×64 вариациями) и apple-touch-icon, и так далее. Идеальный чек-лист верстальщика есть здесьОпытный дизайнер-проектировщик может задокументировать все вышеописанное за пять-семь нерабочих дней. Навыки аналитика обязательны.


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

И в заключении: тестировать тестировать тестировать, активно использовать эксперименты в GA с многоруким бандитом, никогда не закрывать GA debugger и GA tag assistant, использовать калькулятор, оттачивать дизайн, анимации…и вновь тестировать UI, JS, производительность, тестировать, тестировать. Управляйте процессами, а не креслами.

Референсы, как надо делать: Google Material, Universal Windows Platform, AppleIBM, Lighting, MalichimpGov.uk.

37 комментариев

  1. DimoDisa_84

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

    • your-scorpion (Author)

      Мне кажется, вы неправильно понимаете принцип проектирования макетов под разные плотности экранов для андроид. На телефоне размывается картина потому что у десктопных компьютеров ppi 100-110, 216 ppi у Nexus 7, а у iPhone 5 retina 326 ppi. Можно представить, насколько больше нужна картинка для корректного отображения на телефоне. Посмотреть ppi других девайсов можно по ссылке. Для iOS лучше смотреть здесь.

      Размер экрана: фактический физический размер телефона выражается в дюймах (1 дюйм = 2,54 см).

      Разрешение экрана: количество пикселей на экране. Чем больше пикселей, тем четче картинка. Популярные размеры это 480 x 800, 720 x 1280, 1080 x 1920. За основу для основного макета дизайнеру лучше взять 720 x 1280, либо с замахом на будущее 1080 x 1920. Допустимо рисовать макеты 360x640px, которые легко масштабируются до 200% DPI (720×1280), это HDTV стандарт. И до 300% ppi (1080×1920), это 1080p стандарт. 720 x 1280 эквивалентно 320 ppi, в рамках этой резолюции 1DP = 2px. Вот формула px = dp * (dpi / 160). При этом нужно понимать, что если приложение верстается под 320dp, то все будет достаточно хорошо в мультиконном режиме. Если под 360dp или 480dp, то местами текст может не влезть в кнопки.

      Нельзя забывать про особенности dp: если мы задали высоту кнопки 16 мм, то эта кнопка будет 16 мм на 4-дюймовом экране и на 10-дюймовом планшете. На огромном планшете она будет смотреться странно. Поэтому начиная с определенного размера надо придумывать отдельную логику, утолщать элементы, увеличивать отступы и т.п. для планшетов. За планшет принято считать все, что выше 7 дюймов, потому что говорить с этого устройства неудобно, и телефоном оно считаться не может. Поэтому отдельный дизайн под планшет крайне важен. Если ваше приложение просто растягивает свой контент с 3′ до 12′, то это ужасно.

      ppi это количество пикселей на дюйм экрана. Это значение есть и у экрана, и у операционной системы, и эти значения должны совпадать. Так, на моем маке 27″ ppi 109 = 109 пикселей на дюйм экрана. Поэтому, на экране с 109 ppi картинка будет меньше, чем на экране 72 ppi, аналогичная ситуация и с мобильными девайсами. На любом устройстве есть нативное разрешение, на которое и нужно ориентироваться.

      По шрифтам: прочитайте мой комментарий здесь. Рекомендуется использовать системный шрифт. В Andriod4.x и выше это будет Roboto, Android 2.x и Andriod 3.x используют Droid Sans. А для Азии Droid Sans Fallback :) Можно посмотреть в сторону Noto, ошибкой не будет.

      Есть рекомендации и по размеру шрифта для андроида: 12sp, 14sp, 18sp, 22sp.

      • Сигмиш Праум

        Максим привет! Скажи пожалуйста, с какими параметрами отправлять промо-картинки в аппстор?

        • your-scorpion (Author)

          До 5 скриншотов на каждое разрешение экрана (PNG без прозрачности или JPEG).
          iPhone:
          4,7-inch Разрешение 1334 × 750
          5.5-inch Разрешение 1242 x 2208 (его бывает достаточно)
          4-inch Разрешение 1136 x 640
          3.5-inch Разрешение 960 x 640

          Размеры скриншотов iPad:
          1024 x 768 pixels
          2048 x 1536 pixels
          768 x 1024 pixels
          1536 x 2048 pixels

          • Димирича

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

          • your-scorpion (Author)

            Для всех устройств Apple? От Apple Watch до iPad Pro, с учетом tvOS?

            Несколько основных тезисов:
            — способы ввода данных на iPhone и iPad одни и те же + Apple Watch использует касания и Digital Crown, Apple TV управляется пультом вместо манипулирования рукой по экрану. Конечно, Apple Watch имеет Force Touch, но общее ощущение от выполнения работы на устройстве остается все то же, что и на iPhone;
            — iPhone 6 Plus в ландшафтной ориентации подражает iPad;
            — режим Split View в iPad очень похож на удлиненный iPhone.

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

            По размерам: 320 x 568 pt (iPhone 5), 320 x 480 pt (iPhone 4), 375 x 667 pt (iPhone 6), а также 414 x 736 pt (iPhone 6 Plus). iPad это 1024 x 1366 pt (iPad Pro) и 768 x 1024 pt (iPad). С появлением дисплеев Retina, 1pt стал 2 px. Так что точки это отображение на iPhone, а пиксели это значения точек в зависимости от плотности пикселей.

            Приложение для Apple Watch это дополнение к основному приложению на iOS. Apple Watch имеет два размера, 38 и 42 миллиметра, соответственно, два разных разрешения экрана. Колесико позволяет интегрировать интересные навигационные механики, акселерометр и гироскоп есть, но уступают по своей крутости аналогичным датчикам из iPhone. Красивая графика и Apple Watch не всегда совместимы, так как есть ограничение до 50 мб на одно приложение. Многие пользователи расценивают часы исключительно как аксессуар для уведомлений, но в Apple Watch можно внедрить и функционал приложения. В этом случае ретеншн должен неплохо подняться.

          • Виктория

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

          • your-scorpion (Author)

            Всегда пожалуйста! В первую очередь, нужно сделать хороший продукт и почаще его обновлять, это первостепенно. Если речь об играх, то отзывы лучше читать в Steam, а не в Apple Store и Google Play.

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

            Скриншоты тестировать очень просто: делаете рекламу на том же фэйсбуке из скринов и смотрите, что конвертируется лучше всего для вашей аудитории. Запускать проект лучше не в выходные, а в понедельник/вторник (если интересует платящая аудитория).
            — описание никто не читает, Apple даже не показывает описание на первом экране, Google показывает только две строки описания.
            — размер приложения играет роль, так как если приложение больше 100 мб, то все сторы предлагают его скачивают только по wifi.
            — пользователей отпугивает большая цена (как ни странно), так что надо мигрировать во фримиум и рекламу.
            — чем больше языков, тем лучше.
            — очень помогает выклянчивание отзывов: просим дать оценку внутри приложения, если пользователь укажет 1-4 звезды, отправляем в саппорт, если 5 звезд, то отправляем в стор.
            — наличие версии для Apple Watch немного помогает в продвижении, но незначительно.

            Ну и всякие мелочи, вроде классического времени для скриншотах на iOS 9:41, отсутствие статус-бара.

          • Александр

            Есть ли нечто похожее для игр?

          • your-scorpion (Author)

            Делайте проект под 16:9, причины очевидны. Активная зона 4:3, остальное декорации. В 16:9 видно все. 16:10 обрезана часть декораций. В 4:3 будет видна только активная зона, в 5:4 видна та же активная зона, только немного сплющена аспектом камеры по горизонтали.

      • Oleg Butrin

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

        • your-scorpion (Author)

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

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

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

      • Boris Romanov

        Значения экранов андроида в dpi фиксированные всегда, это какое то правило от производителей?

        • your-scorpion (Author)

          Стандартным считается 4,6″(2,25×4″), что эквивалентно 720×1280 (HD) для 320dpi, нестандартные значения dpi встречаются редко.

          Но все же находятся и такие: Nexus 5x 420 dpi, Nexus 6 и 6p 560 dpi. Также, в Android 6/7 можно сменить плотность пикселей. Например, на Nexus 5x в настройки вынесены dpi: 356, 420 (по умолчанию), 460, 500 и 540. Из нестандартных значений наиболее популярно 5,25″ (2,57×4,57″), оно встречается и для 420, и для 560, и эквивалентно 1080×1920 (FHD). Из проблем нестандартного dpi можно назвать некорректную отрисовку интерфейса в некоторых приложениях, и растровая графика будет взята из другого разрешения и отмасштабированна.

          Для dpi 420 и 560 получаются числа в пикселях 2,625 и 3,5 соответственно. Если вы уже делали приложения для Android, то знаете о проблеме с нарезкой hdpi графики с ее 1,5 пикселям при плотности 240 dpi. Аналогичные проблемы вас будут ждать и при работе с нестандартными dpi.

    • tigr3hok

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

      • your-scorpion (Author)

        Многие пользователи почти полностью перешли на ретину и 4k, и когда они сталкиваются с обычным fullHD, то испытывают культурный шок. В 4K антиалиасинг в играх перестает быть проблемой. У многих уже Ultra High Definition (UHD, 4K, 3840x2160px). Но тем не менее, еще лет 10 большинство людей будут сидеть на full hd.

        Вот список популярных разрешений, которые я встречаю в статистике по всем кроссплатформенным продуктам, которые делаю на данный момент:
        ▪ Standard Definition (SD) 720 × 480
        ▪ qHD 960 x 540 pixels
        ▪ HD 1280 × 720
        ▪ Full HD 1920 × 1080
        ▪ 2K 2048 × 1152
        ▪ Quad HD (QHD) 2560 × 1440
        ▪ Quad Full HD (QFHD)/Ultra HD 3840 × 2160
        ▪ 4K 4096×2160

  2. Екатерина

    Здравствуйте! Скажите, а вы делали проекты для Sailfish OS? Я раньше проектировала интерфейсы для android, и эта новая ОС совсем непонятная. Есть какие то общие взаимозаменяемые паттерны для этих двух платформ?
    И какие еще интересные операционные системы можете порекомендовать посмотреть?

    • your-scorpion (Author)

      Да, сразу нужно учесть, что в Sailfish OS нет физических кнопок на девайсе, поэтому управление основано на жестах и это реально круто. Взаимодействие с телефоном происходит быстрее и проще.
      Для иконки приложения нужны следующие форматы: 86×86 108×108 128×128 256×256. Гайды для иконок есть.

      Android не особо похож на Sailfish. Но если вам доводилось делать макеты для WinPhone 7-8, то будет проще. Ключевые моменты:
      ‒ Pull Down Menu не должно содержать более трех пунктов. Потому что если будет больше 3-х пунктов, то в портретной ориентации 4-го не видно.

      ‒ Так как физических кнопок нет, кнопку «Назад» нужно располагать в Dcked Panel или Pull Down Menu.

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

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

      А из других ОС, посмотрите на IRIX. Операционная система для самолетов. Tizen для носимых устройств и LG webOS (круглые экраны).

  3. Виктор @matukGames

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

    • your-scorpion (Author)

      В Confluence заметно удобнее структура хранения, редактирования и просмотра документации. Очень удобные кроссылки, есть всякие uml-плагины вроде Gliffy, удобно вставлять картинки. Можно внедрить почти любой документ, pdf, doc, xls, ppt и даже Google Docs. Полная синергия с Jira.
      В Google Docs лучше реализованы комментарии, есть функционал предложения правок. И есть совместное редактирование. Более менее удобные таблицы.

      А использовать в продакшене надо Confluence+Google Docks. Это позволяет хитро обходить ограничения, например, можно встроить Гугл Таблицу в страницу вики, и совместно редактировать.

  4. Cherrysh

    Срочно! Какого размера иконки для андроида резать?

    • your-scorpion (Author)

      Обычные иконки для бара и пунктов меню:
      • MDPI: 48×48
      • HDPI: 72×72
      • XHDPI: 96×96
      • XXHDPI: 144×144
      • XXXHDPI: 192×192

      Если размер ассета 48 x 48 px, иконка должна быть в районе 32 x 32 px.
      48px = 13mm на экране 135 PPI.
      ПОДРОБНЕЕ

    • wemakesound

      Эти размеры точные или могут варьироваться в зависимости от положения на экране?

      • your-scorpion (Author)

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

  5. Николай headcrab-in-my-room

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

    • your-scorpion (Author)

      Если вы имеете ввиду мобильные приложения, то да. Не на всю Юго-Восточную Азию, конечно, только Китай, Япония и Корея. Основная особенность это запрет Google Play в Китае и общая волатильность рынка Китая. Зато у китайцев есть пара сотен локальных магазинов, с которыми можно договориться. Основные магазины это 360 Mobile Assistant, YingYongBao (Tencent), Wan Dou Jia (Pea Pod), Baidu Mobile Assistant и PP Assistant. Обычно доход делится 50/50 между разработчиком и магазином. Вы передаете магазинам локализованный для Китая APK, договариваетесь о категориях, рейтингах, обсуждаете, какие плюшки вы можете получить от магазина за право опубликовать приложение первыми. Принято нанимать местного партнера для вывода приложения на Китайский рынок, но очень важно контролировать его работу. Например, в процессе перевода слово «Валенки» может превратиться в «сапожки», и визуальный ряд тоже потребуется перерисовывать.

      App Store в Китае есть, и занимает всего 27% рынка. Внешне все достаточно просто: перевести тексты и подключить UnionPay для оплаты. Можно повозиться и внедриться в экосистему местных крупных игроков (мне доводилось работать только с WeChat). Минус экосистем—ваше приложение обязано быть эксклюзивным для одной из трех ведущих платформ.

      Языки разные. Так, в Китае и Сингапуре это Simplified Сhinese. В Тайване, Гонконге Traditional Chinese. Китайцы, которые живут за пределами Китая, иероглифы не учат.

      Выложить приложение мало, надо его рекламировать. Общие правила маркетинга работают и для поднебесной, всякие скидки 50%, 20%, 5%, уникальный контент. Но культурные нормы сильно отличаются, особенно цвета и шрифты, их надо изучать. Так, иероглифы весят больше, в латинице один символ равен одному байту, в кириллице двум байтам, один символ китайского языка вполе может занять все 4 байта. Я использовал упрошенную версию шрифта, и она все равно заняла около 20 мб. Социальные сети являются проблемой, так как Facebook или Twitter в Китае заблокированы, а VPN для большинства жителей слишком дорогое удовольствие. Поэтому авторизироваться через стандартные социальные сети не выйдет, но существуют локальные игроки, которые дают возможность авторизации через свой сервис: WeChat и Weibo.

      За все вышеперечисленные страдания вы можете получить доступ к рынку с ARPU выше, чем в США (исключение: детские игры не монетизируются). Нужно еще уточнить, что именно вы имеете ввиду под азиатскими рынками. Корейцы очень любят музыкальный контент, турки очень ценят приложения для развития детей, китайцы обожают показывать свой статус.

  6. Вячеслав Гончаров

    Где то в спецификациях для продуктов под ios пишут про точки, а где то про пиксели. Где правда?

    • your-scorpion (Author)

      В теперь уже далеком 2007 году компания Apple презентовала миру iPhone с 3,5-дюймовым дисплеем с разрешением 320 × 480. Это разрешение экрана актуально для IPhone 3G. Для этого девайса были актуальны пиксели. Но в iPhone 4 с ретиной разрешение было увеличено вдвое, до 640 × 960 пикселей. Таким образом, одна точка соответствует двум пикселам для ретины.

      Ответ на ваш вопрос: точки делают жизнь разработчиков проще. Разрешение экрана вновь увеличилось до 1280 × 1920 пикселей (320 × 480 для iPhone 4/4S или 320 × 568 для iPhone 5/5с), но этот переход между точками и пикселами обрабатывается системой.

  7. Vlada Orlova

    Добры день. У нас тут затеялся cпор на работе, есть ли смысл использовать QR коды, или это пережиток прошлого? У нас в офисе ни у кого нет ридера кодов в телефоне.

    • your-scorpion (Author)

      Это зависит от страны, для которой вы собираетесь использовать QR-код. В США и европейских странах коды не прижились, но в Китае используются повсеместно, особенно в WeChat (благодаря встроенному сканеру кодов). В Китае QR-коды можно встретить везде, они используются для покупок, ссылок, подарков. Так, в некоторых заведениях с музыкой можно отсканировать QR-код с публичного экрана, и выбрать следующую песню. Также, QR-код может служить билетом в кинотеатр, в поезд или в музей.

      Китайские платежные сервисы WeChat Pay и AliPay благодаря быстрой генерации QR-кодов для оплаты смогли создать сильную альтернативу POS-системам. Покупатель просто сканирует код и автоматически производится оплата. Продавец тоже может просканировать код покупателя и получить деньги со счета покупателя. Также возможно переводы оффлайн-компаниям.

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

  8. Mic Sachkov

    Скажите, а какого размера favicon нужно делать? Вы перечислили не все, их правда нужно так много?!

    • your-scorpion (Author)

      Достаточно двух. Остальные размеры браузеры сделают сами.
      Первая favicon.png в размере 32x32px.
      Вторая favicon-180×180.png в размере 180x180px.

  9. winwin.studio.

    Здравствуйте. Возник следующий вопрос.

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

    • your-scorpion (Author)

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

  10. Вячеслав Бердников

    В начале статьи Вы перечислили множество платформ. такой опыт впечатляет, но все платформы очень разрозненны, такое разнообразие мешает вести единую линию бренда компании сквозь все платформы. Рынок по прежнему идет к mobile first и со временем телефоны решат эту проблему?

    • your-scorpion (Author)

      Рынок не движется к Mobile First, он уже давно там. Более того, он уже Mobile Only. Для примера, на одном из моих enterprise веб-сервисов фаблеты занимают 60% +, при этом сессий больше всего на iPhone 5S. Думаю, требуется подробно рассказать, что означает Mobile, так как это далеко не только iOS и Android.

      Я работаю в индустрии мобайла с самого начала, осваивал работу со сторами, до выхода первого iPhone пилил WAP-сервисы. Но в последние годы все усложняется, так как платформа теперь это не только мобильное устройство. Ваш продукт должен уметь принимать абсолютно любую форму, ведь Facebook, Instagram, WeChat, Opera, Twitter, YouTube теперь тоже платформы. И они создают технологии для комфортного UX пользователя в рамках их экосистемы, Facebook’s Instant Articles, AMP, Progressive Web Apps, Android Instant Apps, все эти технологии помогают пользователю жить в рамках экосистемы платформ Facebook, Google, etd.

      Мессенджеры это тоже отдельная платформа, быстро развиваются и генерят огромный трафик. У них появляются даже собственные сторы. В некоторых странах, таких как Китай и Иран, мессенджеры это больше 1/3 интернета.

      Если ваш сервис не входит в 3-5-7 наиболее часто используемых приложений на смартфоне, возможно, ваша платформа не iOS или Android, а крупные вендоры. И для вас Mobile First это не только приложение в сторе, но и полноценное присутствие во всех значимых сервисах.