Я работаю в разработке ПО и с болью смотрю, как люди обычно сообщают о проблемах с сервисами и программами. Бывает «Я нажал на кнопку и там черный экран», а бывает даже — «Ваша программа не работает». Гайд о том, как нужно сообщать о проблемах.

Посмотрите на эту картинку, представьте себя на месте синего.

Закипели немного, да?

Почему этим вообще стоит заниматься

Есть же простой вариант: написать как смогу, а если что-то будет непонятно, то пусть уточнят, — отвечу на все вопросы. Зачем вообще заморчиваться?

Если картинка выше не сделала ответ понятней, попробую накинуть еще аргументов.

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

Ещё бывает так, что разбирать багрепорт начали через неделю после репорта (кто-то был в отпуске или просто высокая загрузка). Начали у меня уточнять, а я сам не могу разобраться, что же я имел ввиду. Им воспроизвести не удается, а я не могу понять своё же описание. ¯\_(ツ)_/¯ В эти моменты очень стыдно.

Ну и немаловажная деталь — нормально, внимательно сформулированный багрепорт показывает ваше уважение к получателю — вы сделали домашку, отнеслись ответственно. Заниматься именно вашей проблемой приятнее. Плюсик в карму.

Хороший багрепорт

Хороший с моей точки зрения багрепорт состоит из следующих блоков.

1. Понятное краткое описание проблемы

Описание проблемы нужно, чтобы баг потом можно было найти. В идеале из заголовка должен быть понятен домен (часть программы, экран), область ошибки и важность. Писать все подробности в заголовок лучше не стоит, все равно не влезет.

Хорошие примеры:

• Ошибка 404 при переходе на английскую версию статьи
• Неправильный отступ в кнопке с иконкой button primary transparent
• Приложение крешится при попытке отправить прогрессивный jpeg
• Невозможно задать себе имя «Ян», т. к. оно слишком короткое

Плохие примеры (мало подробностей):

• Ошибка 404
• Неправильный отступ в кнопке
• Приложение крешится
• Не получается изменить имя

Плохие примеры (слишком много подробностей для заголовка):

• Неправильный отступ в кнопке с иконкой button primary transparent. В жизни 6 пк 12пк 6 пк 8 пк, а надо 6 пк 8пк 6пк 6пк
• Приложение под macOS версии 10.5.5 build 56718 крешится при попытке отправить прогрессивный jpeg в общий чат. При отправке пнг такого нет

2. Как воспроизвести

Самый важный блок. Я стараюсь его писать именно в виде шагов, чтобы не комкать описание и ничего не пропустить. Пишу по шаблону: шаги — ожидаемый результат — полученный результат

Шаги
Конкретные шаги, которые нужно повторить для воспроизведения бага. Прямо как есть: зайти на страницу, нажать на кнопку, заполнить поле.

1) Открыть страницу профиля
2) Нажать на кнопку «Редактировать профиль»
3) Вписать в поле «Имя» значение «Ян»
4) Нажать на кнопку «Сохранить»

Ожидаемый результат
После шагов пишу ожидаемый результат, что я жду, после выполнения этих действий.

Ожидается: профиль сохранится

Полученный результат
А здесь описываю результат, который получил на самом деле.

Полученный результат: профиль не сохранился, около поля «Имя» текст ошибки «Имя должно быть не менее 3 символов».

3. Скриншоты или скринкасты

Шаги воспроизведения и полученный результат лучше снадбить скриншотами, а если ошибку сложно заскриншотить, то записать скринкаст. При записи скринкаста делайте заметные паузы (пару секунд) перед переходом между шагами и после результата, — так смотрящему будет проще скринкаст посмотреть.

4. Окружение

В окружении описываю релевантные версии программ, браузеров, пакетов, операционной системы. Иногда пишу разрешение экрана и версию ноутбука.

Как внедрить

Первое время может быть непросто. Хочется срезать углы и описать покороче, ведь «и так понятно».

