Библиотека FormStone. Оформляем радиокнопки, чекбоксы и списки


Содержание материала:

Оформление и стилизация option select, radio buttons, input checkbox CSS3

Стилизация option select, radio buttons, input checkbox на чистом CSS3, без использования дополнительных библиотек и плагинов jQuery.

Оформление и стилизация option select, radio buttons, input checkbox CSS3

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

Ниже приведен код оформления и стилизации option select, radio buttons, input checkbox на чистом CSS3, без использования дополнительных библиотек и плагинов jQuery. Важно отметить работоспособность кода и мощную кроссбраузерную поддержку.

Стилизация радиокнопок и чекбоксов при помощи CSS

Иногда, когда мы смотрим на радиокнопки или input type checkbox , то у нас возникают неприятные ощущения. Кажется, что они выглядят ужасно. Но пока не посыпалась нецензурные слова, я попытаюсь избавить вас от этого чувства.

Сегодня мы будем работать только с кодом. Для начала сформируем его структуру:

Если эта кнопка покажется вам некрасивой, не беспокойтесь. Так и должно быть, потому что все остальное мы сделаем при помощи CSS .

Первое что нужно сделать, это скрыть элемент, который генерирует саму некрасивую кнопку – тэг input . Мы все равно сможем нажимать ее, даже несмотря на то, что она скрыта. Как? Вложив input type checkbox в label .

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

Радиокнопка

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

На данный момент наша радиокнопка будет выглядеть следующим образом:

Гораздо привлекательней, не так ли?

Чекбокс (флажок)

Давайте начнем с простого HTML input type checkbox . Сейчас я хочу превратить переключатель, который вы видите на скриншоте, в нечто подобное:

Действительно красивый переключатель!

Наверняка вы видели input type checkbox , в которых тумблер скользит слева направо при нажатии. Такого эффекта можно легко добиться при помощи CSS . Давайте попробуем.

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

Затем добавьте немного пространства с левой стороны при помощи свойства padding . После этого задайте чекбоксу относительное позиционирование, так как нам нужно, чтобы он содержал в себе и все остальные элементы внутри span :

Перейдем к стилизации CSS input type checkbox при помощи псевдоэлементов :before и :after . Так сгенерированным CSS-кодом будет проще управлять:

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

Пришло время немного украсить эти псевдоэлементы. :after будет выступать в роли фона, а :before отвечать за переключение ползунка. Давайте отредактируем ширину элемента, чтобы он стал больше. Также не забудьте добавить inset shadow , чтобы он выглядел как бы вдавленным. Кроме этого не забываем про красный фон, который будет интуитивно указывать на “ выключенный ” режим:

Что касается :before , то нам нужно сделать так, чтобы элемент стал круглым, а также немного « приподнять » его при помощи эффекта box-shadow :

Во « включенном » режиме нам нужно сместить ползунок HTML input type checkbox в сторону, и изменить цвет фона с красного на оттенок голубого:

На этом все! Наши красивые чекбоксы и радиокнопки готовы!

Данная публикация представляет собой перевод статьи « Styling Radio and Check buttons with CSS » , подготовленной дружной командой проекта Интернет-технологии.ру

Стилизация чекбоксов и радиокнопок на чистом CSS с совместимостью для старых браузеров

Для того, чтобы оформить чекбоксы и радиокнопки, как того требует дизайн, сегодня не обязательно использовать JavaScript-решения (типа моего плагина jQuery Form Styler), т.к. для этого можно задействовать только CSS, причем с обратной совместимостью для старых браузеров (т.е. не в ущерб юзабилити), которые не поддерживают современные CSS-правила.

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

Кроме того, сохраняется возможность HTML5-валидации стилизуемых элементов (чего может не быть при использовании JavaScript-плагинов). В современных браузерах ее поддержка — уже давно норма.

Важные особенности

Чтобы всё получилось, важно учитывать следующее:

  1. Кроме, собственно, самого тега элемента, который мы хотим красиво оформить ( или ), понадобится тег , благодаря которому переключать элемент можно, кликая на текст, а не только на сам элемент.
  2. Тег должен находиться до тега (в этом случае состояние элемента формы переключается с помощью атрибута for ), либо он должен находиться внутри тега (в этом случае атрибут for не нужен, но понадобится тег-обертка для текста).

«Фокус» заключается в использовании псевдоселекторов :checked и :not . При этом сам чекбокс или радиокнопка делаются невидимыми, а их эмуляция осуществляется с помощью псевдоэлементов :before и :after для тега или вышеупомянутого тега-обертки.

Стилизация для современных браузеров

Рассмотрим оба вариант расположения стилизуемого элемента формы. Какой из них наиболее удобен — решать вам. Суть от этого не меняется.

Теги чекбокса и радиокнопки находятся перед тегом

В HTML-коде это выглядит следующим образом:

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

CSS-код для чекбокса будет таким:

CSS-код для радиокнопки будет таким:

С помощью свойств position , z-index и opacity для классов .checkbox и .radio мы визуально прячем оригинальные элементы, при этом они остаются на том же самом месте, где будут стилизованные элементы. А с помощью margin немного смещаем их, чтобы сообщение валидации HTML5 смотрелось гармонично. В зависимости от дизайна чекбокса и радиокнопки этот отступ можно подогнать.

Теги чекбокса и радиокнопки находятся внутри тега

HTML-код в данном случае будет следующим:

По аналогии с предыдущим вариантом — тег обязательно должен быть расположен перед тегами с классом .checkbox__text и .radio__text .

CSS-код для чекбокса будет таким:

CSS-код для радиокнопки будет таким:

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

Стилизация с учетом старых браузеров

CSS-код для чекбокса. В комментариях к коду я добавил пояснения касательно браузеров:

CSS-код для радиокнопки:

Примеры

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

Стилизация чекбокса

Рассмотрим стилизацию чекбоксов с помощью CSS. А также рассмотрим, как реализовать отметку чекбокса картинкой.

Стилизация чекбокса

Создадим input с типом checkbox и элемент, который будет новым чекбоксом .mycheckbox__new . Затем обернём их в label чтобы связать label и input. Это необходимо для того чтобы при нажатии на текст, изменялось состояние чекбокса.

Стилизуем новоиспечённый чекбокс: скроем стандартный input и при помощи оператора + в состоянии :checked будем закрашивать чекбокс.

Чекбокс картинкой


Для того чтобы реализовать чекбокс картинкой, в свойстве background добавим background-image . Я вставлю SVG-изображение прямо в CSS код используя base64

Аналогично стилизуется input типа радио

Если вам понравилась данная статья, рекомендую прочитать про стилизацию select

Чекбоксы и радиокнопки

Дата добавления: 2013-12-23 ; просмотров: 2507 ; Нарушение авторских прав

Рис. 1. Пример радиокнопок и чекбоксов.

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

Главное различие заключается в том, что группа чекбоксов даёт возможность пользователям выбрать любую комбинацию параметров, радиокнопки же позволяют выбрать только один параметр. Это сближает эти элементы со списками множественного и единственного выбора соответственно. Из этого различия проистекают все остальные. Например, в группе не может быть меньше двух радиокнопок (как можно выбрать что-либо одно из чего-либо одного?). Еще одно следствие заключается в том, что у чекбокса есть три состояния (выбранное, не выбранное, смешанное), а у радиокнопки только два, поскольку смешанного состояния у неё быть просто не может (нельзя совместить взаимоисключающие параметры). Но это было знание вообще. Теперь перейдем к алгоритму его использования.

В группе радиокнопок как минимум одна радиокнопка должна быть проставлена по умолчанию

Всякий раз, когда пользователю нужно предоставить выбор между несколькими параметрами, можно использовать либо чекбоксы, либо радиокнопки (или списки, но о них позже). Если параметров больше двух, выбор прост: если параметры можно комбинировать, нужно использовать чекбоксы (например, текст может быть одновременно и жирным и курсивным); если же параметры комбинировать нельзя, нужно использовать радиокнопки (например, текст может быть выровнен или по левому, или по правому краю).

Если же параметров всего два и при этом параметры невозможно комбинировать (т.е. либо ДА, либо НЕТ), решение более сложно. Дело в том, что группу из двух радиокнопок часто можно заменить одним чекбоксом. Предположим, что нужно дать пользователю выбор: показывать в документе линейки или не показывать. В этом случае логично поместить в диалоговое окно рамку группировки со словами Показывать линейки, а в эту рамку поместить две радиокнопки: Да и Нет. Понятно, что это решение очень тяжеловесно. Можно сделать проще: убрать рамку группировки и радиокнопки, а на их место поместить всего один чекбокс со словами Показывать линейки. В этом случае все будет хорошо.

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

И чекбоксы и радиокнопки желательно расставлять по вертикали, поскольку это значительно ускоряет поиск нужного элемента

Внешний вид.Традиционно сложилось так, что чекбоксы выглядят как квадраты, а радиокнопки – как кружки. Нарушать это правило нельзя. Желательно вертикально располагать чекбоксы и радиокнопки в группе, поскольку это облегчает поиск конкретного элемента.

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

Взаимодействие.Это может показаться невероятным, но до сих пор в интернете 99% чекбоксов и радиокнопок реализованы неправильно. Дело в том, что создатели языка HTML, ничего не понимавшие в проектировании интерфейсов, были поначалу искренно уверены в том, что в этих элементах управления нажимается только визуальный индикатор переключения, т.е. кружок или квадратик. На самом деле это совершенно не так! Нажимабельной должна быть ещё и подпись, просто потому, что закон Фитса (см. «Быстрый или точный») однозначно требует больших кнопок.

Но в интернете всего этого нет, поскольку в HTML конструкция чекбоксов и радиокнопок просто не позволяет делать нажимабельными подписи. Сейчас это стало технически возможным (через тег Label), но по инерции и вполне понятной лени никто чекбоксы нормальными не делает.

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

Другой аспект: при необходимости заблокировать элемент, желательно визуально ослаблять не только квадрат или круг, но и подпись.

Вариант для панелей инструментов

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

Рис. 2. Пример чекбоксов и радиокнопок на панели инструментов. Слева расположены чекбоксы (шрифт может быть и жирным и курсивным), справа радиокнопки (абзац может быть выровнен либо по левому, либо по правому краю).

Топ-пост этого месяца:  Самые популярные мессенджеры и социальные сети столицы

Обратите внимание, что визуально чекбоксы и радиокнопки не различаются. У них есть определенный недостаток: они не различаются внешне (насколько известно, ни в одной ОС метода визуального различения не выработано). Это не очень критично, поскольку панелями инструментов пользуются в основном сравнительно опытные пользователи, так что страдать по этому поводу не стоит. Тем не менее, на панелях инструментов полезно располагать группы радиокнопок отдельно от групп чекбоксов (чтобы они не смешивались в сознании пользователей).

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

Стилизуем checkbox css

Сегодня мы научимся изменять внешний вид наших чекбоксов только с помощью css. Тема это довольно популярная, но в большинстве решений используются jQuery плагины. В принципе, в этом нет необходимости. Сейчас мы в этом убедимся.

Для начала создадим обычный чекбокс (разметка):

Здесь чекбокс и текст для него. Все это обернуто в div. Это сделано специально и нужно! Кстати, кто не знал: for у тега label должен соответствовать нужному id чекбокса, чтобы при клике по тексту выбирался чекбокс.

Теперь перейдем к стилям:

Здесь все мега просто:) Использование псевдоэлемента after и состояние чекбокса :checked позволяет добиться желаемого результата. Логика: скрываем настоящий чекбокс. У описания для нужного чекбокса показываем псевдоэлемент и стилизуем его как угодно. При клике по описанию — чекбоксу присваивается свойство (чекнутый) и мы выражением input[type=checkbox]:checked + label:after меняем вид псевдоэлемента на нужный. Profit!

Стильные чекбоксы и радиокнопки на CSS3

Мы все хорошо знакомы с HTML чекбоксами и радиокнопками. Больше всего расстраивает то, что нет способа изменить их внешний вид. Они могут выглядеть по-другому в зависимости от вашей операционной системы или браузера, но мы не можем изменить их используя CSS.

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

Скройте чекбоксы

Это может показаться нелогичным, но чтобы наши чекбоксы и переключатели выглядели великолепно, мы должны скрыть их и забыть о них! Теперь мы не нуждаемся в них, для того чтобы прикрепить что-то рядом, поэтому допишем следующие стили.

Вы можете спросить, а что же мы будем делать без них? Но не переживайте, мы сделаем наши собственные чекбоксы.

Радиокнопки

Во-первых, вот наша разметка:

Теперь у нас есть раздел с тремя радиокнопками. Мы рассмотрим чекбоксы чуть позже в этом посте, по тому же принципу. Каждый input обернут в div с классом container. Кроме того, каждый input имеет label со span в нём.

Важно !

Поскольку мы скрыли входы радио и чекбоксов, единственный способ для нас получить к ним доступ — использовать label тег. Для правильной работы тег label должен содержать атрибут «for» с идентификатором соответствующего ввода. Если вход имеет идентификатор «radio-1», то атрибут «for» также должен быть «radio-1». Вы можете удивиться, почему текст внутри каждого label обернут в span:

Так как мы собираемся стилить кнопки с псевдоэлементами «::before и «::after, нам понадобиться родительский элемент, на основе которого они могут быть расположены. В этом случае это будет наш label:

Вот стили, которые подходят как для чекбоксов, так и для радиокнопок:

Свойства top и bottom установлены на ноль и объединены с «margin: auto;» это позволяет нашим элементам иметь центральное горизонтальное положение.

Вот как выглядят остальные стили:

Самая важная часть — последний набор правил, в котором в основном и заключается вся фишка. Псевдокласс «: checked» позволяет нам вносить изменения в элементы при проверке ввода. С помощью селектора ‘+’ мы можем выбрать следующий родственный элемент и нацелить наш «span.radio», где мы применяем новые правила к псевдоэлементу «:: after». В этом случае мы меняем его горизонтальное положение и цвет. Чтобы сделать переключение плавным, мы назначаем переход 0,25 секунды для свойства left и background-color. Теперь, когда мы нажимаем переключатель, переключатель движется плавно, а не быстро.

Чекбоксы

Если вам нужно создать настраиваемые чекбоксы, метод тот же. Взгляните на стили:

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

Отдельно

Если вы хотите использовать иконку FontAwesome в своем псевдоэлементе, вы должны включить её код в свойство content и указать свойство font-family как «FontAwesome». Например:

Коду «f00c» предшествует обратный слеш, который нужен для отображения символа Юникода.

Юникод можно найти на странице выбранной вами иконки:

Финал

Вот и все. Теперь мы создали полнофункциональные и красивые флажки и переключатели, которые вы можете настроить и использовать для своих собственных проектов. Вы можете просмотреть полный исходный код в демоверсии CodePen:

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

Надеюсь, в этом посте вы нашли полезную и понятную для себя информацию. Буду рада вашим комментариям ��

Контактная форма с чекбоксами и выпадающим списком

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

(Реклама: о том, как сделать красивые чекбоксы я описывал в этой статье, а о том как отправить прикрепленный файл — в этой)

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


Создание контактной формы с чекбоксами

Итак, создадим несколько полей:

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

Особое внимание на поля:

Именно эти поля и отвечают за checkbox, радиокнопу и выпадающий список.

Добавив стили я добился следующего внешнего вида:

Как всегда исходник в конце статьи. Продолжим…

Теперь поговорим о php. Не мудрствуя лукаво, я взял обработчик из прошлой статьи и просто дополнил его. Вот как он выглядит сейчас:

Как и в прошлый раз, код достаточно неплохо прокомментирован и особо заострять внимание я на нем не буду. Единственное что хотел бы добавить, так это то, что если вам не нужно поле email, то эти строки:

Замените на эти:

В таком случае письмо будет приходить не с email(a) указанного в поле пользователем, а как будто вы его отправили сами себе.
А на сегодня — все. Всем хорошего настроения. Подписывайтесь и комментируйте статью. Пока!

Радиокнопки и чекбоксы в HTML, их теги и атрибуты

Здравствуйте, уважаемые читатели сайта Uspei.com. Следующий элемент, который сегодня мы успеем разобрать радиокнопки и чекбоксы в html. Обычно они используются в целях задания вопроса внутри формы (о создании форм мы говорили тут) и, соответственно, через них мы можем предложить человеку варианты ответа. При этом он может выбрать только один из этих вариантов.

Радиокнопки — тип radio

Давайте приступим к реализации радиокнопок. Перейдем в код и для радиокнопок выделим отдельный абзац. В нем и создадим нашу радиокнопку. Кнопка создается при помощи тега input.

Тип укажем radio. Зададим кнопке имя и укажем значение, т.е. какое значение будет отослано обработчику, если эта кнопка будет активна. Для этой кнопке мы укажем значение «yes», т.к. эта кнопка будет отвечать за положительный ответ.

Давайте добавим метку label c ответом «Да» для того, чтобы человек кликнул по метке, и кнопка активировалась автоматически.

Теперь создадим ей противоположную кнопку с ответом «Нет». Для этого скопируем label и вставим после первого label. Поменяем «Да» на «Нет» и меняем значение «yes» на «no». Обратите внимание, что имя мы должны оставить то же самое. Это скажет браузеру о том, что эти радиокнопки принадлежат к единой группе и что они взаимоисключающие друг друга. То есть, если активировать одну кнопку, то другая деактивируется. Если имена кнопкам дать разные, то можно одновременно активировать обе кнопки.

Вот таким образом можно передавать обработчику значение = выбор того или иного ответа.

Давайте добавим сам вопрос после открытия абзаца. Спросим человека, любит ли он экономить время?

И еще один момент, который может вам пригодиться – это автоматическая активация кнопок изначально. Для этого есть специальный атрибут, который можно добавить к нужной кнопке. Эта кнопка будет активирована изначально. Атрибут называется checked — можно перевести как отмеченный. Этому атрибуту не нужно указывать никакого значения.

А вот и конечный результат.

Чекбоксы — тип checkbox

Альтернативой радиокнопкам в HTML являются чекбоксы, только в этом случае возможно выделять несколько элементов. Давайте для примера создадим новый абзац и спросим, какими инструментами для экономии времени вы любите пользоваться?
После вопроса укажем новый абзац для создания этих самых чекбоксов. Первый чекбокс будет для ежедневника.

Если проверить наш код в браузере, то выглядеть это будет так:

Теперь таким же образом создадим еще два чекбокса: хронометраж и свои наработки.

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

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

До встречи! Успевайте всё и всегда на страницах блога Uspei.com

Помоги проекту — подпишись на наш Яндекс.Дзен канал!

Чекбоксы и радиокнопки

Составные части программного интерфейса.

Элементы управления.

Кнопки

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

Командные кнопки

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

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

Иная ситуация в Интернете, где отсутствие операционной системы (откуда приходят элементы управления) и простота создания новых типов кнопок (это чуть ли не единственный элемент, с которым вообще удается что-либо сделать) привели к тому, что нестандартные кнопки не создает только ленивый.

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

В Интернете кнопка должна быть оформлена как текстовая ссылка, если она перемещает пользователя на другой фрагмент текста, и как кнопка – если она запускает действие

Размеры и поля.Как вы уже знаете, чем больше кнопка, тем легче попасть в нее курсором. Это правило по мере сил всеми соблюдается, во всяком случае, кнопок размером 5 на 5 пикселей уже практически не встретишь. Однако помимо простоты нажатия на кнопку есть другая составляющая проблемы: пользователю должно быть трудно нажать не на ту кнопку.

Добиться этого можно либо изменением состояния кнопки при наведении на неё курсором, либо установлением пустого промежутка между кнопками.

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

Считать экранную кнопку нажатой нужно не тогда, когда пользователь нажимает кнопку мыши, а курсор находится на кнопке, а тогда, когда пользователь отпускает нажатую кнопку мыши, курсор в это время находится на экранной кнопке, и находился на ней еще, когда кнопка мыши нажималась

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

Топ-пост этого месяца:  Алгоритм Яндекс «Королёв» - что это такое и как работает

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

Направление теней во всех элементах управления должно быть одинаковым: снизу справа

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

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

Никогда не удаляйте элементы, которые нельзя нажать, взамен этого делайте их заблокированными

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

Оба аргументы сильны. Действительно, стандарт. Действительно, нет времени. Но есть два контраргумента: во-первых, это не столько стандарт, сколько стандартная ошибка, во-вторых, думать можно и по дороге домой.

Если второй контраргумент особых объяснений не требует, то сущность первого полезно объяснить. Кнопка, запускающая действие, недаром называется командной. С её помощью пользователи отдают системе команды. Команда же в русском языке формируется посредством глагола в повелительном наклонении

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

Таким образом, следует всемерно избегать создания кнопок с ничего не говорящим текстом, поскольку такой текст не сообщает пользователям, что именно произойдет после нажатия кнопки. При этом есть одна тонкость. Существующие интерфейсы заполнены терминационными кнопками: «Ввод» (Ок), «Отмена» (Cancel) и «Применить» (Apply), что, собственно говоря, и позволяет разработчикам ссылаться на стандарт. Эти кнопки плохи.

С первой кнопкой понятно – это не глагол, а значит, кнопка плоха. Кнопка одна и та же во всех диалогах, значит всё ещё хуже. Вторая, хоть и почти глагол, плоха, поскольку не дает контекста (к тому же отглагольные существительные воспринимаются медленнее, чем соответствующие глаголы). Главный её недостаток, впрочем, заключается в том, что её, как правило, нечем заменить, так что приходится пользоваться ею. Третья, будучи и глагольной, и сравнительно уникальной, имеет другой недостаток: она почти всегда используется неправильно. На ней написано «Применить», но на самом деле её значение совсем иное. Разберем это подробнее.

Как правило, разработчики создают диалоговое окно, внизу которого располагают три кнопки: Ок, «Применить» и «Отмена» (прямо-таки триединство ошибки). Проблемы наступают тогда, когда пользователь делает что-либо в диалоговом окне и начинает думать, какую кнопку ему нужно нажать. Предположим, он всем доволен и нажимает кнопку ОК. Не считая слабо переданного контекста, все довольно хорошо. Все довольно неплохо, если пользователь нажмет кнопку Отмена – его команды просто не будут обработаны системой. А теперь предположим, что пользователь нажал кнопку «Применить». Система выполняет команду пользователя и меняет данные. Начинается самое интересное: теперь кнопка ОК не делает ничего (команда-то уже обработана), помимо закрытия окна. Т.е. эту кнопку в данном состоянии нужно переименовывать в Закрыть. Более того. Кнопка Отмена после нажатия кнопки Применить тоже начинает врать пользователю: она не отменяет действие, но просто закрывает окно. Таким образом, если делать интерфейс полностью однозначным, получается гадость: последовательность кнопок Ок, Применить и Отмена после нажатия кнопки Применить превращается в последовательность Закрыть, Применить, Закрыть.

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

Напротив, если бы вместо кнопки Применить была бы кнопка Предварительный просмотр, все бы работало великолепно. Мало того, что пользователь не путался бы в кнопках, он мог бы избежать многих ошибок, просмотрев результат своих действий перед их окончательным принятием. Но разработчикам реализовывать режим предварительного просмотра тяжело. Гораздо легче вставить кнопку Применить, а то, что пользователям это вредно, их не касается. Таким образом, кнопка Применить оказывается не просто ненужной, но и откровенно вредной. Её можно применять только в палитрах, заменяя ею кнопку ОК, чтобы показывать пользователю, что палитра не исчезнет с экрана после нажатия кнопки. Разумеется, в этом случае, с нею должна использоваться кнопка Закрыть, вместо кнопки Отмена. Во всех остальных случаях эта кнопка не нужна.

Помимо текста, на кнопках можно выводить пиктограммы. Пиктограмма (icons) – это маленькие картинки, служащие для обозначения кнопок и других объектов. Пиктограммы могут существенным образом увеличить ясность и усилить привлекательность интерфейса в данном приложении. Кроме того пиктограммы позволяют намного упростить процесс перевода названий на другие языки. Эта возможность редко используется в ПО, но очень широко в интернете. Однако у пиктограмм есть существенный недостаток – это затруднительное смысловое распознавание. В последних версиях операционных системах Macintosh и Windows при наведении курсора на пиктограмму появляется окно с текстом ее описания. Появляется естественный вопрос. Почему не использовать текст без пиктограммы? Формально, на таких кнопках пиктограммы не очень хороши из-за того, что они обычно должны передавать пользователям идею действия (т.е. глагол), а действие плохо передается пиктограммами. Конечно, даже и нераспознанная пиктограмма хороша тем, что она визуально отделяет кнопку от кнопки и для опытных пользователей обеспечивает ускорение при поиске нужной кнопки (пользователь может помнить, что ему нужна кнопка с синим пятном на пиктограмме). Пиктограмма будет полезной только тогда, когда она грамотно исполнена и легко читаема любым пользователем. Так что, судя по всему, пиктограммы хороши для тех кнопок, для которых пиктограммы нарисовать легко.


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

Кнопки доступа к меню

Также к группе командных кнопок относится кнопка доступа к меню. Формально, это попытка скрестить ужа (раскрывающийся список) с ежом (кнопкой), но попытка удачная. Идея проста. Существует много ситуаций, когда раскрывающийся список не помещается в отведенное для него место, поскольку текст в списке слишком велик. Первое, что приходит в голову, это вставить кнопку, нажатие на которую будет вызывать меню. В самой этой мысли нет ничего плохого, другой разговор, что без правильного исполнения она… Впрочем, по порядку.

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

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

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

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

Чекбоксы и радиокнопки

Рис. 1. Пример радиокнопок и чекбоксов.

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

Главное различие заключается в том, что группа чекбоксов даёт возможность пользователям выбрать любую комбинацию параметров, радиокнопки же позволяют выбрать только один параметр. Это сближает эти элементы со списками множественного и единственного выбора соответственно. Из этого различия проистекают все остальные. Например, в группе не может быть меньше двух радиокнопок (как можно выбрать что-либо одно из чего-либо одного?). Еще одно следствие заключается в том, что у чекбокса есть три состояния (выбранное, не выбранное, смешанное), а у радиокнопки только два, поскольку смешанного состояния у неё быть просто не может (нельзя совместить взаимоисключающие параметры). Но это было знание вообще. Теперь перейдем к алгоритму его использования.

В группе радиокнопок как минимум одна радиокнопка должна быть проставлена по умолчанию

Всякий раз, когда пользователю нужно предоставить выбор между несколькими параметрами, можно использовать либо чекбоксы, либо радиокнопки (или списки, но о них позже). Если параметров больше двух, выбор прост: если параметры можно комбинировать, нужно использовать чекбоксы (например, текст может быть одновременно и жирным и курсивным); если же параметры комбинировать нельзя, нужно использовать радиокнопки (например, текст может быть выровнен или по левому, или по правому краю).

Если же параметров всего два и при этом параметры невозможно комбинировать (т.е. либо ДА, либо НЕТ), решение более сложно. Дело в том, что группу из двух радиокнопок часто можно заменить одним чекбоксом. Предположим, что нужно дать пользователю выбор: показывать в документе линейки или не показывать. В этом случае логично поместить в диалоговое окно рамку группировки со словами Показывать линейки, а в эту рамку поместить две радиокнопки: Да и Нет. Понятно, что это решение очень тяжеловесно. Можно сделать проще: убрать рамку группировки и радиокнопки, а на их место поместить всего один чекбокс со словами Показывать линейки. В этом случае все будет хорошо.

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

И чекбоксы и радиокнопки желательно расставлять по вертикали, поскольку это значительно ускоряет поиск нужного элемента

Внешний вид.Традиционно сложилось так, что чекбоксы выглядят как квадраты, а радиокнопки – как кружки. Нарушать это правило нельзя. Желательно вертикально располагать чекбоксы и радиокнопки в группе, поскольку это облегчает поиск конкретного элемента.

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

Топ-пост этого месяца:  Соблюдение правил гигиены СУБД – как почистить базу MySQL

Взаимодействие.Это может показаться невероятным, но до сих пор в интернете 99% чекбоксов и радиокнопок реализованы неправильно. Дело в том, что создатели языка HTML, ничего не понимавшие в проектировании интерфейсов, были поначалу искренно уверены в том, что в этих элементах управления нажимается только визуальный индикатор переключения, т.е. кружок или квадратик. На самом деле это совершенно не так! Нажимабельной должна быть ещё и подпись, просто потому, что закон Фитса (см. «Быстрый или точный») однозначно требует больших кнопок.

Но в Интернете всего этого нет, поскольку в HTML конструкция чекбоксов и радиокнопок просто не позволяет делать нажимабельными подписи. Сейчас это стало технически возможным (через тег Label), но по инерции и вполне понятной лени никто чекбоксы нормальными не делает.

В Интернете первым признаком профессионально разработанного интерфейса являются нажимабельные подписи к чекбоксам и радиокнопкам

Другой аспект: при необходимости заблокировать элемент, желательно визуально ослаблять не только квадрат или круг, но и подпись.

Вариант для панелей инструментов

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

Рис. 2. Пример чекбоксов и радиокнопок на панели инструментов. Слева расположены чекбоксы (шрифт может быть и жирным и курсивным), справа радиокнопки (абзац может быть выровнен либо по левому, либо по правому краю).

Обратите внимание, что визуально чекбоксы и радиокнопки не различаются. У них есть определенный недостаток: они не различаются внешне (насколько известно, ни в одной ОС метода визуального различения не выработано). Это не очень критично, поскольку панелями инструментов пользуются в основном сравнительно опытные пользователи, так что страдать по этому поводу не стоит. Тем не менее, на панелях инструментов полезно располагать группы радиокнопок отдельно от групп чекбоксов (чтобы они не смешивались в сознании пользователей).

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

Списки

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

Списки бывают пролистываемыми и раскрывающимися, причем пролистываемые могут обеспечивать как единственный (аналогично группе радиокнопок), так и множественный выбор (чекбокс); раскрывающиеся же работают исключительно как радиокнопки. Но сначала необходимо рассказать об общих свойствах всех списков.

Ширина.Ширина списка как минимум должна быть достаточна для того, чтобы пользователь мог определить различия между элементами. В идеале, конечно, ширина всех элементов должна быть меньше ширины списка, но иногда это невозможно. В таких случаях не стоит добавлять к списку горизонтальную полосу прокрутки, лучше урезать текст элементов. Для этого нужно определить самые важные фрагменты текста (например, для URL это начало и конец строки), после чего все остальное заменить отточием (. ). Поскольку нужно максимально ускорить работу пользователей, необходимо сортировать элементы. Идеальным вариантом является сортировка по типу элементов. Если же элементы однотипны, их необходимо сортировать по алфавиту, причем списки с большим количеством элементов полезно снабжать дополнительными элементами управления, влияющими на сортировку или способ фильтрации элементов. Если можно определить наиболее популярные значения, их можно сразу расположить в начале списка, но при этом придется вставлять в список разделитель, а в систему – обработчик этого разделителя.

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

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

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

Раскрывающийся список, как правило, вызывает две проблемы, одна появляется преимущественно в ПО, другая – в Интернете. Первая проблема заключается в том, что иногда отсутствие места на экране не позволяет использовать ни чекбоксы с радиокнопками, ни пролистываемые списки множественного выбора. Приходится делать раскрывающийся список, в котором помимо собственно элементов есть «мета-элемент», включающий все элементы из списка. Этому элементу часто не дают названия, оставляя строку списка пустой, что неправильно, поскольку требует от пользователя слишком глубокого абстрагирования. Такой мета-элемент нужно снабжать названием, например, Все значения или Ничего.

В интернете есть другая проблема. Раскрывающийся список часто используется как навигационное меню. Это изначально неправильно, поскольку содержимое такого меню не видно сразу и уж тем более им трудно индицировать пользователям, в каком разделе сайта они находятся. Это, впрочем, не главное. Большая проблема заключается в том, что список снабжают скриптом, который запускается сразу по выбору значения. Такой метод имеет два недостатка. Во-первых, список исторически не является элементом управления прямого действия (как и чекбокс, например), что приводит к потере пользователями чувства контроля над системой. Во-вторых, раскрывающиеся списки довольно сложны, так что пользователи часто совершают моторные ошибки при выборе нужного элемента. Поскольку эта ошибка не может быть обнаружена системой и не всегда обнаруживается пользователями, часты ситуации, когда пользователь (как ему кажется) выбирает один раздел, а перемещается в другой, что совсем нехорошо. Таким образом, навигационные раскрывающиеся списки нужно снабжать кнопкой, которая и будет запускать действие, запускать же действие сразу после выбора элемента в списке нельзя.

Другим, более сложным вариантом списка является пролистываемый список. Пролистываемые списки могут позволять пользователям совершать как единственный, так и множественный выбор. Одно требование применимо к обоим типам списков, остальные применимы только к одному типу.

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

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

Рис. 4. Список единственного выбора. Обратите внимание, что в ситуациях, когда все элементы помещаются в список без пролистывания, список работает в точности как группа радиокнопок.

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

Рис. 5. Список множественного выбора с чекбоксами.

Гораздо лучше обстоят дела в ПО. Возможность безболезненно выводить в списке чекбоксы позволяет пользователям без труда пользоваться списками, а разработчикам – без труда эти списки создавать.

Комбобоксы

Комбобоксами (combo box), называются гибриды списка c полем ввода: пользователь может выбрать существующий элемент, либо ввести свой. Комбобоксы бывают двух видов: раскрывающиеся и расширенные. Оба типа имеют проблемы.

Рис. 6. Раскрывающийся комбобокс с установленным фокусом ввода (слева) и расширенный комбобокс (справа).

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

Проблемы расширенных комбобоксов, напротив, совершенно иные. Их с трудом, но можно реализовать в интернете (через JavaScript). Они имеют уникальный вид, отличающий их от остальных элементов управления. Зато их сравнительно трудно (хотя и гораздо легче, чем в интернете) реализовать в ПО, поскольку в Windows нет такого элемента, так что собирать его приходится из двух. При этом расширенный комбобокс потребляет много места на экране.

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

Поля ввода

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

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

С размерами по горизонтали интереснее. Конечно, ширина поля должна соответствовать объему вводимого текста, поскольку гораздо удобнее вводить текст, который видишь. Менее очевидным является другое соображение: ширина поля ввода не должна быть больше объема вводимого в поле текста, поскольку частично заполненное поле выглядит как минимум неряшливо.

Ширина поля ввода не должна быть больше максимальной длины строки

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

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

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

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

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

Крутилки

Крутилка (spinner, little arrow) есть поле ввода, не такое универсальное, как обычное, поскольку не позволяет вводить текстовые данные, но зато обладающее двумя полезными возможностями.

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

Добавить комментарий