Вы открыли сайт, выбрали услугу и нажали «Отправить заявку». Кнопка поменяла цвет, но ничего больше не произошло. Форма отправляется? Нужно нажать ещё раз? Данные уже потерялись? Для посетителя эти вопросы важнее названия технологии, на которой собран интерфейс.
В Гуси-Лебеди мы предлагаем обсуждать frontend через такие сценарии. Разберём, что происходит на стороне браузера, где начинается работа сервера и как проверить результат разработки. Пример с заявкой ниже условный, он не описывает выявленную ошибку на конкретном сайте.
HTML, CSS и JavaScript: из чего складывается работающий интерфейс
Frontend, или фронтенд, в контексте сайта связан с интерфейсом, которым пользуется посетитель. Сервер передаёт браузеру код и ресурсы, а браузер собирает отображаемую страницу. Общую схему клиента и сервера объясняет MDN.
На примере формы различие технологий выглядит так: HTML задаёт поля, подписи и кнопку; CSS определяет их расположение и оформление; JavaScript может обрабатывать действия, отправлять запросы и обновлять состояние интерфейса. У страницы может быть полезное поведение и без JavaScript: не каждое действие требует отдельного скрипта.
Это ещё и три разных предмета проверки. Поле может выглядеть аккуратно, но не иметь понятной подписи. Кнопка может реагировать на нажатие, но показывать успех до подтверждения обработки. Сама форма может работать на широком экране, но прятать сообщение об ошибке за экранной клавиатурой телефона. Совпадение с картинкой макета не отвечает на все эти вопросы.
Если вы заказываете адаптивную CSS-вёрстку, передайте исполнителю не только аккуратный макет, но и примеры длинных названий, сообщений и содержимого карточек. Это поможет договориться, как страница должна вести себя с настоящими материалами.
Фронтенд-разработчик превращает согласованный интерфейс в работающую страницу, связывает её элементы с данными и предусмотренными действиями. Но границы ответственности нужно определить для проекта: кто готовит тексты ошибок, кто описывает ответы API и кто проверяет результат отправки заявки. Название специальности не заменяет договорённость между участниками.
Что происходит после нажатия кнопки: браузер, сервер и состояния формы
В нашем примере посетитель вводит контакт и описание задачи. Браузер может сразу подсказать, что обязательное поле пустое или формат адреса электронной почты не подходит. Такая проверка помогает исправить ввод до отправки. Она не доказывает, что адрес существует или заявка дошла до менеджера.
После отправки серверу нужно самостоятельно проверить данные и выполнить предусмотренную обработку. Клиентская проверка не заменяет серверную: данные запроса можно изменить вне обычного интерфейса. Это ограничение прямо описано в руководстве MDN по проверке форм.
Для заказчика здесь есть практический вопрос: какое событие позволяет показать сообщение «Заявка принята»? Клик по кнопке, начало запроса и подтверждённое создание обращения являются разными событиями. Команда должна согласовать, какое из них сообщает сервер и что оно означает в конкретной системе.
Не оставляйте промежуток между нажатием и ответом пустым. Посетителю нужно понять, что отправка началась и стоит дождаться результата. При ошибке полезно объяснить, что можно сделать дальше, и сохранить введённое, если это допускает сценарий. Предложение «Попробуйте позже» без дополнительного способа связи особенно неприятно после длинного описания задачи.
| Ситуация для проверки | Что должен понять посетитель |
|---|---|
| Не заполнено обязательное поле | Какое поле нужно исправить и почему отправка остановлена. |
| Запрос ещё обрабатывается | Действие уже началось; повторное нажатие не является способом ускорить ответ. |
| Сервер отклонил введённые данные | Что исправить, сохранились ли остальные поля. |
| Соединение оборвалось | Результат пока неизвестен. Повторная отправка требует предусмотренного сценария. |
| Обращение принято | Что произошло и какой следующий шаг обещает компания. |
Обрыв соединения не обязательно означает, что сервер ничего не получил. Если повторное действие может создать дубль, его обработку нужно согласовать с backend-командой. Фронтенд может ограничить повторные нажатия, но одной заблокированной кнопки недостаточно для защиты всех способов отправки.
За пределами формы действует та же логика. У каталога бывают загрузка и отсутствие результатов. У личного кабинета может закончиться сессия. У файла может не начаться скачивание. Мы советуем включать такие состояния в обсуждение интерфейса до приёмки: только красивый успешный экран не описывает всю работу сайта.
В проекте веб-сервиса с личным кабинетом особенно полезно отдельно описать, что пользователь может делать с данными и как интерфейс сообщает об ограничениях. Выбор серверных технологий рассматриваем в статье о backend-стеке; здесь важна договорённость о поведении двух частей системы.
Проверка на телефоне: сможет ли человек закончить действие
Адаптивность легко оценить слишком поверхностно: открыть страницу в узком окне и убедиться, что блоки перестроились. Для нашей формы этого мало. Нужно пройти весь путь с телефоном: найти услугу, открыть форму, заполнить поля, исправить ошибку и увидеть результат отправки.
Обратите внимание на момент ввода. Экранная клавиатура уменьшает видимую область. Подпись поля, подсказка и сообщение об ошибке должны оставаться понятными в этом состоянии. Проверьте длинное имя, несколько абзацев описания и увеличенный текст. Эти действия могут показать проблемы, которых нет в аккуратном демонстрационном примере.
Попробуйте пройти форму с клавиатуры на компьютере. Видно ли, какой элемент сейчас выбран? Можно ли добраться до кнопки без мыши? Понятны ли подписи полей? Возможность выполнять действия с клавиатуры и видимый индикатор фокуса описаны в отдельных критериях WCAG: управление с клавиатуры и видимый фокус. Короткий проход по форме полезен, но не подтверждает соответствие сайта всем требованиям доступности.
Согласуйте список браузеров и устройств, который команда действительно проверяет. Формулировка «работает везде» не позволяет воспроизвести ошибку или принять результат. В записи проверки нужны браузер, версия, устройство либо параметры тестовой среды, последовательность действий и фактический результат. Эмуляция узкого экрана полезна, но не воспроизводит каждую особенность настоящего телефона.
Не делайте вывод о скорости по одному открытию на рабочем компьютере. Состояние сети, устройство, размер ресурсов и серверный ответ могут менять впечатление посетителя. Для приёмки сначала согласуйте, какой сценарий и в каких условиях измеряете. Универсальное обещание «всё загрузится мгновенно» здесь только мешает.
Как принимать frontend и что передать после запуска
В Гуси-Лебеди мы предлагаем принимать интерфейс по согласованным действиям. Для формы это не только совпадение с макетом: нужны успешная отправка, исправление ввода, ожидание ответа и предусмотренное поведение при сбое. Для каталога набор будет другим. Критерии должны следовать из возможностей конкретного сайта.
Перед проверкой подготовьте тестовые данные и безопасный способ отличать проверочные обращения от настоящих. Затем пройдите согласованный сценарий и сверяйте две стороны результата: что показал браузер и что зафиксировала система обработки. Сообщение на экране само по себе не подтверждает доставку письма или создание записи в CRM.
Если обнаружена ошибка, опишите её так, чтобы разработчик смог повторить: адрес страницы, среда, шаги, ожидаемое и фактическое поведение. «Форма глючит» оставляет слишком много вариантов. «После исправления обязательного поля кнопка остаётся недоступной» уже задаёт проверяемую задачу.
После запуска важны исходный код, инструкция по сборке, зависимости и порядок выпуска изменений. Для компонентов, связанных с сервером, сохраните описание формата запросов, ответов и ошибок. У команды сопровождения должна быть возможность понять, как воспроизвести проблему, собрать проект и проверить исправление. Секреты и доступы передают отдельно предусмотренным безопасным способом.
Зафиксируйте, какая версия была проверена. Контроль версий в Git помогает сопоставить изменения кода, но не заменяет прохождение сценария на установленном сайте после выпуска.
Хороший результат frontend-разработки ощущается в обычном действии: человек понимает, куда нажать, что происходит и как продолжить, если что-то пошло не по плану. Именно такой путь стоит показывать на приёмке вместе с внешним видом страницы.