Могу рассказать, что заметил у себя. Когда срезаю углы, потом обычно жалею: потом все равно приходится подробно описывать. И до сих пор бывают случаи, когда сам не могу разобраться, что же такое понаписал.

Мне помогает иметь шаблон багрепорта в заметках и трекерах. Скопировал, заполнил, молодец.

Сделайте удобно читателю

Вообще этот прием — один из примеров более общего приёма «сделайте удобно читателю».

Рассказываю как не выбешивать, даже ошибка если не воспроизводится.

Бывает такое, что ошибку, о которой пишут, воспроизвести сложно. Но ответ в трекере «У меня не воспроизводится» и последующее закрытие бага — совершенно хамские действия. Да и просто ответ «У меня не воспроизводится» не самый вежливый, если даже баг не закрывают. Даже когда автор не хочет хамить и хочет помочь, такой ответ, на мой вкус, настраивает на негативный контекст.

Почему так происходит. Я вижу две проблемы:

• Ответ в стиле пинг-понга: «проблема не на нашей стороне, следующий».
• Ответ не подразумевает продолжения, «не воспроизводится» и всё тут, я даже пробовать исправить не буду.

Этот контекст возникает сам собой. А чтобы убрать его приходится прикладывать дополнительные усилия.

Однажды я сообщал о своей проблеме с Конспектом. Со мной в личке связался Анатолий Буров и написал такое сообщение (цитирую с разрешения автора):

Спасибо за сообщение! Разбираемся.

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

Вижу на скриншоте в консоли, что на десктопном Сафари установлен блокировщик, который не даёт загрузить Яндекс.Метрику. Возможно, причина в этом. Сейчас проверим.

В связи с этим пара вопросов: а какой это блокировщик? И на айфоне тоже он настроен?

По смыслу «у меня не воспроизводится», при этом негативный контекст сообщения превращен в невероятную заботу «у меня не воспроизводится, но даже в этом случае ты в надежных руках, сейчас будем разбираться».

Я просто растаял.

Кроме заботы сделано предположение о возможной причине (кстати, верное. Так и оказалось, что это я своим блокировщиком сделал «баг») и предложения о дальнейшем траблшутинге.

Но в первую очередь я говорю про заботу в сообщении. Мне бы так уметь.

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

Отчасти это некий eat your own dog food.

Ноушен

Питч

Первые два скриншота уже не переснять, Питч переделал схему показа релизнотсов. Сейчас — третья.

Яндекс-Дзен

Наверное, это единственное хорошее в Яндекс-Дзене

Lunacy

Редактор Lunacy компании icons8, после обновления открывают артборд с изменениями.

Понятно, что так могут не все, но кто может — молодцы.

Рассуждаю про написания «зуум» и «зумм». Это копия твитер-треда twitter.com/mikeozornin/status/1424681440843911170

Никак не пойму зачем и почему люди пишут Zoom по-русски как «зуум» и «зумм» (встречал у коллег оба написания). Мини-тред про то, почему меня это смущает.

Во-первых, никто так не говорит «зуум».
Никто в речи не тянет „у“ долго, все говорят не [zuːm], а [zum]. Особенно заметно при склонении («в зуме»), мне даже выговорить «зууме» [zuːmɪ] сложно.

Удвоенную „у“ ещё хоть как-то можно было бы выговорить, если бы „у“ была безударная, но под ударением это совсем анреал.

Во-вторых, никто не говорит и «зумм».
Удваивать согласные на конце в речи у нас тоже не принято: «Бонн» в речи звучит как [bon], а не [bon(ː)]. Удвоение могло бы встретиться в середине слова, как в «оловянный» [ɐɫɐˈvʲanːɨɪ̯], но и так слово «зум» не звучит.

В-третьих, в русском «зуум» и «зум» просто одно и то же.
Длина звука в русском не является фонемообразующим фактором (не является смыслоразличительной).

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

В-четвертых, нет никакой надобности дублировать оригинальное удвоенное написание. При обрусении слов многие удвоенные согласные теряются: «business» → «бизнес», «blogger» → «блогер». И ничего.

