Добавить документацию по Figma
This commit is contained in:
AidarKC
parent
f9a15ab192
commit
0f63f7dae6
33
Dev_Docs/Figma/README.md
Normal file
33
Dev_Docs/Figma/README.md
Normal file
@ -0,0 +1,33 @@
|
||||
# Figma
|
||||
|
||||
Эта папка хранит рабочие инструкции по переносу экранов SHiNE в Figma и по обратному переносу изменений из Figma в код.
|
||||
|
||||
## Что здесь лежит
|
||||
|
||||
- `README.md` — точка входа и краткий регламент.
|
||||
- `TRANSFER_UI_SCREENS.md` — подробная инструкция по переносу экранов UI в Figma и обратно.
|
||||
|
||||
## Когда читать
|
||||
|
||||
Читать перед любыми задачами вида:
|
||||
- перенести экран из `shine-UI` в Figma;
|
||||
- собрать новый Figma-файл для экранов SHiNE;
|
||||
- перенести изменения из Figma обратно в код;
|
||||
- уточнить, каким способом переносить экраны: по одному или пачкой.
|
||||
|
||||
## Ключевое правило
|
||||
|
||||
Для экранов SHiNE безопасный рабочий способ на текущий момент:
|
||||
- переносить экраны в Figma по одному;
|
||||
- не пытаться сразу переносить длинный auth-flow пачкой;
|
||||
- после каждого переноса визуально проверять результат в самой Figma;
|
||||
- только после удачного одного экрана переходить к следующему.
|
||||
|
||||
## Про Miro
|
||||
|
||||
Отдельной папки `Miro` пока нет.
|
||||
|
||||
Причина:
|
||||
- практики по Miro в проекте пока мало;
|
||||
- устойчивого процесса ещё нет;
|
||||
- как только появится стабильный сценарий работы с Miro, его нужно будет оформить аналогично Figma.
|
||||
224
Dev_Docs/Figma/TRANSFER_UI_SCREENS.md
Normal file
224
Dev_Docs/Figma/TRANSFER_UI_SCREENS.md
Normal file
@ -0,0 +1,224 @@
|
||||
# Перенос экранов UI в Figma и обратно
|
||||
|
||||
## Зачем нужен этот документ
|
||||
|
||||
Этот документ фиксирует практический опыт, который уже был получен на переносе стартового экрана, экрана регистрации и дальнейших попытках.
|
||||
|
||||
Главная цель:
|
||||
- чтобы агент не повторял неудачные попытки;
|
||||
- чтобы переносы делались одинаково;
|
||||
- чтобы изменения из Figma можно было уверенно переносить назад в `shine-UI`.
|
||||
|
||||
## Где находится основной UI
|
||||
|
||||
- основной клиентский UI: `shine-UI/`
|
||||
- маршруты и список pre-auth экранов: `shine-UI/js/router.js`
|
||||
- экраны: `shine-UI/js/pages/`
|
||||
- общие стили: `shine-UI/styles/main.css`, `shine-UI/styles/layout.css`, `shine-UI/styles/components.css`
|
||||
|
||||
## Что считать успешным переносом в Figma
|
||||
|
||||
Успешный перенос экрана в Figma — это не просто фон и прямоугольники.
|
||||
|
||||
Нужно, чтобы:
|
||||
- были видны все ключевые текстовые элементы;
|
||||
- кнопки были перенесены как отдельные элементы;
|
||||
- поля ввода были явно видны;
|
||||
- экран был узнаваем визуально;
|
||||
- пользователь мог вручную подправить макет в Figma;
|
||||
- после правок можно было понять, что именно переносить обратно в код.
|
||||
|
||||
## Текущий рабочий способ
|
||||
|
||||
На текущем проекте лучший практический способ такой:
|
||||
|
||||
1. Переносить только один экран за раз.
|
||||
2. Сначала читать конкретный `js/pages/<screen>.js`.
|
||||
3. Затем читать связанные стили из `styles/components.css` и `styles/layout.css`.
|
||||
4. После этого вручную собирать экран в Figma как отдельный frame с явными элементами.
|
||||
5. Проверять в Figma, что не получился только фон без текста и контролов.
|
||||
6. Только после успешной проверки переходить к следующему экрану.
|
||||
|
||||
## Почему нельзя переносить пачкой
|
||||
|
||||
Был получен негативный опыт:
|
||||
- при переносе сразу многих экранов в Figma часть экранов отображалась как фон без нормальных надписей и элементов;
|
||||
- длинные экраны с большим количеством текста и форм разваливались;
|
||||
- автогенерация давала внешний вид, непригодный для ручной доработки.
|
||||
|
||||
Поэтому правило такое:
|
||||
- auth-flow, регистрация, вход, onboarding — переносить по одному экрану;
|
||||
- после каждого экрана ждать визуального подтверждения пользователя;
|
||||
- не объединять 5-10 экранов в один проход без отдельного разрешения и без промежуточной проверки.
|
||||
|
||||
## Рекомендуемый порядок переноса в Figma
|
||||
|
||||
### Вперёд: код -> Figma
|
||||
|
||||
1. Определить точный экран.
|
||||
2. Найти файл экрана в `shine-UI/js/pages/`.
|
||||
3. Найти используемые CSS-классы через поиск по файлу экрана.
|
||||
4. Вытащить:
|
||||
- тексты;
|
||||
- состав кнопок;
|
||||
- поля ввода;
|
||||
- карточки;
|
||||
- блоки статуса;
|
||||
- последовательность секций.
|
||||
5. Если экран длинный, всё равно переносить его как один frame, но собирать блоками сверху вниз.
|
||||
6. В Figma создавать отдельный экран рядом с уже существующими экранами, а не смешивать всё в одну кучу.
|
||||
7. После создания экрана проверить метаданные/скриншот Figma, если инструмент это позволяет.
|
||||
|
||||
### Назад: Figma -> код
|
||||
|
||||
1. Снять актуальный скриншот изменённого Figma-экрана.
|
||||
2. Получить метаданные узла, если это помогает понять структуру.
|
||||
3. Сравнить Figma с текущим кодом экрана.
|
||||
4. Переносить обратно в код только реальные изменения:
|
||||
- порядок блоков;
|
||||
- тексты;
|
||||
- размеры/отступы;
|
||||
- наличие или отсутствие карточек;
|
||||
- подписи кнопок;
|
||||
- видимость блоков.
|
||||
5. Не придумывать новые UX-решения без отдельного подтверждения пользователя, если их нет в Figma.
|
||||
6. После правок проверять экран локально или как минимум по коду и зависимостям.
|
||||
|
||||
## Что переносить вручную
|
||||
|
||||
Вручную, а не автогенерацией, нужно переносить:
|
||||
- экраны регистрации;
|
||||
- экраны входа;
|
||||
- длинные формы;
|
||||
- экраны с несколькими карточками;
|
||||
- экраны с длинными объясняющими текстами;
|
||||
- экраны, где важен порядок блоков.
|
||||
|
||||
Причина:
|
||||
- именно они чаще всего ломаются при слишком автоматическом переносе.
|
||||
|
||||
## Какие ошибки уже были
|
||||
|
||||
### Ошибка 1. Перенос пачкой
|
||||
|
||||
Проблема:
|
||||
- несколько экранов были добавлены сразу;
|
||||
- пользователь увидел, что на экранах в Figma «какая-то ерунда».
|
||||
|
||||
Вывод:
|
||||
- переносить по одному.
|
||||
|
||||
### Ошибка 2. Видно только фон
|
||||
|
||||
Проблема:
|
||||
- frame создавался, фон и свечения были видны;
|
||||
- тексты и элементы либо не появлялись, либо получались непригодными.
|
||||
|
||||
Вывод:
|
||||
- при сложных экранах собирать элементы вручную и явно.
|
||||
|
||||
### Ошибка 3. Слишком вольная реконструкция
|
||||
|
||||
Проблема:
|
||||
- экран формально был перенесён, но визуально не соответствовал ожиданию пользователя.
|
||||
|
||||
Вывод:
|
||||
- для SHiNE важнее узнаваемый и редактируемый экран, чем «формально похожий» экран.
|
||||
|
||||
## Обязательные проверки после переноса в Figma
|
||||
|
||||
После каждого нового экрана агент должен проверить:
|
||||
- виден ли заголовок;
|
||||
- видны ли кнопки;
|
||||
- видны ли поля ввода;
|
||||
- не исчезли ли длинные тексты;
|
||||
- не сломан ли порядок секций;
|
||||
- не оказался ли на холсте только фон и пустые прямоугольники.
|
||||
|
||||
Если хотя бы один пункт не выполнен:
|
||||
- не считать перенос завершённым;
|
||||
- либо переделать экран сразу;
|
||||
- либо остановиться и показать пользователю только после исправления.
|
||||
|
||||
## Правила для длинных экранов
|
||||
|
||||
Если экран длинный, например регистрация:
|
||||
- высота frame может быть больше стандартной мобильной высоты;
|
||||
- секции должны идти в правильном вертикальном порядке;
|
||||
- отдельные карточки должны быть вынесены в отдельные блоки;
|
||||
- тексты лучше упрощённо располагать вручную, чем терять их совсем.
|
||||
|
||||
## Правила для экрана регистрации
|
||||
|
||||
Экран `register-view` особенно чувствительный.
|
||||
|
||||
При переносе нужно отдельно учитывать:
|
||||
- заголовок и стрелку назад;
|
||||
- поля логина и пароля;
|
||||
- переключатель режима 12 слов;
|
||||
- сетку слов;
|
||||
- строку статуса длины пароля;
|
||||
- строку статуса проверки логина;
|
||||
- кнопку проверки логина;
|
||||
- отдельную карточку первого сервера;
|
||||
- отдельную карточку FAQ;
|
||||
- нижние кнопки `Назад` и `Далее`.
|
||||
|
||||
## Правила для экрана входа
|
||||
|
||||
Для экранов входа важно не смешивать:
|
||||
- экран выбора способа входа;
|
||||
- вход по логину/паролю;
|
||||
- вход через другое устройство;
|
||||
- вход по QR.
|
||||
|
||||
Каждый из них переносить отдельно.
|
||||
|
||||
## Что делать после правок пользователя в Figma
|
||||
|
||||
Если пользователь изменил экран в Figma:
|
||||
|
||||
1. Считать Figma источником визуальной правки.
|
||||
2. Сначала понять, что именно изменено:
|
||||
- тексты;
|
||||
- порядок блоков;
|
||||
- наличие блоков;
|
||||
- размеры;
|
||||
- отступы;
|
||||
- логика flow.
|
||||
3. Переносить эти изменения назад в код минимально необходимыми правками.
|
||||
4. Если из Figma следует уже не только визуальная, но и UX-логическая правка, отдельно проверить, что она согласована пользователем.
|
||||
|
||||
## Когда нужно добавить заметку в Pending_Features
|
||||
|
||||
Если после изменения по Figma:
|
||||
- поменялась логика flow;
|
||||
- поменялась регистрация/вход;
|
||||
- нужен реальный прогон на test2;
|
||||
- затронута интеграция с Solana;
|
||||
|
||||
тогда нужно добавить файл в `Dev_Docs/Pending_Features/`.
|
||||
|
||||
## Что пока не оформлено для Miro
|
||||
|
||||
По Miro пока нет устойчивого процесса.
|
||||
|
||||
Из того, что уже понятно:
|
||||
- пока не стоит обещать такой же отлаженный перенос, как для Figma;
|
||||
- сначала нужно накопить хотя бы 2-3 реальных сценария работы;
|
||||
- только после этого оформлять отдельную папку и регламент.
|
||||
|
||||
## Краткая памятка для агента
|
||||
|
||||
Если задача звучит как:
|
||||
- «перенеси экран в Figma»;
|
||||
- «добавь экран в Figma»;
|
||||
- «я поправил экран в Figma, перенеси назад»;
|
||||
|
||||
то агент должен:
|
||||
|
||||
1. Прочитать этот документ.
|
||||
2. Работать по одному экрану.
|
||||
3. Не переносить auth-flow пачкой.
|
||||
4. Проверять результат после каждого экрана.
|
||||
5. При переносе обратно в код не гадать, а опираться на Figma-правки.
|
||||
@ -1,2 +1,2 @@
|
||||
client.version=1.2.261
|
||||
server.version=1.2.246
|
||||
client.version=1.2.262
|
||||
server.version=1.2.247
|
||||
|
||||
Loading…
Reference in New Issue
Block a user