diff --git a/Dev_Docs/Figma/README.md b/Dev_Docs/Figma/README.md new file mode 100644 index 0000000..fc6c083 --- /dev/null +++ b/Dev_Docs/Figma/README.md @@ -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. diff --git a/Dev_Docs/Figma/TRANSFER_UI_SCREENS.md b/Dev_Docs/Figma/TRANSFER_UI_SCREENS.md new file mode 100644 index 0000000..5e4bdb4 --- /dev/null +++ b/Dev_Docs/Figma/TRANSFER_UI_SCREENS.md @@ -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/.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-правки. diff --git a/VERSION.properties b/VERSION.properties index 320fbca..bb0faf4 100644 --- a/VERSION.properties +++ b/VERSION.properties @@ -1,2 +1,2 @@ -client.version=1.2.261 -server.version=1.2.246 +client.version=1.2.262 +server.version=1.2.247