В-пятых, откуда берется написание «зуум» я ещё могу понять (две гласные превратились в две гласные), откуда берется «зумм» я даже представить не могу.

Хотя могу предположить, откуда взялся «зумм» — из известного романса «Вечерний зумм»:
Вечерний зумм, вечерний зумм!
Как много дум наводит он
О юных днях в краю родном,
Где я любил, где отчий дом,
И как я, с ним навек простясь,
Там слушал зумм в последний раз!

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

Рассказываю о важном в работе принципе

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

Фуф, вроде обсудили и договорились, — ставим. Сделали анонс договоренности, записали её в командный ноушен.

Начали использовать. Раз, Вася многоточие не поставил. Ну, думаете, может забыл. Указали ему на ошибку, и он поставил. Но потом в следующий раз не поставил, и через один раз снова не поставил.

Начали разбираться, что не так, решили же, вот записано в ноушене. И тут он говорит:

.
.
.
— Вообще-то я был против точек.

Такое поведение — саботаж и нарушение принципа Disagree and commit.

Принцип получил распространение благодаря Джефу Безосу, который использует этот принцип в работе. Как понятно из названия, его суть заключается вот в чем:

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

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

Наш бро

До принятия решения разбирается, защищает свою точку зрения, приводит аргументы

После принятия придерживается принятого решения, как будто топил за него сам

Не наш бро и всех бесит

После принятия не придерживается принятого решения, и каждый раз напоминает, что он то вообще-то был против.

В продолжении тредов Романа Шамина про дружбу дизайнеров и фронтендеров решил вытащить в блог одну из статей наших гайдов — про то, что такое «хорошо переданный макет». Все вытащенные из гайдов статьи доступны по тегу гайдлайны.

Треды Романа Шамина:
teletype.in/@romanshamin/what-design-want-from-frontend
teletype.in/@romanshamin/what-frontend-want-from-design

Дальше привожу статью из наших командных договоренностей.

О чем эта статья

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

Эта статья описывает как хорошо передать макет в разработку.

Хранение и состав макетов

Список самих экранов

Уровень «Минимально достаточный»
Всем членам команды продукта понятно где и как искать макеты:

• где найти макеты по нужной фиче,
• где найти старый макет,
• как понять актуальная версия или нет.

Договоренности команды о процессе выкладывания макетов записаны.

При обновлении макетов уведомляется проектная команда (аналитик, фронтенд, тех. писатель, QA).

Состав экранов

Уровень «Минимально достаточный»
Для фичи понятен набор экранов, на которые вносятся изменения: какие экраны новые, какие экраны дорабатываются.

Если экранов несколько, то понятны переходы между экранами.

Уровень «Хорошо»
Доступна актуальная схема экранов продукта (карта сайта).

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

Экраны

Структура экранов

Уровень «Минимально достаточный»
Понятна структура экрана: из каких блоков состоит экран, какие между ними соотношения по размерам и отступам.

Как ведут себя блоки экрана при прокрутке и ресайзе.

Уровень «Хорошо»
У продукта есть понятная сетка, описаны типовые лейауты страниц: список, дашборд, форма редактирования, страница просмотра и т. д.

Элементы на странице

Уровень «Минимально достаточный»
По каждому визуальному элементу на макете понятно, что это такое: текст, компонент, иконка, паттерн.

По каждому компоненту понятно, что это за компонент, какой его режим используется, понятно, если в коде нет этого компонента или функции существующего компонента.

Понятны размеры элемента, его взаимоотношения с соседними элементами.

Понятно как элемент тянется, что будет, если в элементе будет меньше или больше контента.

Уровень «Хорошо»
Все элементы описаны, разработчик знает где искать документацию на каждый используемый тип элемента: текст, компонент, иконку, паттерн.

Размеры элементов и отступы между элементами логичны, ожидаемы и понятны.

Примеры:

Плохо: Случайные размеры блоков, фронтендерам сложно понять отступы

Плохо: Случайные размеры блоков, фронтендерам сложно понять отступ

