image

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

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


Чем мы пользуемся


Sketch и плагины:

Adobe Photoshop и скрипт Size Marks от Романа Шамина.
Заметим, что Photoshop для дизайна мобильных приложений используем все реже и реже — в работе мы активно внедряем Sketch и продвигаем его среди разработчиков, дабы они могли в случае трудностей сами посмотреть нужный размер или ресурс в исходнике, не отвлекая дизайнера от важных дизайнерских дел.

Несмотря на то, что описанное ниже сильно «завязано» на Sketch, приемы возможно применять и в Photoshop, хотя это несколько сложнее.

О разрешениях макетов


Итак, как мы знаем, iOS имеет на данный момент следующие разрешения ресурсных изображений: @1x, @2x и @3x; а Android: mdpi(1x), hdpi(1,5x), xhdpi(2x), xxhdpi(3x), xxxhdpi(4x) — это основные, ldpi и tvdpi в рассчёт брать не будем.

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

Если рассматривать форм-фактор телефонов, то для простоты вычислений размеров, а так же последующей подготовки спецификации, проще взять следующие разрешения макетов:
iOS
  • 320x480 (iPhone 4/4s)
  • 320x568 (iPhone 5/5c/5s)
  • 375x667 (iPhone 6)
  • 414x736 (iPhone 6 Plus).


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

image

За основные разрешения мы выбираем 320x568 для iOS ( @1x) и 360x640 для Android (mdpi), так как девайсов с этими форм-факторами сейчас наибольшее количество.

Так почему же именно @1x и mdpi?

Проектирование и отрисовка


На этапах проектирования и дизайна выбранные нами @1x и mdpi дают возможность быстро «накидать» прототип из стандартных элементов Sketch и не думать о чётности размеров элементов и отступов, так как все они будут только увеличиваться в случае нашего желания посмотреть большие разрешения.

Кроме того, это никак не мешает нам смотреть макеты на устройствах с помощью плагина Sketсh Preview (работает в связке с приложением Skala и Skala Preview), у плагина есть настройки, которые дают возможность увеличивать макет до нужного для просмотра разрешения, причем как на iOS устройствах, так и на Android.

image
Настройки плагина Sketch Preview

Главным требованием является кратность разрешения у устройства к разрешению исходника, например, наш исходник iOS 320x568, нормально смотреть его можно только на iPhone 5/5s/5c, а исходник Android 360x640 мы смотрим на Nexus 5 c разрешением в 3 раза больше 1080x1920 (xxhdpi).

Единственным, для кого-то существенным, минусом является желание видеть однопиксельные разделители на высоких разрешениях. Это значит, что если мы хотим увидеть на экране iPhone 5 линию толщиной в 1px, то в макете она должна быть 0,5px. Так как создавать в макете 0,5px линии не круто, решение этой проблемы может быть иным: создаём 2px прозрачную линию на месте разделителя с внутренней тенью с значением 0,5. Если же это Android макет, то 0,33-0,35 (для просмотра на Nexus 5).

image
Пример разделителя 0,35 установленного с помощью внутренней тени в Android приложении

Но в большинстве случаев мы просто останавливаемся на разделителях в 1px в макете, а в спецификации для разработчиков прописываем этот момент словами.

Экспорт


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

Так как мы выбрали самое малое разрешение, то можем не беспокоиться за «мыло» (искажения и нечёткость) в ресурсах для iOS, изначально мы рисуем все элементы с привязкой к пиксельной сетке (очень редко без) и получаем чёткие иконки в @2x и в @3х. Очевидно преимущество в случае появления в проекте iPad-версии приложения, так как в этом случае проработанные @1x ресурсы нам понадобятся.

image
Пример нарезки для iOS из @1x(верхняя строка — нормальный размер иконок, нижняя — увеличенный, для детального просмотра)

В случае же с Android, наш выбор mdpi даёт отличный результат в xhdpi/xxhdpi/xxxhdpi и, возможно, «мыло» в hdpi.

image
Пример автоматической нарезки для Android из mdpi

Очевидным решением проблемы является проработка hdpi ресурсов руками, либо сильное соблюдение чётности в mdpi(как видно на картинке с верхней линией самолётика получилось, а вот с линией в обведённой области — нет).

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

Спецификация


Разработчики просят отдавать им спецификацию в pt и dp, для iOS и Android соответственно. Тут выбранные нами разрешения также нам помогают, не надо думать и делить размеры на какие-то числа и так далее…

Достаточно с помощью lite measure или просто measure расставить нужные размеры. Здесь можно возразить, что плагин умеет пересчитывать размеры из тех что есть в нужные, но не многие об этом знают, да и вообще не многие знают, что размеры надо отдавать в pt и dp.

Замечание: У автора была старая версия плагина Sketch Measure, новую изрядно поменяли.

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

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

image
Пример работы скрипта Size Marks

Думаем о других


Важным моментом, на наш взгляд, является передача проекта от одного дизайнера к другому. Если новый дизайнер получит xxhdpi-проект (а он не привык к этому или вообще новичок), то ему понадобится уйма времени на изучение и понимание исходника, а также постоянный пересчёт с делением на 3 (что не так просто, как кажется). Если же он получит mdpi проект, то легко сможет соотнести его с гайдлайнами и скорее приступит к решению задачи.

