Вайбкодинг на практике - бесплатный курс. Урок 4. Улучшаем дизайн

К моему глубокому сожалению, администрация VC решила, что мой аккаунт "коммерческий"

Причина такая:

Для аккаунтов с такой меткой, если я не буду платить по примерно 50к в месяц, выключается продвижение внутри площадки

Мотивация продолжать публиковать здесь бесплатный курс или делиться опытом я в себе не нахожу

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

Публиковать ссылки на тг-канал я не буду, а то вдруг я там случайно что-то продам и не поделюсь с Комитетом. Если кому-то интересен мой контент - он легко находится в поиске тг по имени

Спасибо всем)

P.s. вот еще оказывается как

Что это за курс

Я решил на практике показать, как создать приложение с помощью вайбкодинга — от идеи до готового продукта. Это не строгий курс с пошаговой инструкцией «как надо». Мы пройдём весь живой процесс со всеми ошибками, сложностями и решениями. Весь курс будет опубликован здесь бесплатно, поэтому ставьте реакции на пост, задавайте вопросы в комментариях — так больше людей сможет увидеть курс.

Первую часть и описание идеи продукта можно найти здесь:

В прошлом уроке в прототипе впервые появилась возможность пройти весь путь от регистрации до утверждения и печати договора. Логику согласования мы описали в книге, и прототип теперь ей следует.

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

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

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

Это сделано для более комфортного восприятия читателем, в самой работе этот шаг избыточен.

Мой перфекционизм потребовал еще одной правки - мне не нравится что файлы документации называются транслитом: vid/nabor.html, vid/obrazec.html, statusy.html, kniga.mdc. Помимо эстетики есть проблема - по имени не всегда понятно, что внутри: obrazec — это прототип, а nabor — UX-кит. Делаю это первым шагом, чтобы следующие промпты уже работали с новыми именами.

Режим: Auto · Plan → выполни план.

Результат: агент переименовал файлы через git, поэтому история изменений сохранилась, и поправил ссылки во всех страницах книги и прототипа. Снимки уроков в lessons он не трогал, старых имён в книге и правилах не осталось.

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

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

Подсвечивать изменения внутри текста я не хочу — юристу важно видеть формулировки целиком, но новые редакции должны быть заметны. Как и во втором уроке, сначала прошу агента изучить, как это сделано в других сервисах, и только потом менять UX-кит. Заодно переносим принципы вида из «Плана макета» в UX-кит: план работ со временем устареет, а правила вида нужны постоянно.

Правка большая, поэтому режим: /prompt-master → Plan → выполни план.

Перед тем как собрать промпт, /prompt-master задал два вопроса: для какого инструмента готовим промпт и что именно дописывать в «План макета» — только найденные в интернете подходы или ещё и мои требования.

Второй вопрос оказался по делу. В промпте я прошу дописать ресёрч в «План макета» и в то же время вынести оттуда принципы вида. Без уточнения агент мог бы сложить туда и требования. Ответил так:

Результат: в «План макета» агент дописал только ресёрч — как правки и комментарии показывают Word и Google Docs. Вывод простой: почти везде правка и комментарий выглядят по-разному. Комментарий пусть будет на полях справа рядом с местом в тексте, а правка показывается отдельно, с автором и кнопками «принять» или «отклонить».

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

Но есть проблема. Прототип мы трогать не просили, но он всё равно поменялся: UX-кит и прототип используют один и тот же файл стилей. Агент спрятал в нём старую колонку кнопок у пункта, и в прототипе пропали кнопки «Комментарий», «Редакция» и «Согласен». Согласовать договор в прототипе сейчас нельзя. Поправим это следующим шагом, когда будем переносить новый вид пункта в прототип.

Дальше переносим новый вид пункта из UX-кита в прототип и переделываем экран согласования. На большом мониторе договор стоит узкой колонкой по центру, а по бокам пусто. При этом над договором три блока управления, и сам текст начинается только на втором экране.

