Подход на спрайтах мне нравится гораздо больше как минимум из-за качества иконок на выходе. SVG шрифты имеют массу своих особенностей типа хинтинга, когда иконка может слегка плыть из-за размера окна браузера или едва заметных расхождений в рендеринге на разных операционках. Но, к сожалению, пока что отказаться от использования шрифтов мы не можем.
Stroy71, если расскажете более подробно, где и какие трудности с продуктом у вас возникают, я обязательно передам ваш отзыв ребятам, которые занимаются True Image. Нам очень важен фидбэк от пользователей.
С технической стороны мы реализовали все очень просто. Написали регулярки, которые проходят по SVG и вычищают все лишнее. Работает решение при определенных условиях.
1. все иконки — это глифы, то есть одноцветные
2. все иконки экспортированы из Sketch
3. все иконки экспортированы через slice
Это дает нам примерно одинаковый код для всех иконок.
replace = [
{reg : / fill="(.*?)"/m, post : ''},
{reg : /(\s*)<\/defs[\s\S]*<\/g>/m, post : ''},
{reg : /(\s*)<defs>/m, post : ''},
{reg : / id="(.*?)"/m, post : ''},
{reg : /xmlns:xlink="(.*?)"/m, post : ''},
{reg : /(\s*)<g[\s\S]*?>/m, post : ''},
{reg : /(\s*)<\/g>/m, post : ''},
{reg : /<svg/m, post : '<svg fill="#000"'},
{reg : / transform="(.*?)"/m, post : ''},
{reg : / fill-rule="(.*?)"/m, post : ''},
],
Что используете? Acronis Backup или True Image? Интересно было бы получить общий фидбэк по продукту, что удобно, что нет, с какими проблемами, помимо озвученной, и как часто сталкиваетесь. С прошлой статьи мы получили очень ценный отзыв про True Image от пользователя Хабра, не хотелось бы нарушать хорошую традицию. Готов пообщаться в ДМ.
Какой способ работы с SVG, на ваш взгляд, самые оптимальный? SVG — спрайты? Держать все SVG в JS и кешировать на стороне пользователя? Использовать img или background-image? Работать с растровыми картинками долго и муторно, в нескольких продуктах мы сейчас используем PNG спрайты и это боль, особенно, когда есть 18 цветовых схем и нужно добавить новую иконку.
Когда мы в Acronis начнем делать терминалы для покупки/пополнения проездных, обязательно учтем неудачный опыт других компаний. Спасибо, что поделились вашей болью.
Один диалог с кнопкой слева, другой с кнопкой справа — это два разных компонента? А если к ним добавить диалог с двумя кнопками, с тремя, кнопка + ссылка, две ссылки, но без кнопки? Это все тоже разные компоненты?
Разработчики видят макеты только в Zeplin. В Zeplin, как правило, попадают только утвержденные макеты прошедшие ревью. Если есть несколько вариантов решения задачи, это отдельные ветки в Abstract. Ветку можно удалить в любой момент или оставить для истории.
Давайте отделим мух от котлет. Если дизайнер вдруг захотел поменять расположение кнопок или скругления у бордеров просто так, потому что вроде так прикольнее — это нефункциональное изменение. В нем нет смысла, пока не доказана его необходимость и польза. Если показало иследование, что так будет лучше, заметнее, кликать будут больше — это функциональное изменение.
Нет такого компонента как модальное окно с кнопкой справа. Делать настолько узкие и точечные компоненты — тупик. Если брать методологию атомарного дизайна, то модальное окно — это организм, который состоит из контейнера и кнопки, без привязки к какому-то конкретному краю. Доносить функциональное изменение исключительно через макет, чтобы разработчик сам сидел и смотрел diff'ы — это неправильно выстроенный процесс. На каждое функциональное изменение должна быть спека, таск в джире, что-то еще с описанием изменения. Если хотите смотреть рядом два макета, можно пользоваться sympli (функционал схож с Zeplin) или попробовать Kactus.io (похож на Abstract, но работает через Git-аккаунт), там такая возможность есть.
Какое отношение положение кнопки имеет к библиотеке компонентов?
Если речь про UX паттерны и лэйауты, то положение тех же кнопок жестко зафиксировано и описано, здесь не нужны никакие визуальные дифы. Разработчики получают финальные макеты через Zeplin, где уже ничего не надо двигать, так как макеты прошли ревью на этапе прототипов, отрисовки UI и проверки текстов
тех.писателями. Дальше сборка, отлов багов и продакшен.
1. Изменение радиуса скруглений — это нефункциональное изменение польза от которого неочевидна. Мы не делаем нефункциональных изменений в компонентах. Если меняется какой-то компонент — изменению предшествовало обсуждение.
2. Для ввода новых компонентов есть таблица с roadmap, куда заносятся все хотелки. Как только компонент добавлен в Sketch файл, его статус в таблице меняется. Как только компонент попадает в code base его статус меняется в таблице еще раз.
3. Как только артборд с изменениями попадает в Zeplin, падает уведомление в отдельный канал в Slack. + Описание мерджа ветки с мастером в Abstract + лично через скайп, слак, в письме, устно.
Без многоступенчатого согласования компоненты не меняются. Перед тем, как внести какое-либо изменение уведомляются все заинтересованные. Это же не просто цвет в макете поменять. В Abstract можно смотреть ветку с историей изменения элемента, там же можно выделить область и оставить комментарий или вести дискуссию.
Была такая попытка, но человек, который активно продвигал Bootstrap, ушел из компании и оставил после себя не самое лучшее наследие. К тому же, Bootstrap 4 до сих пор не зарелизили. Как вы развиваете компоненты? Где идут изменения? В коде Bootstrap, задаются через переменные или переопределяете стили?
1. все иконки — это глифы, то есть одноцветные
2. все иконки экспортированы из Sketch
3. все иконки экспортированы через slice
Это дает нам примерно одинаковый код для всех иконок.
Нет такого компонента как модальное окно с кнопкой справа. Делать настолько узкие и точечные компоненты — тупик. Если брать методологию атомарного дизайна, то модальное окно — это организм, который состоит из контейнера и кнопки, без привязки к какому-то конкретному краю. Доносить функциональное изменение исключительно через макет, чтобы разработчик сам сидел и смотрел diff'ы — это неправильно выстроенный процесс. На каждое функциональное изменение должна быть спека, таск в джире, что-то еще с описанием изменения. Если хотите смотреть рядом два макета, можно пользоваться sympli (функционал схож с Zeplin) или попробовать Kactus.io (похож на Abstract, но работает через Git-аккаунт), там такая возможность есть.
Если речь про UX паттерны и лэйауты, то положение тех же кнопок жестко зафиксировано и описано, здесь не нужны никакие визуальные дифы. Разработчики получают финальные макеты через Zeplin, где уже ничего не надо двигать, так как макеты прошли ревью на этапе прототипов, отрисовки UI и проверки текстов
тех.писателями. Дальше сборка, отлов багов и продакшен.
2. Для ввода новых компонентов есть таблица с roadmap, куда заносятся все хотелки. Как только компонент добавлен в Sketch файл, его статус в таблице меняется. Как только компонент попадает в code base его статус меняется в таблице еще раз.
3. Как только артборд с изменениями попадает в Zeplin, падает уведомление в отдельный канал в Slack. + Описание мерджа ветки с мастером в Abstract + лично через скайп, слак, в письме, устно.
Про положение элемента не понял вопрос.