Комментарии 34
Выглядит и красиво и грамотно! Не планируете опубликовать вашу библиотеку компонентов?
+2
Довольно полезно. Примерно тоже самое стоит и нам сделать
0
Отправьте автора читать про байндинги в Angular, от
[label]="'text'"
кровь из глаз идет-3
Прикольно. A что для разработчиков является single source of truth? Как документируются Angular компоненты? Какова процедура для изменения компонентов или дизайна в момент проверки дизайна компонентов (verfication)?
+1
Думаю теперь можно немного изменить схему, библиотеки в Sketch 47 sketchapp.com/docs/libraries
0
В статье я как раз говорю об этом. Несмотря на то, что в Sketch 47 будут библиотеки, мы не спешим уходить с Lingo из-за большей гибкости в работе.
1. Неясно, как нативные библиотеки будут работать с Abstract
2. Как хранить составные компоненты, которые находятся не в символе, а собраны в папку. Sketch до сих пор не смог победить баг который создает дубли символов при копировании символов из проекта в проект.
1. Неясно, как нативные библиотеки будут работать с Abstract
2. Как хранить составные компоненты, которые находятся не в символе, а собраны в папку. Sketch до сих пор не смог победить баг который создает дубли символов при копировании символов из проекта в проект.
+1
НЛО прилетело и опубликовало эту надпись здесь
Интересно сколько у вас времени уходит на организацию работы и собственно на саму работу?
Пять лет, минимум — сделайте переименование синхронизаций, сделайте переименование синхронизаций, сделайте переименование синхронизаций…
Это трудней чем запилить единую библиотеку компонентов?
Пять лет, минимум — сделайте переименование синхронизаций, сделайте переименование синхронизаций, сделайте переименование синхронизаций…
Это трудней чем запилить единую библиотеку компонентов?
+3
Это ж компания. Автор топика, очевидно, за дизайн, а не за разработку…
0
Обязательно передам вашу боль коллегам, которые занимаются True Image. Если вы являетесь активным пользователем, может расскажите про свой опыт? Можно здесь, можно в личные сообщения или на почту, это было бы очень круто и ценно для нас.
+1
Спасибо за адекватную реакцию и вы очень точно сказали, это боль. С большой буквы «Б». Пользуюсь TrueImage уже лет 10 и вначале писал по разным поводам и в техподдержку и сюда в комментарии пару раз. Теперь уже не пишу.
Но если вам действительно интересно, то попробую еще раз собрать все вместе и вышлю вам, еще раз спасибо за ответ.
Но если вам действительно интересно, то попробую еще раз собрать все вместе и вышлю вам, еще раз спасибо за ответ.
0
Мы в своей компании сделали все немного проще — взяли Bootstrap (сейчас это 4 Beta) и стандартный boilerplate с кучей необходимых элементов и все это видоизменили в соответствии с текущим визуальным стилем. Сделать и содержать это все предельно просто и для каждого элемента есть копи-пейст маркап и стиль.
Продуктов у нас тоже много и почти все они так или иначе завязаны на хтмл.
0
Была такая попытка, но человек, который активно продвигал Bootstrap, ушел из компании и оставил после себя не самое лучшее наследие. К тому же, Bootstrap 4 до сих пор не зарелизили. Как вы развиваете компоненты? Где идут изменения? В коде Bootstrap, задаются через переменные или переопределяете стили?
0
Мне кажется, что стандартный винтоус интерфейс был бы лучше
0
НЛО прилетело и опубликовало эту надпись здесь
Без многоступенчатого согласования компоненты не меняются. Перед тем, как внести какое-либо изменение уведомляются все заинтересованные. Это же не просто цвет в макете поменять. В Abstract можно смотреть ветку с историей изменения элемента, там же можно выделить область и оставить комментарий или вести дискуссию.
0
НЛО прилетело и опубликовало эту надпись здесь
1. Изменение радиуса скруглений — это нефункциональное изменение польза от которого неочевидна. Мы не делаем нефункциональных изменений в компонентах. Если меняется какой-то компонент — изменению предшествовало обсуждение.
2. Для ввода новых компонентов есть таблица с roadmap, куда заносятся все хотелки. Как только компонент добавлен в Sketch файл, его статус в таблице меняется. Как только компонент попадает в code base его статус меняется в таблице еще раз.
3. Как только артборд с изменениями попадает в Zeplin, падает уведомление в отдельный канал в Slack. + Описание мерджа ветки с мастером в Abstract + лично через скайп, слак, в письме, устно.
Про положение элемента не понял вопрос.
2. Для ввода новых компонентов есть таблица с roadmap, куда заносятся все хотелки. Как только компонент добавлен в Sketch файл, его статус в таблице меняется. Как только компонент попадает в code base его статус меняется в таблице еще раз.
3. Как только артборд с изменениями попадает в Zeplin, падает уведомление в отдельный канал в Slack. + Описание мерджа ветки с мастером в Abstract + лично через скайп, слак, в письме, устно.
Про положение элемента не понял вопрос.
0
НЛО прилетело и опубликовало эту надпись здесь
Какое отношение положение кнопки имеет к библиотеке компонентов?
Если речь про UX паттерны и лэйауты, то положение тех же кнопок жестко зафиксировано и описано, здесь не нужны никакие визуальные дифы. Разработчики получают финальные макеты через Zeplin, где уже ничего не надо двигать, так как макеты прошли ревью на этапе прототипов, отрисовки UI и проверки текстов
тех.писателями. Дальше сборка, отлов багов и продакшен.
Если речь про UX паттерны и лэйауты, то положение тех же кнопок жестко зафиксировано и описано, здесь не нужны никакие визуальные дифы. Разработчики получают финальные макеты через Zeplin, где уже ничего не надо двигать, так как макеты прошли ревью на этапе прототипов, отрисовки UI и проверки текстов
тех.писателями. Дальше сборка, отлов багов и продакшен.
-1
НЛО прилетело и опубликовало эту надпись здесь
Давайте отделим мух от котлет. Если дизайнер вдруг захотел поменять расположение кнопок или скругления у бордеров просто так, потому что вроде так прикольнее — это нефункциональное изменение. В нем нет смысла, пока не доказана его необходимость и польза. Если показало иследование, что так будет лучше, заметнее, кликать будут больше — это функциональное изменение.
Нет такого компонента как модальное окно с кнопкой справа. Делать настолько узкие и точечные компоненты — тупик. Если брать методологию атомарного дизайна, то модальное окно — это организм, который состоит из контейнера и кнопки, без привязки к какому-то конкретному краю. Доносить функциональное изменение исключительно через макет, чтобы разработчик сам сидел и смотрел diff'ы — это неправильно выстроенный процесс. На каждое функциональное изменение должна быть спека, таск в джире, что-то еще с описанием изменения. Если хотите смотреть рядом два макета, можно пользоваться sympli (функционал схож с Zeplin) или попробовать Kactus.io (похож на Abstract, но работает через Git-аккаунт), там такая возможность есть.
Нет такого компонента как модальное окно с кнопкой справа. Делать настолько узкие и точечные компоненты — тупик. Если брать методологию атомарного дизайна, то модальное окно — это организм, который состоит из контейнера и кнопки, без привязки к какому-то конкретному краю. Доносить функциональное изменение исключительно через макет, чтобы разработчик сам сидел и смотрел diff'ы — это неправильно выстроенный процесс. На каждое функциональное изменение должна быть спека, таск в джире, что-то еще с описанием изменения. Если хотите смотреть рядом два макета, можно пользоваться sympli (функционал схож с Zeplin) или попробовать Kactus.io (похож на Abstract, но работает через Git-аккаунт), там такая возможность есть.
0
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дизайн-система Acronis. Часть первая. Единая библиотека компонентов