В случае с iOS и передачей макетов в @2x дело обстоит чуть проще, так как делить на 2 умеет даже гуманитарий. Но иногда встречаются исходники в @2x для iPhone 6, и опять вместо работы начинаются пересчёты и размышления.

Лирика


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

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

Руководствуясь вышеизложенными размышлениями, наша дизайн-команда мобильных приложений выбрала путь работы с @1x и mdpi макетами.

Небольшой опрос
В каком разрешении ваши исходные файлы для iOS?

Проголосовало 173 человека. Воздержалось 183 человека.

В каком разрешении ваши исходные файлы для Android?

Проголосовало 159 человек. Воздержалось 206 человек.

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

Комментарии (15)


  1. romanshamin
    01.07.2015 14:46
    +2

    … скрипт Size Marks, который при наших разрешениях даст нужные разработке размеры (но только в px, к сожалению)

    Size Marks указывает размеры в пикселях, если разрешение документа равно 72 ppi. При любых других разрешениях размеры будут в поинтах.


    1. Simach Автор
      01.07.2015 14:51
      +3

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


  1. nemezis
    01.07.2015 23:49

    Zeplin.io не пользуетесь? 


    1. Simach Автор
      02.07.2015 01:27

      пока не начинали, но знаем о нём.
      Ждём проект, на котором попробуем.


  1. Louter
    02.07.2015 01:15

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


    1. Simach Автор
      02.07.2015 01:29

      если в про iOS и у вас есть отдельные артборды под iPhone 5/6/6+. то вам хватит 1 пункта.


  1. vovkab
    02.07.2015 10:52
    +1

    Делаем в принципе все тоже самое, вот уже пару лет. (андроид)
    Работаем со скетч фалом напрямую, оттуда сохраняем svg. Gradle плагин (https://github.com/avianey/androidsvgdrawable-plugin) нам нарезает все нужные размеры. Если у иконки есть ровные линии, то делается отдельный svg файл для hdpi, если сильно заметно.

    Мне интересно что вы делаете с редлайнами для текста, например, то что показано на картинке «Пример работы скрипта Size Marks», не будет работать, так как не учитываются падинги для шрифтов. В примерe падинг сверху уже будет не 60, а 54, в добавок судя по картинке оба текстовых поля пересекаются друг с другом. Не знаю как в ios, в андроиде такого быть не должно :)


    1. Simach Автор
      02.07.2015 11:33

      Если у иконки есть ровные линии, то делается отдельный svg файл для hdpi, если сильно заметно.

      Не совсем понял этот момент, если у вас нарезаются из svg все нужные размеры, то зачем отдельный svg для hdpi? Проще же сразу png.
      и вы наверное про не ровные линии?

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

      image

      А картинка взята из примера самого Size Marks. =)


      1. vovkab
        03.07.2015 08:48

        > Не совсем понял этот момент, если у вас нарезаются из svg все нужные размеры, то зачем отдельный svg для hdpi?

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

        > По поводу текста, в спецификациях мы отдаём расстояние до базовой линии, на не лэйбла. Иногда даём картинку с сеткой вроде вот такой:

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


        1. Simach Автор
          03.07.2015 09:36

          Про «блюр» понятно, я скорее о svg, но не суть.

          Да, сами. Тут ещё момент есть, что у Ps и Sketch иногда паддинги могу отличаться у одного шрифта. Мы просто иногда даём картинку с линиями, программисты её себе вставляют и расставляют по ней. Не самый удобный вариант, но пока так.


          1. vovkab
            03.07.2015 23:24

            > я скорее о svg

            Тут есть 3 способа:
            1. экспортировать как есть, но получим размытые картинки, обычно на hdpi
            2. экспортировать все размеры в png и руками подправить иконки для hdpi, tvdpi и тд.
            3. создать отдельную копию svg для hdpi, подвинуть ее по сетке что бы избавится от блюра.

            Мне больше нравится третий вариант, так как он легче и к тому же у нас уже все нарезается из svg автоматически. В итоге из mdpi svg мы получим png для mdpi(x1), xhdpi(x2), xxhdpi(x3). А из hdpi.svg -> hdpi.png.


            1. Simach Автор
              04.07.2015 13:54

              ах да, прошу прощения, я что-то не о том подумал.
              Вы кладёте в проект 2 svg, а там уже всё самое делается.

              я почему-то думал, что проще так:
              сделать в mdpi и mdpi.svg -> mdpi/xhdpi/xxhdpi/xxxhdpi.png
              а hdpi просто сразу из скетча -> hdpi.png

              в общем не так важно, суть ясна)


  1. iago
    07.07.2015 13:17

    А как вы делаете 1-пиксельные линии? Очень часто не хочется, чтоб они растягивались до 2 пикселей на ретине…


    1. Simach Автор
      07.07.2015 14:01

      как описано в статье, делаем внутреннюю тень в 0.5px, на ретине она становится 1px.


    1. Simach Автор
      08.07.2015 12:13

      но если вопрос про иконки, то в таком случае прорабатываем @2x отдельно