Перейти к содержанию

Поиск услуги и запись

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

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

Сохранить выбранное предложение

Страница замены цепи сообщает 1200 ₽ за работу и отдельную оплату детали. Если посетитель выбирает Центр, работа выполняется там. Если выбирает Речной, велосипед принимают для передачи в Центр. Эти сведения составляют контекст будущего обращения. Идентификаторов услуги и пункта недостаточно, если интерфейс не раскрывает их значение человеку.

Начальную ссылку можно представить как /booking/?service=chain-replacement&location=river. Она открывает форму с выбранными условиями, а не создаёт запись. Отправка должна происходить только после отдельного действия и понятного ответа. Иначе обычный переход по ссылке окажется неожиданным заказом, который мог выполнить даже робот или предпросмотр сообщения.

Вверху формы покажем резюме: «Замена цепи. Приём в Речном, работа в Центре. 1200 ₽ за работу, деталь отдельно. Срок уточняется после согласования». Рядом разрешим изменить услугу и пункт. Пока человек не отправил обращение, выбранный путь остаётся предположением о подходящем предложении, а не подтверждённым договором или забронированным временем.

Поле обращения Что сообщает Чего не означает
service_id Интересующая услуга Что диагноз уже подтверждён
intake_location_id Предпочтительный пункт передачи Место выполнения всех операций
symptoms Описание со слов посетителя Заключение мастера
own_part Есть ли собственная деталь Её совместимость
Контакт для ответа Как согласовать следующий шаг Разрешение на любые рассылки

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

Неполные сведения и ограничения выбора

Предположим, посетитель не знает модель трансмиссии. Форма не должна требовать выдумать её ради отправки. Для свободного описания добавим подсказку: укажите известные сведения и что именно происходит, неизвестное можно так и обозначить. Это помогает различить установленную замену и необходимость диагностики без ложного автоматического заключения.

В макете фрагмент резюме и выбора выглядит следующим образом. Он не содержит обработчика и не является готовой системой записи:

<section aria-labelledby="request-summary">
  <h2 id="request-summary">Условия обращения</h2>
  <p>Замена цепи: 1200 ₽ за работу, деталь отдельно.</p>
  <p>Приём в Речном; выполнение в Центре после согласования.</p>
  <label for="known-symptoms">Что происходит с велосипедом</label>
  <textarea id="known-symptoms" name="symptoms"></textarea>
  <p>Неизвестную модель оборудования можно указать как неизвестную.</p>
</section>

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

Не предлагайте точные свободные часы без источника актуального расписания. Наши данные содержат режим работы пунктов, но не занятость мастеров. Из интервала «11:00–18:00» нельзя вывести свободное место завтра в 12:00. Вместо календаря с придуманной доступностью используем предпочтительное время и объяснение, что сотрудник подтвердит возможность.

Адрес формы не следует смешивать с адресом информационной страницы услуги. Для обхода основной связи достаточно обычной ссылки с href; кнопка, которая строит весь маршрут только внутри обработчика JavaScript, усложняет обнаружение документа. Google описывает этот технический принцип отдельно от результата записи. Рекомендации по доступным ссылкам.

Ответ, который не обещает лишнего

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

Эти состояния пока описаны, а не реализованы. В архиве expected означает ожидаемый документ после урока, а не результат запуска формы. Для действующего сайта понадобятся серверная проверка, защита от повторной отправки, понятное хранение статуса и технический контроль доставки. SEO-содержание не заменяет эту работу; оно определяет, какие обещания система имеет право показывать.

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

Другой случай — выбранная услуга больше не доступна через пункт. Сервер не должен молча принимать прежний параметр. Интерфейс объясняет изменение и предлагает подходящий вариант, сохраняя описание проблемы. В текущем сценарии такой блокировки нет, но наличие отдельного списка возможностей филиала из восьмого урока позволяет её реализовать.

Параметры перехода не устанавливают цену

Посетитель может изменить параметры ссылки вручную, поэтому будущий обработчик получает цену и возможности пункта из своего подтверждённого источника, а не доверяет любому числу в адресе. Форма показывает стоимость труда по выбранному идентификатору и заново проверяет доступность маршрута. Это техническое следствие содержательной модели: разные уровни должны использовать один источник условий.

В учебном макете цены вообще не передаются через URL. Из адреса приходят только предпочтительные услуга и пункт, а неизвестные значения требуют понятного выбора. Если вместо river указан несуществующий филиал, нельзя незаметно заменить его Центром и продолжить как будто посетитель сам согласился. Правильное ожидаемое состояние объясняет, что пункт не найден, сохраняет описание проблемы и предлагает существующие места. Такая ситуация пока не выполнялась, но она входит в контракт будущей реализации и препятствует потере контекста обращения.

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