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

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

Почему формы вгоняют в тоску?

• Сложно заставить форму выглядеть одинаково. Если же она выглядит в разных браузерах и на разных платформах по-разному (что, по сути, не критично), появляются расхождения в размерах, расположении и выравнивании элементов — иногда до десятков пикселей. Это выглядит некрасиво и может поломать всю разметку;
• Сложно сделать форму такой же, как нарисовал её дизайнер. Ему в кайф, чтобы select был такой же точно в ширину, как и input, но на практике это не так — приходится дописывать кучу мелких дополняющих стилей. Круто придумывать своё оформление для выпадающих списков, но сделать такой кастомный застилизованный элемент управления — сущий ад с кучей чертей и глубоких котлов. На мой взгляд, формы должны выглядеть стандартным для платформы образом. Так они лучше узнаются. Но макет-то всё равно перед глазами, а значит он раздражает и загоняет в рамки;
• Сложно предусмотреть универсальные стили для разнообразных форм. Пятнадцать лет назад все восторгались CSS именно за это — написал пяток правил один раз, а работают они для всего сайта, всегда. С формами так выходит редко, потому что их привыкли рисовать, как бог на душу положит.

Таким образом, раздражение в предвкушении вёрстки очередной формы — верный признак того, что она хреново продумана и нарисована.

Форма на рисунке выше выглядит, в целом, привлекательно и достаточно аккуратно. Но мне не нравятся поля для выбора дат заезда и выезда, выравнивание подписей, внешний вид кнопки и самих полей. Я бы изменил всё это, чтобы получилось вот так.

Кажется, всё поменялось в лучшую сторону.

1. Поля для ввода даты стали более понятными: можно ввести дату цифрами (в идеале, в любом формате — это забота программистов), а можно выбрать во вслывающем календаре, щёлкнув на иконку в углу поля;
2. Появилось 3 обособленных этапа — выбор даты, выбор количества человек и подходящего номера, ввод контактной информации для подтверждения бронирования. Заполнять такую форму проще;
3. Выровненные подписи к полям, поля и кнопка выглядят более аккуратно. Такой вариант проще и для восприятия, и для реализации — не нужно выдумывать десяток CSS-классов для элементов разной ширины, расположенных как попало.

Поля для ввода даты

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

Это порождает несколько проблем для пользователей и разработчиков.

Во-первых, интерфейс календаря куда более понятный, чем несколько выпадающих списков. Если календарь не нравится, дату можно ввести руками, в произвольном формате. А ещё лучше — прикрутить к такому полю «подсказывалку», например, такую. Тогда вероятность ошибки станет нулевой (маньяки с отключенным Javascript идут лесом — они просто не увидят всплывающего окна), а парсинг значения даты станет предельно простым (var d = new Date('12.03.2010')).

Во-вторых, первоначальный вариант ввода дат допускает какую-то странную неоднозначость — сейчас кажется, что забронировать номер можно только на 2010 год. А что делать 30 декабря? Выводить только «декабрь ’10»? Не выводить его вообще, потому что бронировать номер на 31 декабря за один день — чушь? Или выводить уже следующий, 2011 год? Это слишком сложно.

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

Я допускаю лишь один вариант, зачем мог понадобиться первоначальный формат ввода даты — передача информации какому-то стороннему сервису бронирования, которым уже пользуются в отеле. Только такая «проблема» совсем уж надумана, решить её можно в 10-20 строк кода.

В моём варианте ввести дату проще: сразу видно, что дата заезда уже введена, а отъезда — нет.

Разбиение на этапы

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

Такие «этапы» также не помешают потому, что очевидна последовательность: сначала мы определяемся с периодом пребывания в гостинице, затем выбираем количество гостей и тип номера (сюда можно подставить наиболее ходовые значения, как и сделано в примере) и вводим какую-то информацию для связи.

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

Выравнивание

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

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

Стив Круг, автор книги «Не заставляйте меня думать!», писал об исследованиях, которые опровергают устоявшиеся стереотипы о движении взгляда при просмотре страницы (слева направо, сверху вниз). Практические наблюдения порой свидетельствуют об отсутствии упорядоченности в движении глаз — мы воспринимаем страницы по некоторым привычным шаблонам («сверху логотип, справа меню» — ага, ясно!), выхватывая первое попавшееся (и подошедшее — иначе говоря, понравившееся) и не замечая всего остального.

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

Выводы

• Верстать хорошие формы — просто и приятно;
• Верстать плохие формы — сложно и муторно;
• Рисовать плохие формы — тяжкий грех;
• Перекладывать обязанности программиста на нежнейшие плечи пользователей — грех смертельный.

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

Кто здесь? Что это?

Меня зовут Олег Громов, а это — мой личный блог. Я frontend-разработчик и руководитель начинающей фирмы 12faces (ссылка не работает). Мы проектируем взаимодействие с программой, а спроектировав, берёмся за реализацию: делаем графический дизайн, верстаем, пишем нужные скрипты, хорошенько тестируем и помогаем развитию проекта.

Пишите, не стесняйтесь!