В настоящее время департамент мобильной разработки Rambler&Co активно расширяется, в том числе и в плане iOS-разработчиков и UX дизайнеров. Большое количество людей и проектов, ведущихся ими, усложняет и без того непростой процесс передачи дизайна разработчикам. Всем, так или иначе связанным с мобильной разработкой, знакомы проблемы и разногласия, возникающие на стыке интересов программиста и дизайнера — начиная тем, в каких единицах измерять расстояния, и заканчивая тем, кто должен нарезать элементы экранов в различных разрешениях. Чтобы окончательно решить проблему в рамках нашей компании, мы решили подготовить подробные гайдлайны по этому взаимодействию.
Главный тезис: Дизайн приложения считается законченным только тогда, когда разработчику переданы следующие материалы:
- Карта экранов приложения,
- Карта цветов, используемых в приложении,
- Список шрифтов, используемых в приложении,
- Размеченные состояния каждого из экранов,
- Нарезка элементов для всех экранов,
- Видео/gif со всеми нестандартными анимациями,
- Иконки приложения.
Теперь поочередно пройдемся по всем обозначенным пунктам.
1. Карта экранов
Карта экранов содержит в себе все экраны приложения и все возможные переходы между ними. Для каждого из переходов должно быть строго обозначено действие, инициирующее его (к примеру, нажатие кнопки или определенный жест пользователя). Каждый из экранов должен быть определенным образом обозначен (порядковый номер, название, код). В дальнейшем именно это обозначение используется в качестве ссылки на этот экран (к примеру, при наименовании папок, содержащих нарезку ресурсов).
Так как это обозначение может использоваться в названиях файлов и папок, то оно должно отвечать следующим условиям:
- Только латиница, цифры и знак "-",
- Только нижний регистр.
Чего не должно быть на карте экранов:
- Разметки элементов каждого экрана,
- Различных состояний одного и того же экрана (экран с нажатой/не нажатой кнопкой),
- Списка цветов, шрифтов и прочей служебной информации.
Отдельно стоит упомянуть, что интерактивный прототип приложения в Invision или других сервисах ни в какой мере не заменяет карты экранов.
Формат: png, jpeg, pdf.
2. Карта цветов приложения
Карта цветов — это изображение, содержащее список всех цветов, используемых в приложении (как многократно, так и единоразово).
Каждый из цветов должен быть представлен следующими данными:
- Кодовое название цвета,
- Метка, окрашенная текущим цветом,
- Числовое значение цвета: HEX или RGB.
В идеале, код цвета — число или короткое слово. Эти коды используются при разметке экранов для обозначения используемых цветов.
Формат: png, jpeg, pdf.
3. Список шрифтов приложения
Список шрифтов представляет собой текстовый документ, в котором перечислены все использующиеся в приложении шрифты. Указывается только название шрифта; размер в данном случае писать не нужно.
Если предполагается использовать нестандартный шрифт, он должен быть приложен к набору предоставляемых документов.
Список стандартных шрифтов представлен здесь.
Формат: txt, doc, pdf (для списка шрифтов). ttf/otf для нестандартных шрифтов.
Пример списка шрифтов:
- HelveticaNeue Regular,
- HelveticaNeue UltraLight,
- SuperHipsterFont (этот шрифт прикладывается отдельно).
4. Разметка состояний экранов
В большинстве случаев каждый из экранов может находиться в различных состояниях. Каждое из таких состояний, в том числе и основное, должно быть представлено в отдельном файле.
Представим, что мы размечаем экран списка сообщений электронной почты. Он называется «messages-list-screen”. Ячейки на этом экране могут находиться в трех различных состояниях — они могут быть не выделены, выделены и сдвинуты вбок. В таком случае требуется предоставить три различных файла:
- messages-list-screen-default.png,
- messages-list-screen-selected.png,
- messages-list-screen-swipe.png.
Наименование каждого из файлов должно включать в себя название экрана, используемое на карте экранов, и обозначение состояния (default, selected и пр). Полная разметка требуется только для default состояния. На остальных файлах размечаются элементы, уникальные для этих состояний.
Что включает в себя разметка экрана:
- Все расстояния и отступы между элементами,
- Размеры элементов (высота/ширина),
- Названия элементов (соответствующие названию нарезанного ресурса),
- Радиусы скругления углов,
- Названия и размер используемых шрифтов,
- Коды встречаемых цветов (соответственно карте цветов).
Все размеры указываются в не в пикселях, а в пойнтах. Если приложение должно выглядеть по разному на различных экранах (iPhone 5/iPhone 6), требуется предоставлять разметку для всех случаев.
Про отличия пойнтов от пикселей и размеры экранов различных устройств хорошо написано здесь. Также, чтобы иметь представление об адаптивной верстке, стоит прочитать эту статью.
Формат: png.
5. Нарезка ресурсов
Нарезать требуется следующие виды ресурсов:
- Иконки (кнопки, индикаторы, стрелки и пр),
- Фоны,
- Сплеш-скрины (если они есть).
Все ресурсы предоставляются в трех размерах — стандартном (соответствует размеру, указанному на разметке экрана в пойнтах), @2x и @3x.
Все взаимозаменяемые ресурсы должны быть строго одного размера. Под взаимозаменяемыми понимаются такие изображения, которые могут быть подставлены на место друг друга. Как пример — кнопка в NavigationBar’е, которая в одних случаях представляет собой значок карты, в других — лупу.
Нарезанные ресурсы должны располагаться в папках, названия которых соответствуют названию текущего экрана (не состояния, а именно экрана). Разбивать в отдельные папки исходя из размеров ( @2x, @3x) не нужно.
Основные правила по наименованию нарезанных изображений:
- Только латиница,
- Вместо пробелов используется -,
- Только нижний регистр.
Если у элемента есть несколько состояний (к примеру, нажат/не нажат), для состояний, отличных от стандартного, добавляется соответствующий префикс (-selected, -disabled).
Если одна и та же иконка используется на нескольких экранах, то нарезается она только один раз и кладется в папку common. Важно следить за тем, чтобы у разных иконок (даже находящихся в разных папках) не было одинаковых названий.
Более подробный гайд по наименованию ресурсов.
Формат: png.
Пример:
- messages-list-screen/
- favourite-icon.png
- favourite-icon @2x.png
- favourite-icon @3x.png
- favourite-icon-selected.png
- favourite-icon-selected @2x.png
- favourite-icon-selected @3x.png
- reply-indicator.png
- reply-indicator @2x.png
- reply-indicator @3x.png
6. Видео нестандартных анимаций
Так как выделить в общем виде набор стандартных анимаций не представляется возможным, то все планируемые анимации нужно обсуждать с командой разработчиков.
Для всех нестандартных анимаций должны прилагаться пояснительные видео или gif. Кроме этого, нужно подготовить и текстовое описание происходящего: какой параметр анимируется, за какое время, у какого объекта. Например: »заголовок увеличивается в 2 раза за 1 секунду с линейной скоростью", «изображение поворачивается на 90 градусов за 2 секунды с функцией плавности easeInOutQuart».
7. Иконки приложения
Иконки приложения должны быть квадратными (без скругленных углов) и предоставлены во всех необходимых размерах. Список размеров можно посмотреть здесь.
Автоматически нарезать иконки в нужных размерах поможет этот psd.
Формат: png.
8. Скриншоты для App Store
Для AppStore требуется пять комплектов скриншотов в разных размерах:
- 3,5’’ (iPhone 4, iPhone 4s) — 640 x 960 px
- 4’’ (iPhone 5, iPhone 5s) — 640 x 1136 px
- 4,7’’ (iPhone 6) — 750 x 1334 px
- 5,5’’ (iPhone 6+) — 1242 x 2208 px
- iPad — 1536 x 2048 px
Неплохой набор psd-шаблонов для генерации скриншотов всех размеров.
Формат: png.
Файловая структура предоставляемого комплекта документов
После того, как все описанные выше файлы подготовлены, должна получиться папка с о структурой, похожей на:
- screens-map.png
- color-palette.png
- fonts.txt
- custom-fonts/
- custom-font1.ttf
- custom-font2.ttf
- screens/
- common/
- back-icon.png
- back-icon @2x.png
- back-icon @3x.png
- messages-list-screen/
- messages-list-default.png
- messages-list-selected.png
- messages-list-swipe.png
- assets/
- favourite-icon.png
- favourite-icon @2x.png
- favourite-icon @3x.png
- favourite-icon-selected.png
- favourite-icon-selected @2x.png
- favourite-icon-selected @3x.png
- reply-indicator.png
- reply-indicator @2x.png
- reply-indicator @3x.png
- common/
- animations/
- side-menu-animation.mov
- peter-pan-animation.gif
- app-icons/
- icon-29.png
- icon-40.png
- icon-80.png
- ...
- screenshots/
- 640x920/
- screenshot1.png
- 640x1136/
- screenshot1.png
- ...
- 640x920/
Конечно, во многих случаях трудно требовать от дизайнеров полностью законченный пакет до фактического начала разработки — некоторые из экранов могут дорабатываться, анимации меняться, а скриншоты и иконки вообще рисуются под конец. Как вариант решения этой проблемы — держать всю папку расшаренной на файловом сервере или в облаке, постепенно ее заполняя.
Некоторые из перечисленных требований могут показаться излишними, но опыт показывает, что следование этим гайдлайнам экономит время не только разработчикам, но и самим дизайнерам.
Похожие гайдлайны в настоящий момент формируются и командой Android-разработчиков, так что, если читатели будут заинтересованы — обязательно опубликуем в недалеком будущем.
Полезные ссылки:
Комментарии (23)
mholub
23.04.2015 12:29+1А я вот стараюсь дизайны резать сам и прошу от дизайнеров только PSD. Если не справляюсь, потому что не знаю Photoshop так хорошо, то уже прошу мне там пару картинок дорезать.
Мне так нравится куда больше, чем объяснять дизайнеру что именно и как мне нужно нарезать. Да и не отвлекаю его лишний раз.
defmethod
23.04.2015 12:34+2Это классно, когда компания маленькая. Но когда масштаб большой, должен быть четкий и понятный процесс. Это улучшает взаимодействие отделов.
Spail
23.04.2015 14:45Такой подход означает что разработчик делает работу за дизайнера. Что не есть хорошо.
mholub
23.04.2015 14:58+2Задача дизайнера — дизайнить. А это уже верстка.
Версткой может заниматься как разработчик, так и дизайнер. Обычно занимаются дизайнеры, потому что фотошоп это их инструмент.
Но почему бы не делать это программистам? Это чисто технический скилл. Не нужно бояться фотошопа.Spail
23.04.2015 15:24Потому что программисты будут делать это явно дольше дизайнера. Ну и время программиста обычно стоит дороже чем время дизайнера.
mholub
23.04.2015 15:32Я не согласен. Большинство графики я нарезаю чем-то вроде:
1. Duplicate Layer/Group
2. В меню выбрать New document
3. Потом выбрать Image Trim
4. Save To PNG
Дизайнер потратит на это не сильно меньше времени чем я. В сложном случае я сам к нему пойду. Зато не тратится время на вот эти коммуникации.
Может быть конечно если дизайнер уже заранее натренирован и сразу знает в каком именно виде графику нужно отдать, то это действительно проще сделать дизайнеру.
При этом я приветствую структурированный подход конечно вроде выдачи таблицы цветов или шрифтов. Это очень помогает. У меня были случаи, когда я подходил к дизайнеру и говорил «А у тебя вот на этом экране шрифт 56 пикселей, а вот тут 60. Это ты специально так задумал или скосячил?». Таблички должны эти проблемы убирать в корне.
Pr0Ger
23.04.2015 19:38В Pixelmator это очень просто делается: нужный слой/группа просто drag'n'drop'ом в папку и все. Практически всегда это легче самому это сделать, чем объяснить в каком виде тебе нужно нарезать картинки
AlexRoch
23.04.2015 15:50+3Где-то в параллельной вселенной… «А я вот стараюсь править мелочи сам, мне проще залезть в исходники проекта и поменять там расположение элементов или те же шрифты, цвета. Мне так нравится куда больше, чем объяснять программисту какой именно шрифт тут должен стоять. Да и не отвлекаю его лишний раз. »
MagiC
23.04.2015 15:19Спасибо вам за статью! Мы по очень похожей схеме работаем, тоже делаем макеты, разметку, нарезаем графику и отдаём всё это разработчикам. Возьмём что-нибудь из ваших приёмов на вооружение.
Можно пару вопросов?
В чём рисуете макеты? Photoshop, Illustrator? Какие версии?
А разметку страницы делаете через плагин? Мы, например, используем Ink дя Photoshop, Specctr для Illustrator.
Используете ли в макетах ссылки? Например, вы нарисовали большую карту экранов, отдали уже разработчикам, а потом оказалось, что в меню надо пункт переправить. Не приходится править во всех макетах отдельно, а потом ещё и во всех макетах на карте?
YourDestiny Автор
23.04.2015 22:40Не за что :) Вообще большая часть дизайнеров используют Photoshop+Illustrator, на Sketch еще не перешли. Насчет версий сходу не скажу, но завтра постараюсь уточнить. С названием плагина для разметки то же самое — узнаю.
На самом деле мы не слишком сильно участвуем в процессе именно дизайна, так что тонкостей вроде использования ссылок не знаю — но уверен, что что-то в этом роде используется.
30PP0
23.04.2015 16:13+1Я для «нарезки» использую плагин для PS resonator.cc
Принцип работы: все иконки из исходных файлов помещаются столбцами в промежуточный файл Res-Project.psd, перед этим отресайзившись под нужные вам плотности. Фишка в том, что при полной автонарезке силами PNG Express, например, у иконок часто получаются мыльные края или случаются ещё какие-нибудь глюки. Поэтому RESONATOR сначала собирает все иконки в один файл, который называется Res-Project.psd. В нём вы поправите мыльную графику, а уже потом сохраняете пиксель перфектные иконки. Так же плюс в том, что вся «нарезка» хранится в одном файле, и её не надо искать по разным папкам, когда нужно переделать какую-нибудь иконку.
Mofas
23.04.2015 16:33Если бы у вас еще и Sketch был бы мастхэв в процессах, то это был бы отличный гайд )
YourDestiny Автор
23.04.2015 22:42Эти гайдлайны лишь формализуют общение между разработчиками и дизайнерами, насильно навязывать рабочий софт — не очень правильно :)
AnthonyBY
24.04.2015 01:13Раньше тоже весьма плевался когда просили нарезать дизайн самостоятельно. Однако в последнее время перестал делать из этого трагедию и нормально сам в фотошопе меряю и нарезаю с помощью бесплатного плагина Cut&Slice me www.cutandslice.me
p.s. Sketch ещё не освоил, но в активном процессе.
rule
Ваша схема хорошо работает, если дизайн после отдачи разработчикам не меняется. Но чаще всего во время разработки он меняется.
Для ускорения этого процесса лучше обучить разработчиков пользоваться sketch и плюс автоматизировать многие процессы: создание палитры цветов, экспорт картинок, нарезка, создание imageassets. Для сложных или динамических элементов использовать PaintCode или QuartzCode с автоматизацией экспорта.
jMas
Скорей всего речь идет о процессе, когда над дизайном работают программисты или специалисты из области программирования, не начиная писать код. Промежуточные версии дизайна на вряд ли собирают в законченный пакет для передачи программистам. Пусть автор меня поправит, если это не так.
И очень хорошее предложение полностью автоматизировать экспорт графики.
Spail
Из скетча брать данные действительно очень просто, но ведь его не все дизайнеры используют, а нужно единообразие.
rule
для фотошопе плагины тоже не особо сложно писать, так что можно и из фотошопе автоматом выдирать. Но скэтч сэкономит море времени, а дизайнеру хорошему не важно где рисовать, на практике за неделю дизайнер адаптируется к скетчу очень быстро.
Spail
Если за неделю, то круто, надо переводить на скетч =) а как вы автоматизируете упомянутые в комменте процессы?
rule
да там плагинов пачка есть, а некоторые вещи скриптами, их очень просто в скетче делать