WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 12 | 13 || 15 | 16 |   ...   | 27 |

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

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

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

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

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

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

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

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

ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ЭЛЕМЕНТЫ УПРАВЛЕНИЯ Также к группе командных кнопок относится кнопка доступа к меню. Кнопки доступа кменю Формально, это попытка скрестить ужа (раскрывающийся список, см.

стр. 72) с ежом (кнопкой, см. стр. 64), но попытка удачная.

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

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

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

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

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

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

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

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

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

ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ЭЛЕМЕНТЫ УПРАВЛЕНИЯ Несмотря на то, что в большей части литературы чекбоксы и радиокнопки Чекбоксы и радиокнопки разбирают по отдельности, я решил нарушить эту традицию и описать их вместе, поскольку это помогает лучше понять различия между этими элементами.

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

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

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

Главное различие заключается в том, что группа чекбоксов дают возмож ность пользователям выбрать любую комбинацию параметров, радиокноп ки же позволяют выбрать только один параметр. Это сближает эти элемен ты со списками множественного и единственного выбора соответственно (о которых будет подробнее рассказано ниже).

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

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

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

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

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

К сожалению, этот метод работает не всегда. Поскольку в самом чекбоксе написано только то, что произойдет после его включения, но не описано, ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ЭЛЕМЕНТЫ УПРАВЛЕНИЯ что произойдет, если его не включить, такая конструкция не работает в ситуациях, когда пользователям по той или иной причине функциональ ность непоставленного чекбокса может быть непонятна. Например, если нужно спросить пользователя, в какой кодировке посылать ему письма, не получится заменить две радиокнопки Windows 1251 и KOI 8 единым чекбоксом KOI 8. Пользователь не обязан понимать, в какой кодировке система будет посылать ему письма по умолчанию. К счастью, такие ситуации редки.

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

Желательно вертикально располагать чекбоксы и радиокнопки в группе, поскольку это облегчает поиск конкретного элемента.

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

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

кружок или квадратик. На самом деле это совершенно не так! Нажима бельной должна быть ещё и подпись, просто потому, что закон Фитса (см.

«Быстрый или точный» на стр. 10) однозначно требует больших кнопок.

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

Сейчас это стало технически возможным (через JavaScript), но по инерции и вполне понятной лени никто чекбоксы нормальными не делает. Увы1.

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

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

ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ЭЛЕМЕНТЫ УПРАВЛЕНИЯ Как чекбоксы, так и радиокнопки, бывают двух видов: описанные выше Вариант для панелей инструментов стандартные, и предназначенные для размещения на панелях инстру ментов (см. «Панели инструментов» на стр. 90).

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

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

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

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

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

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

раскрывающиеся же работают исключительно как радиокнопки.

Pages:     | 1 |   ...   | 12 | 13 || 15 | 16 |   ...   | 27 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.