Комментарии 43
Если коротко, то просто используйте размеры кратные 8-ми пикселям.
Давно юзаю такую сетку — взял на вооружение как только ознакомился с Material Design.
8-пиксельная сетка часто (если не всегда) упоминается в связке с baseline grid кратному четырем пикселям. И вот тут возникают заусенцы. Допустим, интерлиньяж текста равен 20 пикселям, что допускается 4-пиксельной baseline grid (блин, как по-русски-то?). Это зачастую приводит к появлению в дизайне текстбоксов, размер которых не кратен 8 (20, 36, 44 и т.п.). И если замерять от такого текстбокса отступ, кратный 8, то вся стройная 8-пиксельная сетка ниже этого объекта будет испорчена объектами, смещенными на 4 пикселя.
Надеюсь понятно объяснил… Как быть в такой ситуации?
Стараюсь не использовать интерлиньяж 20 px. Т.е. он или 16 px, или 24 px, или 32 px.
Это очень неприятное ограничения для дизайна мобильного интерфейса, где часто приходится экономить место. Ну может хоть посоветуете, как быть-то, если все таки приходится совмещать восьми- и четырех-пиксельные сетки?
делаем отступ не 16, а 20
Ну это понятно, а как это автоматизировать?) То есть, хотим мы сделать символ для компонента «Абзац текста 100500 букв». В него закладываем отступ до следующего компонента. Какой отступ закладывать и как? Ведь текст бывает разный и соответственно отступ может быть как 16, так и 20. Я так понимаю такие нюансы еще не поддаются автоматизации?
Если формализовать проблему, то получится условие: если строк чётное количество — отступ снизу=16, если нечетное = 20.
Ну и получается что отступ одного и того же компонента будет разнится, что тоже не есть гуд — разница хоть и в 4 пикселя, а мешать будет.
А в Скетче автоматизировать такое не знаю как. Думаю, что пока нельзя и придётся делать вручную.
Все расстояния которые находятся в контексте какого-то текста (например внутренние паддинги кнопки или другого бокса, внешние отступы между параграфами и т.д.), желательно привязывать к размеру шрифта данного текста, чтоб расстояние / размер шрифта = адекватное число (1.4; 1.5; 1.6 и т.д., а не 1.82754).
Например есть некий бокс с текстом внутри с шрифтом 24px, так вот внутренний паддинг желательно бы указать с привязкой к данному шрифту, чтоб одно делённое на другое равнялось число с одной цифрой после запятой.
Это я к тому, что грамотный верстальщик будет прописывать этот паддинг в em. И допустим если в данном случае паддинг дизайнер нарисует 48px, то верстальщик укажет 2em (и всё будет красиво и адаптивно), а если паддинг будет 50px, то в css надо будет писать 2,08333333em что не есть хорошо.
А никак не быть, например из того же Бринхерса следует, что интерлиньяж текстовых блоков может не становиться на сетку, при условии того что, в конечном итоге блок все же войдет в ритм сетки. Там приводится отличная аналогия с ритмом музыки, можно выбрать один ритм для всей композиции, но ничего страшного не случится если внутри композиции будут переходы на более быстрые или медленные фрагменты, главное чтобы в конце они влились в общую композицию. Помимо этого я часто замечаю что многие жертвуют оптической композицией ради математической верности, это проиграшная позиция, не пофиг ли встает ли текстовый блок в пиксельную сетку, или нет, если в общей композиции он будет смотреться ужасно. Моя стратегия такова, 8 пикселей грид обязательное выравнивание по горизонтали, и компромиссное по вертикали.
Помимо этого я часто замечаю что многие жертвуют оптической композицией ради математической верности, это проиграшная позиция
Соглашусь, но зачастую это обусловлено необходимостью быстрой разработки дизайна. Хотя иногда быстрее получается если просто подзабить на мат.верность, но чую верстальщики такому не рады будут)
Моя стратегия такова, 8 пикселей грид обязательное выравнивание по горизонтали, и компромиссное по вертикали.
Хмм, а вот это странно. Текст спокойно разрушает и горизонтальную сетку, и вертикальную — везде рано или поздно приходится отступать от сетки. Вообще 8рх — это довольно большой кусок доступного пространства; это понимаешь, когда начинаешь дизайнить формы и таблицы (эти компоненты наверное вообще самое сложное в дизайне).
Чем дальше в лес тем больше сетка начинает выполнять роль клетки, короче :)
Все классно)
А вы в процессе делаете UI guide или в конце проекта?
Кстати насчет стилей. Существует много полезных плагинов которые автоматически генерируют стили
Например — https://github.com/lucaorio/sketch-styles-generator
Есть несколько вопросов которые возникли при открытии:
* Как можно порезать дизайн для верстки, к примеру, сложные наложения разных градиентов etc? (Обычного экспорта определенного symbol'a недостаточно).
* Где можно найти историю изменений? Как откатить изменения?
* Как работать верстальщикам которые работают под Windows?
п.с. прошу не минусовать, вопросы серьезные
1) никак
2) никак
3) никак
)))
Если по серьезному, то на первый вопрос все же есть ответ. Градиенты вообще не импортируются а создаются прямо в скетче.Существуют плагины, которые экспортируют весь скетч файл в HTML страничку или даже CSS код.
По поводу ваших вопросов:
1. Не до конца понял что именно вы имели в виду, но обращу ваше внимание, что в Скетче есть инструмент «Slice» (S), с функционалом, схожим с Фотошоповским. Вы можете «нарезать» любые нужные вам участки макета и экспортировать в виде png, в любом разрешении. Кроме этого, объекты можно сгруппировать, видимость установить масками и экспортировать группу. Более точный рецепт можно дать при более детальном понимании задачи.
2. Скетч использует маковский инструмент, что-то вроде Time Machine, позволяющий откатиться к более ранним версиям. Находится он в «File» → «Revert to...». Но, насколько я понимаю, сама история храниться на той машине, на которой файл разрабатывался. Т.е. если вам достался готовый файл для «нарезки» откатиться в не сможете.
Я в проектах последнее время использую Git, поэтому откатиться до любого коммита не составляет сложности на любой машине.
3. Для этого есть ряд решений, таких как Invision, Zeplin или плагин Marketch. Фактически, все они включают в себя инспекторы кода, и показывают css информацию по любому объекту (что-то вроде developer tools в Хроме). Сам использую Инвижн. У него в последних версиях появился замечательный «Incpect mode», если макет выгружен при помощи плагина Craft Sync. Для того чтобы познакомиться с ним есть бесплатная версия для одного проекта.
2. Cmd + Z (Undo) не работает, ковырялся в настройках, требуемый результат не получен (приходиться «не дышать» )) ). Git как вариант для небольших файлов, а вот если файлы Sketch'a ≥ 200mb, при наличии хорошего канала, все равно тянет продолжительное время.
3. Спасибо за Marketch. Попробовал использовать avocode (пока trial), жить как-то можно.
К сожалению у всех фломастеры разные.
Комманда Sketch'a послала все остальные OS, а держать кучу подписок на разные сервисы тоже не вариант как минимум накладно.
В результате имеем огромную проблему и приличное кол-во плевков во все стороны.
По 3-му правилу нужно очень сильно давайть по рукам. )
з.ы. Большое спасибо за ответы.
* Masks, Slices.
* File → Revert To → Browse All Versions…
* invisionapp.com
Ещё есть продукт от Adobe — Experience Design CC, пытающийся составить конкуренцию Скетчу, но тут я не могу ничего советовать, т.к. смотрел его поверхностно. Пока он в бета-версии, и там нет такого арсенала плагинов и туториалов, как у Скетча.
Ну, и покупка мака — это отличное вложение, на мой взгляд ))
Ещё есть продукт от Adobe — Experience Design CC, пытающийся составить конкуренцию Скетчу, но тут я не могу ничего советовать
Могу посоветовать не тратить время на эту мертворожденную программу. Я специально обновился до десятки только чтобы протестить XD — в ней вообще ничего еще нет, только пара прикольных фишек, которые в итоге не помогут вести дизайн-проект в этой программе.
Ну и попытка превратить фотошоп в программу для веб-дизайна… На этого франкенштейна нельзя без боли смотреть теперь, а работать в нём — проще себе в ногу выстрелить :)
Феерверк и Дримвивер проекты Макромедии, а не Адоби. После поглощения было похоронено почти всё наследие первой. На плаву остались только Дримвивер (который в последнем релизе слегка перетряхнули) и Анимейт (бывший Флеш, ныне морвировавший).
ХД пишется с нуля, с учётом текущей конъюнктуры.
В нём до сих пор (версия 21.1.0) весело маячат три весёлые жопы:
— рассинхрон имён объектов в аутлайнере и ассет экспорте;
— экспорт маскированных объектов с габаритами по маске+контент, а не чисто по маске.
— пьяные размеры у слайсов.
Две первые можно увидеть на этой картинке:
К сожалению, так и не смог заставить себя пользоваться стилями для текстов и объектов, т.к. их нельзя упорядочить в меню. Как только стилей становится больше 10, в них просто невозможно ориентироваться. Если бы разработчики дали возможность упорядочивать стили по группам (как это сделано для символов), возможно, это было бы удобно.
Вынесите кнопку «Styled Text» в тулбар — там стили текста группируются так же как символы. Ещё я добавил туда кнопку «Symbols» и «Fonts», а все лишнее убрал. Мне стало намного удобнее.
4 правила работы в Sketch над крупными проектами