Как стать автором
Обновить

Комментарии 34

Выглядит и красиво и грамотно! Не планируете опубликовать вашу библиотеку компонентов?
Пока об этом рано говорить, но в долгосрочной перспективе планируем.

Не публиковали?

Довольно полезно. Примерно тоже самое стоит и нам сделать
Отправьте автора читать про байндинги в Angular, от [label]="'text'" кровь из глаз идет
Прикольно. A что для разработчиков является single source of truth? Как документируются Angular компоненты? Какова процедура для изменения компонентов или дизайна в момент проверки дизайна компонентов (verfication)?
Source of truth для разработчиков — макеты в Zeplin, приоритет всегда у UI Library. Компоненты пока никак не документируются, только демо-стенд с примерами. Если говорить о verification, то двигаемся в сторону Lean UX.
В статье я как раз говорю об этом. Несмотря на то, что в Sketch 47 будут библиотеки, мы не спешим уходить с Lingo из-за большей гибкости в работе.

1. Неясно, как нативные библиотеки будут работать с Abstract
2. Как хранить составные компоненты, которые находятся не в символе, а собраны в папку. Sketch до сих пор не смог победить баг который создает дубли символов при копировании символов из проекта в проект.
Спасибо за интересную статью!
НЛО прилетело и опубликовало эту надпись здесь
Интересно сколько у вас времени уходит на организацию работы и собственно на саму работу?

Пять лет, минимум — сделайте переименование синхронизаций, сделайте переименование синхронизаций, сделайте переименование синхронизаций…

image

Это трудней чем запилить единую библиотеку компонентов?

Это ж компания. Автор топика, очевидно, за дизайн, а не за разработку…
Обязательно передам вашу боль коллегам, которые занимаются True Image. Если вы являетесь активным пользователем, может расскажите про свой опыт? Можно здесь, можно в личные сообщения или на почту, это было бы очень круто и ценно для нас.
Спасибо за адекватную реакцию и вы очень точно сказали, это боль. С большой буквы «Б». Пользуюсь TrueImage уже лет 10 и вначале писал по разным поводам и в техподдержку и сюда в комментарии пару раз. Теперь уже не пишу.

Но если вам действительно интересно, то попробую еще раз собрать все вместе и вышлю вам, еще раз спасибо за ответ.
Да, нам действительно интересно и важно! К тому же, фидбэк от пользователя, который так долго пользуется нашим продуктом будет ценным вдвойне.
Хочу публично выразить благодарность компании Acronis и персонально Nikishkin

Фидбэк мой был принят, отправлен по инстанциям, рассмотрен и дан развернутый ответ по всем пунктам, по ряду вопросов работу Acronis уже ведет. Еще раз, спасибо.

Мы в своей компании сделали все немного проще — взяли Bootstrap (сейчас это 4 Beta) и стандартный boilerplate с кучей необходимых элементов и все это видоизменили в соответствии с текущим визуальным стилем. Сделать и содержать это все предельно просто и для каждого элемента есть копи-пейст маркап и стиль.


Продуктов у нас тоже много и почти все они так или иначе завязаны на хтмл.

Была такая попытка, но человек, который активно продвигал Bootstrap, ушел из компании и оставил после себя не самое лучшее наследие. К тому же, Bootstrap 4 до сих пор не зарелизили. Как вы развиваете компоненты? Где идут изменения? В коде Bootstrap, задаются через переменные или переопределяете стили?
Мне кажется, что стандартный винтоус интерфейс был бы лучше
Почему?
НЛО прилетело и опубликовало эту надпись здесь
Без многоступенчатого согласования компоненты не меняются. Перед тем, как внести какое-либо изменение уведомляются все заинтересованные. Это же не просто цвет в макете поменять. В Abstract можно смотреть ветку с историей изменения элемента, там же можно выделить область и оставить комментарий или вести дискуссию.
НЛО прилетело и опубликовало эту надпись здесь
1. Изменение радиуса скруглений — это нефункциональное изменение польза от которого неочевидна. Мы не делаем нефункциональных изменений в компонентах. Если меняется какой-то компонент — изменению предшествовало обсуждение.

2. Для ввода новых компонентов есть таблица с roadmap, куда заносятся все хотелки. Как только компонент добавлен в Sketch файл, его статус в таблице меняется. Как только компонент попадает в code base его статус меняется в таблице еще раз.

3. Как только артборд с изменениями попадает в Zeplin, падает уведомление в отдельный канал в Slack. + Описание мерджа ветки с мастером в Abstract + лично через скайп, слак, в письме, устно.

Про положение элемента не понял вопрос.
НЛО прилетело и опубликовало эту надпись здесь
Какое отношение положение кнопки имеет к библиотеке компонентов?

Если речь про UX паттерны и лэйауты, то положение тех же кнопок жестко зафиксировано и описано, здесь не нужны никакие визуальные дифы. Разработчики получают финальные макеты через Zeplin, где уже ничего не надо двигать, так как макеты прошли ревью на этапе прототипов, отрисовки UI и проверки текстов
тех.писателями. Дальше сборка, отлов багов и продакшен.
НЛО прилетело и опубликовало эту надпись здесь
Давайте отделим мух от котлет. Если дизайнер вдруг захотел поменять расположение кнопок или скругления у бордеров просто так, потому что вроде так прикольнее — это нефункциональное изменение. В нем нет смысла, пока не доказана его необходимость и польза. Если показало иследование, что так будет лучше, заметнее, кликать будут больше — это функциональное изменение.

Нет такого компонента как модальное окно с кнопкой справа. Делать настолько узкие и точечные компоненты — тупик. Если брать методологию атомарного дизайна, то модальное окно — это организм, который состоит из контейнера и кнопки, без привязки к какому-то конкретному краю. Доносить функциональное изменение исключительно через макет, чтобы разработчик сам сидел и смотрел diff'ы — это неправильно выстроенный процесс. На каждое функциональное изменение должна быть спека, таск в джире, что-то еще с описанием изменения. Если хотите смотреть рядом два макета, можно пользоваться sympli (функционал схож с Zeplin) или попробовать Kactus.io (похож на Abstract, но работает через Git-аккаунт), там такая возможность есть.
НЛО прилетело и опубликовало эту надпись здесь
Один диалог с кнопкой слева, другой с кнопкой справа — это два разных компонента? А если к ним добавить диалог с двумя кнопками, с тремя, кнопка + ссылка, две ссылки, но без кнопки? Это все тоже разные компоненты?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Разработчики видят макеты только в Zeplin. В Zeplin, как правило, попадают только утвержденные макеты прошедшие ревью. Если есть несколько вариантов решения задачи, это отдельные ветки в Abstract. Ветку можно удалить в любой момент или оставить для истории.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий