Исследователи Массачусетского технологического института нашли способ оптимизировать форму роботов для передвижения по различным типам местности. Система RoboGrammar моделирует эти формы и определяет, какая конструкция будет работать лучше всего в заданных условиях.

Поговорим о самой важной части: формы.
То есть текстовые поля, чекбоксы, выпадающие списки и прочие удовольствия. Я ни слова не скажу об их оформлении, я поделюсь соображениями по поводу сценария работы формы по приёму данных (регистрационных, например).

Чтобы сделать классную процедуру регистрации, надо поставить себя на место посетителя паспортного стола или какого-либо другого органа, работающего в обмен на сданную в него макулатуру.

Ситуация 1.
Вы собрали 20 справок и 30 выписок, засунули в окошечко злой тётьке, приходите через 2 недели — а Вам говорят, что в одной из справок допущена ошибка — принесите новую.

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

С тем, что при регистрации приходится дважды вводить скрытый «звездочками» пароль, все давно привыкли. К тому же это совершенно логично: повторный ввод пароля уменьшает вероятность того, что вы допустите опечатку и зарегистрируетесь с неизвестным вам паролем.

Однако некоторым этого показалось мало, и они решили, что e-mail тоже нужно вводить дважды.

Никогда я так раньше не делал, однако, все по порядку.

Случилось мне сверстать красиво оформленную поисковую форму со всякими PNG-фенечками и кнопкой картинкой. Все бы ничего, пару дней все работало как часы, отправлялось, искало и т.д. А тут мне менеджер проекта и говорит: «Форма не работает». Как так? Глянул в ФФ — работает, в Опере — Ок, в ИЕ7 — работает, на шестерке завал. Блин. Как будто disabled на <input type=«image» src=«картинка»> выставлен, ан нет — ничего подобного.

Пробую onclick=«this.form.submit()» — Фиг вам.
Пробую onclick=«document.forms['form_name'].submit()» — Фиг.

Думаю, а что, если дело не в кнопке, ставлю обычный Сабмит — срабатывает только при попадании в два крайних правых пиксела — Блин.

И тут уже пришлось извращаться:
<form method="get" action="/search/" name="form_name">
<table cellpadding="0" cellspacing="0">
<tr>
<td><img src="/img/inner/spacer.gif" width="15" height="22"></td>
<td height="22"><input type="text" name="q" value="Поиск"></td>
<td width="27" height="22" onclick="document.forms['form_name'].submit()">
<input type="submit" value="" style="border-width: 0;
    background-color: transparent;
    background: url('/img/pretty_button.gif') 0px 3px no-repeat;
    width: 27px; height: 22px;">
</td>
</tr>
</table>
</form>


Что характерно, работает везде… :)

UPD: Хотя можно было и просто картинку вставить…

Изредко работая над своим личным проектом, я дошёл до задачи сделать форму… Форму добавления места. Проблема в том, что она достаточно не типична. Я решил написать по этому поводу статью, которая поможет глубже проникнуть в newforms новичкам.

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

В формах могут быть как языко-зависимые, так и языко-независимые поля.
Последние, естественно, в переводах не нуждаются.
А вот как представить редакторам языко-зависимые поля — это я и хочу обсудить.

Обязательное условие — все языковые версии должны редактироваться на одной странице.

На данный момент я вижу следующие два варианта:

1. Переключение языков в форме (например, через табы). Таким образом, мы представляем отдельную форму для каждого языка.

2. Переключение полей формы и заполнение всех языковых версий каждого поля по отдельности.

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

А есть ли какие-нибудь общеизвестные доводы по поводу: существительные или глаголы использовать в интерфейсе — в меню и на кнопках? Мне вот что сейчас пришло в голову.

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

Меню требует скорее существительного. Хотя бы потому что так сделано во всех программах. Плюс, исходя из параграфа выше, существительное символизирует некоторую отложенность действия (а меню как раз такие.)

Но что делать со смешанными меню?

Продукты | Загрузить | Купить | Новости | Дилеры | О компании
Форумы | Поиск | Помощь | Войти | Зарегистрироваться

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

Ёр мысли ар велкам! Апдейты в комментах

Здесь уже многое говорилось о различном виде веб-страниц в браузерах IE и FF (Safari, Opera).

Сегодня столкнулся с реальной проблемой. IE 7 не растягивает поле ввода на всю ширину экрана, а ужимает его до каких-то примерно 300px. При этом ВСЕ остальные браузеры отображают поле правильно. Вот код:

...form id=«form1» name=«form1»>
...input name=«textfield» type=«text» style=«width: 100%;»>

Кто-нибудь, интересно, знает, что делать с этим?
Вижу, что на Яндекс`e поле растягивается по ширине во всех браузерах…

Итак, решение: прописывать width: 100% не только в «style» самого элемента «input» формы, но и в родительском контейнере (в моем случае — в ячейке таблицы, содержащей элемент формы).

Спасибо ya.ru за исходный код.)

Я — никто в дизайне пользовательских интерфейсов. Иногда я, правда, делаю интерфейсы к своим программам, но, вообще говоря, я в этом ничего не понимаю. Это мой главный аргумент в этом топике — пользовательские интерфейсы разрабатываются для простых пользователей. То есть и для меня тоже, так как я один из них.

Тему формы отправки комментариев мусолили на этом сайте тысяча миллион девяносто раз. Это еще один топик «про это». Как обычно, в таких темах первая картинка — форма, требующая доработки. Не будем бросать вызов традициям — посмотрим на картинку:

               +-----------------------------+
Ваше имя:      | FedTroll IV                 |
               +-----------------------------+
Комментарий:
+--------------------------------------------+
| Владимир Владимирович, скажите пожалуйста, |
| почему нам с детства внушали, что          |
| Лепрозория и НЛО не существует?            |
|                                            |
+--------------------------------------------+


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

Мини пост вызванный огромным гневом в сторону дизайнеров вышеупомянутого сайта.
И так пришло мне сегодня письмо. примерно так:

и как же я удивился, что нет ни одного привычного мне способа ответа на сообщение. Думал почти минуту, кликал везде — никак. Оказалось что надо было выбрать чекбокс, возле сообщения и нажать сверху на кнопку ответить.

По-моему это классический пример как делать не надо. А ведь этот сайт приучает многих людей к интернету. Вот попадет человек на ваш крутой сайт и будет искать чекбокс и кнопочку.
UPD странная манера на хабре. Ставить плюсы топику и минусы автору. Или скорее всего тот кто ставит плюс топику ничего не делает с кармой автора, а тот кто ставит топику минус, заодно ставит минус в карму. Не справедливо как-то

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

Здесь представлены

Примечание: Luke Wroblewski является страшим дизайнером интерфейсов в Национальном Центре Приложений для Суперкомпьютеров, (NCSA), в котором появился первый широко распространенный графический браузер, NCSA Mosaic. В этом центре он проектировал интерфейсные решения для Hewlett-Packard, IBM, и Kellogg's и участвовал в совместной разработке Среды Взаимодействия для Открытого Портала (OPIE). Ниже перевод его статьи о выборе правильной разметки для отображения форм на веб-страницах.

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

–HTML: the Definitive Guide

Примечание: ниже находится перевод тезисов доклада «Learning to Love Forms» с конференции «WebVisions 2007» (автор Aaron Gustafson). Докладчик рассказывает о верстке форм, используя корректный и эффективный XHTML/CSS-код.

• Формы — это необходимое зло. Людям свойственно усложнять формы, хотя они могут быть представлены весьма просто.
• Рассматривайте верстку форм как создание обычного XHTML-кода. Но будьте готовы к несоответствиям со стороны браузеров и применению хаков.
• Разбивайте сложные формы на несколько простых частей.
• Старайтесь обеспечивать максимальную семантическую ценность кода.
• Не усложняйте дизайн форм.

XHTML & CSS приемы

1. Элемент FORM создает форму.
2. Единственным обязательным его атрибутом является ACTION, и он всегда должен быть URI.
3. По умолчанию METHOD выставляется в GET.
4. Атрибут NAME устарел, используйте вместо него ID.
5. Элемент FIELDSET используется для группировки связанных полей формы. Может быть вложенным.

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

Краткое содержание:

1. Аспекты изменение формы через систему темизации
2. Изменение формы в модулях
3. Применение Forms API
4. Примеры для обоих веток Друпала

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

На помощь приходит замечательный скрипт «Masked Input Plugin», который позволяет назначить для каждой формы маску, по которой данные будут заполнятся.

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

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

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

Самый простой метод — это некая унификация веб-форм в целом, будь то цветовые решения или стандартизированные иконки. Я решил предложить вам на суд расцветку для текстовых полей веб-форм. Она вполне может подойти и к спискам, но даже Internet Explorer 7 не разрешает расставлять какие-либо стили на свои любимые select'ы. Недолго думая над названием, я решил, что слово «Светофор» лучше всего отражает смысл этой унификации.

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

Дабы не быть голословным, приведу пример для jQuery:

$('#id_кнопки').click(function()
 {
  $('this').attr('disabled', 'disabled')
 }
);

В идеале, кнопка должна становиться активной только после того, как форма будет полностью валидна.

Как подсказал Хабрапользователь nooze, стоит учитывать, что в случае AJAX реакции на отправку, следует учесть ошибки (например, не совпадающие логин и пароль, или таймаут запроса)

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