В НормЦРМ есть раздел «Контакты». В него я добавил теги. И есть раздел «Регулярные платежи». В него я добавил категории. По сути — одно и то же.
Задача: показать новым пользователям заранее заготовленные примеры тегов и категорий, чтобы они быстрее сориентировались.
Ограничения: два языка интерфейса (дальше — больше), а также непредсказуемость того, с какими тегами и категориями будут работать разные пользователи.
Начал я, разумеется, с проектирования. Сейчас расскажу и покажу процесс, поделюсь результатом и промптом, с помощью которого Codex справился с задачей с первой попытки.
Прототипы я, как и 15 лет назад, делаю в Axure. На скриншоте — первая версия модалок добавления категорий.
После проектирования я её завайбкодил, протестировал, выкатил на прод и заполнил реальными данными на своём аккаунте.
И вот именно в момент добавления первых тегов и категорий я и задумался над тем, что остальным пользователям тут может понадобиться помощь.
Первое, что пришло в голову: сразу сделать набор предустановленных тегов и показать его в списке. Но тут возникали проблемы, с которыми не хотелось бороться:
-
Пришлось бы учитывать сразу два языка и всю вытекающую из этого логику
Если пользователь сменит язык интерфейса через неделю работы — часть тегов переведутся на другой язык, а часть (которые он уже использует) останутся на прежнем?
Часть предустановленных тегов и категорий были бы не нужны пользователю — и ему пришлось бы удалять их в отдельном разделе (либо каждый раз смотреть на них)
Поэтому я быстро отказался от этой идеи и переключил внимание на окно создания нового тега. Там весь интерфейс — это одно поле, да кнопки сохранения и отмены.
Изначально действует такая логика: если у пользователя пока нет ни одного тега — он при попытке добавить новый — сразу видит именно модалку создания нового тега (а не выбора из существующих).
Так что самым простым и элегантным решением оказалось такое: под полем, где вводится название тега, добавить набор примеров. Проектирование заняло пять минут времени и вот что получилось:
Логика такая:
При добавлении первого тега или категории пользователь сталкивается именно с этим интерфейсом, где может посмотреть на примеры и подставить что-нибудь из списка;
Если тег уже есть у пользователя — он не будет отображаться в списке;
Если все теги есть у пользователя — блок с примерами тегов скроется целиком;
Сравнение с тегами пользователя происходит без учёта регистра по полному совпадению;
Сравниваются пользовательские теги и примеры, являющиеся частью интерфейса (а значит переведённые на нужный язык), поэтому вопрос с языковыми версиями решается сам по себе.
Покрутив это в голове и посмотрев в прототипе, я подготовил промпт для Кодекса:
Модальное окно создания нового тега для контакта.
Под текстовым полем с названием тега добавляем новый блок, в котором перечислены примеры тегов, которые можно подставить в поле, кликнув по одному из них.Заголовок блока должен быть оформлен простым 16-м шрифтом, как текст: «Примеры тегов. Кликните, чтобы подставить в поле:»
После заголовка должно быть расстояние, отделяющее его от списка примеров тегов под ним.
Список примеров тегов:
— Оформлен 16-м шрифтом
— Через запятую
— Каждый тег оформлен как ссылка, а запятые между ними — как простой текст
— Каждый пример тега — с маленькой буквы
— Список примеров — в одну строку/абзац, переносы допускаются только по ширине контейнера (естественный wrap)
— Если у пользователя уже существует тег, совпадающий с тегом из примеров (регистр не учитываем) — этот пример не отображается в списке
— Если у пользователя уже используются все теги, совпадающие с тегами из примеров — то мы вообще не отображаем блок с примерами тегов вместе с его заголовком
— Если после фильтрации остался 1 пример — показываем его без лишней пунктуации (без ведущей/хвостовой запятой).
— При клике по примеру тега в списке — он автоматически подставляется в поле «Название тега» (подстановка заменяет текущее значение поля)Теги в примерах показываем на том языке, который сейчас выбран в интерфейсе пользователя. То есть, они должны быть обёрнуты в i18n переменные.
Примеры тегов храним в шаблоне списком.
Плюс сопроводил задачу скриншотом из прототипа. В результате работы убедился в том, что Кодекс не наплодил мне новых стилей, а использовал существующие — и перенёс код в дев, где всё и протестировал.
В итоге получилась вот такая логика (это уже скриншоты из живого интерфейса НормЦРМ):
А при переключении на английский будут отображаться уже все примеры, т.к. я заполняю всё на русском и при сравнении примеров и тегов совпадений не находится:
Вот и весь очередной кейс-малютка. На проектирование, разработку, деплой и тестирование ушло ровно 50 минут (я пользуюсь тайм-трекером). Надеюсь, кому-нибудь пригодится этот кусочек моего опыта.
Полезные ссылки на статьи на Хабре про то, как я делаю НормЦРМ:
udinhtml
Не претензия, просто наблюдение: попадаются на глаза ваши статьи уже давно и у меня сложился некий образ Форреста Гампа, который перед тем, как начать что‑то делать, уже все продумал наперед, остается только (бежать) кнопки нажимать. Вот эти вот «ушло ровно 50 минут», я бы только промт составлял столько же конкретизируя формулировки, или вникал бы в задачу столько же перед тем, как вообще начать что либо делать руками.
Или вот из соседней статьи: «Промпты иногда получаются внушительных размеров. И тут мне ну очень помогает навык слепой печати. При скорости в 400–500 символов в минуту постановка задачи кажется не такой мучительной (впрочем равно как и написание подобных статей)». Т.е. тут упор в собственное физическое ограничение ввода команд руками, а не в том, чтобы успевать продумать структуру промта и его детали, чтобы это не было проблемой, как будто весь текст уже у вас в голове и остается только напечатать\сделать.
«Кто ты, воин?» Сверхчеловек или часть работы остается вне трекера времени?
Ekamelev Автор
Отличное наблюдение! Вне трекера времени работы не остаётся. И важно учитывать один нюанс: я делал всю архитектуру проекта в одно лицо с нуля. И продолжаю делать. Началось всё в мае 2025. Это значит, уже скоро год будет.
Получается, что мне не нужно тратить время на то, чтобы во что-то въехать или что-то с кем-то согласовать. Во время каждого подхода к работе я косвенно затрагиваю разные участки системы и постоянно думаю над системными оптимизациями.
Например, мне при каждом новом подходе уже не нужно думать о каких-то атомарных элементах интерфейса — они уже все есть. Не нужно выдумывать новые модели, если старые хорошо работают.
Это счастье работы над проектом, где ты изначально полностью погружён в контекст. В клиентских проектах картина иная — я обычно несколько месяцев въезжаю в курс всего, выстраиваю систему в голове, дальше быстро делаю непосредственно проектирование и… обычно на этом моя работа заканчивается и нужно искать следующий проект :) Я называю это проклятием проектировщика-фрилансера. Очень хочется уже осесть в каком-нибудь постоянном проекте. Но пока это получилось сделать только в своём собственном.
Поэтому, в итоге, я действительно иногда обращаю внимание на свои физические ограничения, т.к. всё продумывание размазано по месяцам разрозненных задач.
За примером далеко ходить не надо. Возьмём эти последние 50 минут. Во время тестирования результата я заметил, что какие-то теги у меня написаны с заглавных букв, а какие-то со строчных, и что в разных частях интерфейса они могут отображаться по-разному. Это раздражало. Наблюдение и размышление, что с этим делать, заняло пять минут времени. Правки заняли ещё минут двадцать. Я уже на следующий день унифицировал отображение тегов во всех разделах, отображая их с заглавной буквы.
Спасибо, что не только написали по существу, но ещё и на соседнюю статью сослались. Очень приятно.