Хорошо: Размеры блоков понятны

Хорошо: Размеры блоков понятны, блоки расположены предсказуемо по сетке

Кегли

Уровень «Минимально достаточный»
Для каждого текста на странице понятен стиль или mixin, который нужно взять, эти стили и mixin’ы однозначно определяются из самого макета.

Эти mixin’ы не противоречат компонентам, паттернам или аналогичным элементам других экранов продуктов.

Уровень «Хорошо»
Есть актуальная таблица миксинов, описаны общие принципы их использования.

Примеры:

Плохо: Кегль не замапплен, неясно какой типографический миксин взять

Хорошо: Кегль и цвет замапплен, понятно что указать

Цвета

Речь идет про цвет любого интерфейсного элемента: текста, иконки, рамки, фона, блока, линии.

Уровень «Минимально достаточный»
Не используются цвета не из палитры проекта.

Переменные цветов подписаны, разработчику легко понять, какую переменную использовать (копировать hex-код не норм).

Уровень «Хорошо»
Составлена таблица цветовых токенов: default text, disabled text, error icon для всех используемых в проекте тем.

В макетах прилинкованы цвета из этой таблицы (не error-500, а validation-text-color).

Примеры:

Плохо: Цвета не замаплены, неясно какой цвет выбирать

Хорошо: Цвета замаплены, понятно что указать

Отступы

Уровень «Минимально достаточный»
Понятны сами отступы между всеми блоками на странице и их внутренняя логика.

Отступы на макете не противоречат компонентам (например, в компоненте «кнопка» отступы 6 16, а на макете 6 12).

Уровень «Хорошо»
Описана интерфейсная микросетка и описание модулей.

Логика отступов описана, есть типовые отступы и их завязка на сетку.

Пиктограммы

Уровень «Минимально достаточный»
Разработчик знает, как вообще подключаются пиктограммы в проект.

Понятно, что это за конкретная пиктограмма, как ее подключить и вставить.

Уровень «Хорошо»
Есть общий список пиктограмм, их коды, параметры вставки в код продукта и документацию.

Иконки версионируются, к продукту или в документацию можно подключить нужную версию пакета иконок.

Примеры:

Плохо: Иконка не замаплена, нужно искать её в наборе самостоятельно

Хорошо: Указано какая иконка и из какого набора. Примечание: mc — префикс одного из наших наборов иконок.

Текст

См. также Правильный процесс вычитки (ссылки нет, статья не вытащена наружу).

Уровень «Минимально достаточный»
Рыба в макете правильная с точки зрения состояний, смысла и точная с точки зрения чисел и значений.

Нет никаких Значение-1, Значение-2, Значение-3 и Лорем ипсумов.

Из текста понятно, о чем он: это важно, чтобы техписатели могли его понять и улучшить.

Уровень «Хорошо»
Текст в состоянии production-не стыдно, техписатели только полируют его.

Состояния

Другие состояния

Уровень «Минимально достаточный»
Понятно, как сделать все остальные состояния: переключенные вкладки, переключатели, чекбоксы и радиокнопки (если они влияют на компоновку интерфейса).

Отрисованы или описаны (если этого достаточно) все варианты дропдаунов, селектов и других выпадаек.

Кроме самих этих состояний описаны переходы между ними.

Уровень «Хорошо»
Если блоки меняются значительно, то лучше не пытаться описать отдельные выпадайки, а нарисовать блоки целиком, чтобы было меньше путаницы

Пример:

Хорошо: Нарисованы альтернативные состояний экрана

Загрузка

Уровень «Минимально достаточный»
Понятно как загружаются элементы экрана, в какой последовательности, как отображается процесс загрузки.

Как должен вести себя продукт, если загрузка медленная, элементов много, или загрузка не удалась.

Пустое состояние

Уровень «Минимально достаточный»
Понятно, как выглядит пустое состояние всех блоков и элементов, когда в них нет данных.

Уровень «Хорошо»
Пустые состояния систематизированы, используются типовые решения.

Пример:

Валидация

См. Валидация данных