Здесь же исправляем мелочь, которую нашли в прошлом уроке: после утверждения контрагенту пишется «доступна версия для печати», а кнопки печати у него нет.

Режим: Auto · Plan → выполни план.

Перед тем как составить план, Cursor остановился и задал два вопроса. Трёхколоночного экрана в книге ещё нет, а от ответов зависит разметка:

Это то самое правило из урока 3: нет факта в книге — вопрос и стоп. На первый вопрос ответ уже был в моём промпте: обсуждение справа, напротив пункта. На второй — в книге: ещё в прошлом уроке мы решили, что стороны подписываются «Вы» и названием другой стороны из реквизитов. «Поставщик» в промпте был просто примером.

Заодно агент уточнил, почему пропали кнопки: UX-кит перешёл на новую разметку кнопок у пункта, а прототип всё ещё рисует старую, и общие стили её прячут.

Ответил коротко:

Результат: кнопки у пунктов вернулись — агент перевёл прототип на ту же разметку пункта, что и в UX-ките. Экран согласования теперь в три колонки: слева разделы с пометками «спор» и «ждёт нас», в центре договор, справа ссылка для контрагента, наши реквизиты и обсуждение выбранного пункта. Сверху строка со статусом, переходом к следующему открытому пункту и «Утвердить итог».

Слова из книги в интерфейсе заменены: «Вы предложили», «Лазурный склад предлагает», «Ответить», «Предложить свою формулировку», «Создан из шаблона … 12 марта». Агент заодно записал все эти решения в книгу и обновил список экранов.

Контрагент при первом входе видит приветствие: кто прислал договор, что от него нужно и сколько пунктов ждут ответа. По отключённой ссылке — «Доступ закрыт, попросите новую ссылку у отправителя». После утверждения кнопка «Версия для печати» есть у обеих сторон.

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

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

Режим: Auto · Plan → выполни план.

Результат: плашка «Режим прототипа» теперь по умолчанию в одну строку, а пометки «В книге ещё открыто» открываются по кнопке «Открытые вопросы».

На телефоне сверху одна строка — название проекта, статус и «Меню», первым виден текст договора, снизу закреплена полоса «9 / 14 · Следующий». Оглавление, ссылка и реквизиты уехали в меню. Действия с пунктом открываются снизу в шторке с крупными кнопками. Приветствие контрагента на телефоне стало компактной строкой с кнопкой «Скрыть» и не отодвигает договор вниз.

Версия для печати теперь отдельный документ: формат A4, только итоговый текст, номер пункта слева, подписи с линией, расшифровкой и «М.П.», внизу каждой страницы номер договора и «итоговая редакция от …». На экране одна кнопка «Распечатать или сохранить PDF».

Нашлась одна мелочь: в колонтитуле на всех страницах написано «стр. 0» — номер страницы не считается. Поправим сразу, промпт простой:

Агент нашёл причину: так написанный номер страницы браузер считает только как ноль, поэтому номер он перенёс в поле самой страницы. Чтобы проверить на договоре из нескольких страниц, он заодно увеличил шрифт и интервалы в печати — для договора это как раз нормально. Теперь внизу каждой страницы свой номер.

Когда прошёл прототип ещё раз, нашёл две проблемы. На телефоне не видно сквозного меню — его закрывает панель с меню пунктов. А кнопки «Ответить» и «Предложить свою формулировку» у каждого пункта получились слишком большими и некрасивыми. Лучше сделать одну аккуратную кнопку «Не согласен», через которую можно и ответить, и предложить свою редакцию.

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

Получившуюся книгу я скопировал в lessons/lesson-4/ и сделал коммит.

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

Вопрос к вам: как вы сейчас согласовываете договоры — Word в режиме правок, протокол разногласий, переписка в мессенджере или что-то ещё? Ответьте одной строкой в комментариях.

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

Версия документации по результатам данного урока здесь:

Предыдущие уроки:
Урок 0
Урок 1. Первые шаги и разочарование в результате
Урок 2. Исправляем ошибки
Урок 3. Продумываем user flow

Следующий урок:
Скоро