Уровень «Минимально достаточный»
Понятно, когда и как срабатывает валидация.

Как и когда показывается.

Все сообщения об ошибках проходят через дизайнера, для каждой из возможных ошибок дизайнер придумывает способ предотвращения ошибки или способ отображения, если её нельзя предотвратить

Уровень «Хорошо»
Валидация соответствует общему гайдлайну.

Валидация способствует не попаданию с ситуацию срабатывания валидации.

Много данных

Уровень «Минимально достаточный»
Понятно как работает экран, когда во всех потенциальных местах (текст, списки, таблицы) будет много данных.

Все вытащенные из гайдов статьи доступны по тегу гайдлайны.

См. также

Гайд Контура: guides.kontur.ru/principles/layouts/
Чек-лист Prit4er1: notion.so/5c03c7554ff542da9c77a6f420935282

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

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

Круто, что JetBrains как-то узнал о проблеме и изменил сплэшскрины.

Было:

Стало:

Ещё более стало:

Даже мне смотреть на первый сплэшскрин тяжелее и некомфортнее всего.

У меня в рабочем чате случайно зашла речь про новый сплэшскрин Вебшторма. Я вспомнил, что у меня же есть их коллекция.

2017

2018

2019

2020

2021

Коллекция в копилке (пополняется): scrapp.me/@mike.ozornin/tags/серия: сплешскрины джетбрейнса

Снова ищем, прошлый поиск

Я руковожу группой интерфейсных дизайнеров в Positive Technologies и ищу в нашу команду двух человек, чтобы делать корпоративные B2B-приложения.

Я слабо верю в поиск дизайнеров на хедхантере, но верю в нетворкинг и рекомендации.

Чем мы занимаемся

Мы делаем корпоративные продукты для специалистов по информационной безопасности («ибэшников»). Вы, возможно, про нас не слышали, но в России нет ни одного ибэшника, который бы нас не знал. Некоторые наши продукты хорошие, некоторые — отличные; наш WAF попадал в магический квадрант Гартнера (это типа круто), наша SIEM-система — лидер российского рынка SIEM.

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

В планах на этот (2021) год: изменить мышление продакт-менеджеров к customer development’у, осовременить наш ui kit и базу ui-компонентов, унифицировать интерфейсы продуктов, научиться делать некоторые задачи в режиме дизайн-бюро. В итоге — сделать так, чтобы продукты любили и за интерфейс тоже.

Есть и планы на команду: хотим активизировать обмен знаниями, приглашать других дизайнеров в гости и ходить сами.

Многие продакт-оунеры хотят всего этого, они на нашей стороне. Я ищу двух дизайнеров, которые бы захотели к нам присоединиться и остаться надолго.

Задачи, которыми придется заниматься

Разбираться со сложными системами и создавать для них элегантные решения.

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

Создавать интерфейсы B2B-продуктов: длинные формы, панели администрирования, конструкторы алгоритмов; определять внешний вид дашбордов, графиков, отчетов.

При необходимости — создавать прототипы, тестировать их на команде разработки или пользователях.

По возможности и при желании — участвовать в customer development продуктов, чтобы понять потребности пользователей.

Наш дизайнер

Имеет опыт проектирования интерфейсов CRM-систем, систем документооборота, промышленных или других подобных систем.

Имеет минимальный технический бэкграунд (знает в общих чертах, как работает интернет) и способен разобраться в новой для себя предметной области. Один на один с иб не оставим.

Умеет поддерживать логичность и целостность базовых интерфейсных компонентов и следить за консистентностью всего продукта.

Готов проверять свои гипотезы и макеты коридорным тестированием, анкетами, может провести юзабилити-тестирование.

Обладает вкусом и чувством эстетики. Считает, что удобство, эффективность и красота могут сочетаться в одном продукте.

О команде

Дизайнеров девять человек (четверо в Москве, трое в Новосибирске, двое в Питере). Каждый из них тесно работает со своей продуктовой командой, периодически все общаются между собой. Часть дизайнеров ведут внутренние задачи дизайн-отдела: гайдлайны, ui kit, дизайн-токены, развитие экспертизы в исследованиях.

Основной инструмент — Фигма, но есть пара дизайнеров, кто ещё не переехал со Скетча.

Есть свой ui kit, своя база ui-компонентов на Angular и гайдлайны по их использованию (если дойдут руки, опубликуем в этом году).

Фронтендеры и бэкендеры, которые не говорят «ой, это невозможно».

Процессы в разных проектах немного разные, но в среднем работа над очередной фичей проходит примерно так: раннее обсуждение фичи, проектирование сценариев, скетчи, макеты, авторский надзор за реализацией, пользовательское исследование сделанной фичи.

Если вам интересно и вы узнали себя хотя бы наполовину, напишите о себе:
mozornin@ptsecurity.com или в телеграм: @mikeozornin

Делюсь скриптами для решения проблемы ревью макетов в Цеплине или Фигме

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

Делать это в Цеплине или Фигме — катастрофа и унижение.

В Цеплине: зайти в список проектов, обновить проекты по времени обновления, зайти в проект, обновить экраны по времени обновления, открыть первый, посмотреть, перейти к следующему. В то момент, когда на глаза начинают попадаться знакомые макеты, нужно остановиться и перейти к следующему проекту. При этом Цеплин дико тормозит — посмотрел 10 макетов, потратил 5 минут. Хочется убиться.

В Фигме нет и этого. Нет ни версий, ни даты обновления, ни фильтрации, ни сортировки. Ходи по экранам и ищи новое. На Фигму я просто забивал.

Я написал себе пару скриптов, которые скачивают в виде png-файлов все обновившиеся с прошлого раза макеты. Пока доволен, на ревью всех проектов день уходит 10-15 минут. Вдруг кому-то тоже помогут.

Качать здесь:

github.com/mikeozornin/zeplin-and-figma-screen-download

Как использовать

1. Создайте токен доступа к Фигме или Цеплину
   Фигма: figma.com/developers/api#access-tokens
   Цеплин: docs.zeplin.dev/reference#introduction
2. Скопируйте config.py.example как config.py и впишите туда свои токены.
3. (Только для фигмы): Отредактируйте в файле config.py идентификаторы проектов, которые вам нужны. (Идентификатор проекта содержится в урле https://www.figma.com/file/__id-of-the-project__/YourProject)
4. Запустите нужный скрипт

Вы можете использовать как один скрипт, так и оба. Если нужно, отредактируйте скрипт запуска run.sh.

Как оно работает

Скрипты скачивают новые версии экранов из Цеплина и Фигмы в папку, названную по текущей дате (2020-11-06).

Скрипт для Цеплина работает умнее: скачивает только те экраны, которые обновлялись с момента прошлого запуска. Момент предыдущего запуска хранится в файле zeplin-checkpoint.txt, если его стереть, то скачаются все экраны снова.

В Фигме нет версий отдельных экранов, а версия файла меняется при каждом изменении. Сделать так же, как для Цеплина не получится. Поэтому скрипт для Фигмы качает все экраны из проектов (скачаются все корневые фреймы). После скачивания скрипт проверит, качался ли такой файл раньше, если такой файл уже встречался ранее, то скрипт удалит только что скачанный файл. В итоге он оставит только те, которые не качались раньше.

Для определения встречался такой файл, или нет используется md5-сумма файлов. Md5-суммы хранятся в файле figma-checkpoint.txt, если его стереть, то скачаются и останутся все экраны.

Как запускать регулярно

Если вам нужно, чтобы скрипт срабатывал сам в определенное время, добавьте его в планировщик крон или планировщик Windows.

Моё задание для запуска в 23:00 каждый день выглядит в кроне так:

00 23 * * * /Users/mike/work/git-repos/stuff/zeplin-download-recent/run.sh

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

Что может быть появится

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

Вопросы и предложения

Feel free, как говорится, написать на mike.ozornin@gmail.com. Ошибки, предложения, код-ревью, что угодно.