Эргономика и юзабилити: Элементы пользовательского интерфейса (стр. 4 )

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

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

Задача раскладывается на две составляющие: во-первых, нужно реализовать возможность свободного перемещения по последовательности. Если экранов немного (3-5), то вполне можно ограничиться стандартными кнопками Назад и Далее. Если же экранов много, переход по этим кнопкам будет, как минимум, медленным. В таких случаях разумно дополнять кнопки раскрывающимся списком (при этом, возможно, исключая из него ещё не пройденные экраны), либо, если есть место, снабжать мастера списком всех экранов (отмечая текущий и пройденные экраны). Независимо от числа экранов в последовательности, необходимо информировать пользователей об объеме оставшегося действия (чтобы дать им возможность оценивать количество работы и тем самым повышать их чувство контроля над системой). Справедливости ради надо уточнить, что в длинных последовательностях показ объема оставшихся экранов может снизить мотивацию пользователей в начале действия, но повысить мотивацию в конце («осталось немного, не буду это бросать»).

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

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

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

Рис. 5.5.1-1. Идентификация текущего состояния на .

На всем протяжении оформления заказа покупателя информируют о том, на каком этапе он находится.

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

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

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

5.6. Функциональность и окна

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

5.6.1. Лишние окна

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

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

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

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

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

5.6.2. Необходимые окна

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

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

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

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

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

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

5.6.3. Загрязнение окнами

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

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

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

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

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

6.  Пиктограммы

В традиционном ПО пиктограмм используется довольно много:

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

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

6.1. Чем пиктограммы плохи

В 1981 году Истерби и Грейдон провели масштабное исследование ста восьми пиктограмм, выбранных экспертами ISO для использования по всему миру. Некоторые из этих пиктограмм широко использовались и до этого. Цель исследования заключалась в том, чтобы определить, сколько пиктограмм правильно бы распознавались двумя третями целевой аудитории. Результат: три.

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

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

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

Происходит это оттого, что размер пиктограммы практически не позволяет нарисовать на ней что-либо однозначное. А если размер увеличить, то пиктограмма будет пожирать слишком много места и очень долго распознаваться пользователями (о чем ниже). При этом понимание смысла неоднозначности возможно только при наличии контекста. Например, замок обозначает, что нечто запирается. Но что именно запирается и как именно запирается, сказать невозможно. Однако если пиктограмма расположена в диалоговом окне, становится понятно – запирается всё, что находится в окне; если пиктограмма в рамке группировки – запирается всё, что находится в рамке; если на другой пиктограмме – запирается объект, который данная пиктограмма символизирует.

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

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

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

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

она должна иметь внятный и однозначный контекст; её сюжет должен быть пользователям понятен; этот сюжет должен быть удовлетворительно нарисован.

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

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

6.2. Чем пиктограммы хороши

Достоинств у пиктограмм несколько:

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

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

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

6.3. Какой должна быть хорошая пиктограмма

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

6.3.1. Разборчивость

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

Сложно назвать пиктограммы на рис. 6.3.1-1 контрастными и уж тем более сложно признать их непохожими друг на друга. Если бы не подписи под ними, пользователи путались бы даже в этих 8 значках.

Рис. 6.3.1-1.

6.3.2. Стандартность сюжета и его реализации

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

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

6.3.3. Минимально возможная детализация сюжета

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

Рис. 6.3.3-1. Пример избыточной детализации пиктограмм.

Например, зачем нужен зеленый значок на папке с документами? Или к чему рисовать содержимое корзины, когда метафора самой корзины и так легко узнаваема?

6.3.4. Стандартность стилистики

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

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

Рис. 6.3.4-1. Пример пиктограмм выдержанных в единой стилистике.

Во второй строчке оригинальные пиктограммы программы, в первой строчке стандартные Windows пиктограммы (открыть, сохранить, поместить в буфер и т. д.), адаптированные под стилистику программы.

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

6.3.5. Эстетическая привлекательность

По большей части субъективна.

6.3.6. Полнота набора

Одна и та же по смыслу пиктограмма должна быть продублирована в системе в нескольких разных вариантах, поскольку пиктограмма может проявляться в различных контекстах. Так, главная пиктограмма программы в Windows проявляется не только в Explorer, но и на панели задач, в строке названия программы и в некоторых других местах. Проблема в том, что основная пиктограмма имеет размер 32 на 32 пикселя, но почти везде она должна показываться с половинным размером (16х16 пикселей). Если не создать дополнительно уменьшенную пиктограмму, то основная пиктограмма будет просто уменьшаться при выводе, что существенно, вплоть до полной неразборчивости, портит её качество. Т. о. чем полнее набор, тем лучше.

Рис. 6.3.6-1. Пример набора пиктограмм.

Слева основная пиктограмма MS Word и пиктограмма его документа. Если не нарисовать уменьшенных пиктограмм, то в строке названия программы и в меню будет показываться нечто непонятное (в центре). Однако если уменьшенные пиктограммы нарисовать отдельно, никаких проблем не возникнет (справа).

Правило формирования набора очень простое: все пиктограммы в наборе должны максимально походить друг на друга. К сожалению, простота это правила не приводит автоматически к его повсеместной выполнимости; если с парой 32x32 и 48x48 проблем никогда не возникает, то с парой 16x16 и 32x32 проблемы происходят постоянно, поскольку красота большой пиктограммы не влезает в малую.

Эта проблема имеет два решения:

можно сначала рисовать маленькую пиктограмму, а уже на её основе рисовать большую; можно выделить в большой пиктограмме основной элемент, и перенести в малую только его.

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

6.3.7. Пиктограмма системы и пиктограммы файлов

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

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

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

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

Рис. 6.3.7-1. Примеры пиктограмм для файлов шаблонов.

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

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

6.3.8. Пиктограммы панели инструментов и меню

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

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

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

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

7.  Курсоры

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

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

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

Контрольный список интерфейса ПО

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

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

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

Окна При проектировании было учтено, при каком разрешении, а так же размере монитора и шрифтов будут работать пользователи. Заголовки Заголовки короткие и адекватные содержимому окна. Заголовки соответствуют названиям элементов, при помощи которых окна были вызваны. Если окно вызывается элементом, не имеющим явного названия, в заголовке окна отражается название экранной формы. Дизайн окна Тип окна (модальное, немодальное, возможность минимизации/максимизации) был выбран осознанно, в соответствии с задачами пользователей. Управляющие и информационные элементы расположены достаточно далеко друг от друга (не менее 7 DLU). Информация в окне адекватно сгруппирована (связанные элементы объединены в группы). Кнопки находятся в секции, на которую они оказывают непосредственное воздействие. Терминационные кнопки (управляющие окном) расположены либо снизу в ряд либо справа в колонку. Переход от элемента к элементу внутри окна, осуществляется сверху вниз слева направо. Диалоговые окна В диалоговых окнах отсутствуют меню или инструментальные панели. Диалоговые окна открываются не в центре экрана, а в центре текущего действия пользователя. Меню Пункты главного меню Пункты меню имеют адекватные названия. Первая буква в названии пунктов заглавная. Все пункты первого уровня активизируют выпадающее меню. Каждому пункту меню назначены общепринятые горячие клавиши (выделены подчеркиванием). Раскрывающиеся меню и элементы основного меню второго уровня Все элементы начинаются с заглавной буквы. Если в меню используются пиктограммы, они расположены слева от названия пункта меню. Все списки содержат более одного элемента. Высота меню не превышает размер экрана (меню не нужно прокручивать). Пункты меню адекватно сгруппированы. Осмысленно использованы разделители в меню. Пункты меню расположены в порядке связанности выполняемых функций, частоте использования, важности. Используются не более двух подуровней меню. Каждый пункт меню имеет соответствующую горячую клавишу. Название пункта меню соответствует названию вызываемого окна. Пункты меню, открывающие диалоговые окна, обозначены в конце многоточием (…). Недоступные пункты меню обозначены серым цветом шрифта. Всплывающие меню Каждому пункту всплывающего меню соответствует аналогичный пункт в основном меню. Инструментальные панели Каждому элементу инструментальной панели соответствует всплывающая подсказка. Элементы упорядочены и сгруппированы в соответствии с задачами пользователей. Для стандартных действий используются общепринятые графические элементы. Управляющие элементы Переключатели (Check boxes) В одном окне используется не более 10 переключателей. Переключатели сгруппированы и каждой группе присвоено название. Внутри группы переключатели расположены строго вертикально. Переключатели не применяются для частого, оперативного использования. В названиях используется только позитивная, утвердительная форма. Командные кнопки Кнопки имеют краткие и ясные названия. В каждом диалоге используется не более 6 кнопок. Кнопки, выполняющие в разных диалогах идентичные функции, имеют одинаковые названия. Типовые кнопки имеют общепринятые названия и общепринятые горячие клавиши. Кнопки, вызывающие продолжение диалога в вложенных формах, обозначены многоточием (…). Недоступные кнопки имеют соответствующие атрибуты (серый цвет шрифта и т. п.). Опасные для пользователя кнопки не являются кнопками по умолчанию Редактируемые поля со списком (Сombo Box) Имеют функцию авто-выбора. Раскрывающиеся списки Высота выводимого на экран списка ограничена 3-8 элементами. Если список содержит более 50 элементов, используется фильтр или режим поиска. Если все элементы не умещаются в одном фрагменте списка, автоматически появляется полоса прокрутки. Группы элементов Каждая группа имеет осмысленное название, помимо рамки отделена от других групп и элементов свободным пространством. Подписи (Labels) Все элементы имеют подписи. Учтена возможность увеличения (уменьшения) длины подписей при использовании large fonts (small fonts). Подписи выровнены по левому краю поля (если они находятся над полем). Подписи расположены по середине высоты поля (если название находится с боку). Если элемент недоступен, подпись отображается серым шрифтом. Списки Если список содержит более 50 элементов, используется фильтр или режим поиска. Высота ограничена 3-8 элементами. Если все элементы не умещаются, автоматически появляется полоса прокрутки. Кнопки выбора (Option Buttons или Radio Buttons) В одной группе используется не более 6 кнопок. В пределах группы кнопки расположены по вертикали. Нет состояния, когда ни одна кнопка не выбрана. Последовательность расположения кнопок в группе учитывает частоту использования. Вкладки (Tabs) Названия вкладок выровнены по центру. Каждой вкладке присвоено осмысленное название. Количество рядов закладок не превышает двух. Все связанные между собой данные находятся внутри одной закладки. Кнопки, относящиеся ко всему блоку закладок, расположены за пределами блока закладок. Текстовые поля ввода (Text Box or Edit Field) Для недоступных полей используются серый цвет (название, текст и фон поля). Высота всех текстовых полей в окне одинакова. Содержимое полей выровнено по левому краю, за исключением полей с числовыми значением (напр., для вывода денежных сумм). Длина поля не меньше длины вводимых в него данных. Если в поле вводится численное значение границы диапазона выводятся во всплывающей подсказке. Порядок табуляции фокуса ввода При открытии окна фокус попадает на элемент внутри окна. Схема табуляции соответствует очередности заполнения полей (слева направо, сверху вниз). Командные кнопки включены в табуляцию. Невидимые и недоступные элементы исключены из схемы табуляции. Пиктограммы Направление теней во всех пиктограммах одинаково: слева сверху. Взаимодействие с пользователем Система, завершив какую-либо длительную операцию, пищит через встроенный динамик компьютера. Цифры, предназначенные для сравнения либо для копирования в буфер обмена, выводятся непропорциональным шрифтом.

Литература

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

http://www. *****/ui www. ***** Головач «Дизайн пользовательского интерфейса» http://www. *****/ Юзабилити в России http://www. *****/ Статьи Якоба Нильсена: http://www. /personas/nielsen. asp Ководство. Артемий Лебедев. http://www. *****/kovodstvo2/sections/

Нормативные документы

ISO 9241 - Эргономические требования к офисной работы с визуальными терминалами (VDTs):  Часть 11 - Руководство по юзабилити Оригинал (Word, 98K, на английском)  Перевод (Word, 281K)

ISO 9126 - Качество программного продукта   Часть 1 (PDF 73K)- Характеристики и подхарактеристики качества   Часть 1.2 (PDF 102K)- Модель качества   Часть 4 (PDF 604K)- Показатели Качества в использовании

CIF - Формат описания юзабилити характеристик продукта и результатов юзабилити тестов Version 1.1 (html), October 28, 1999  Version 2.0 (PDF, 82K)

[1] Карточная сортировка — классификационный метод, при котором пользователи сортируют различные элементы разрабатываемого ПП по нескольким категориям. Для проведения карточной сортировки создается список параметров, которые предполагается подвергнуть классификации, после чего каждый из указанных параметров выписывается на отдельной карточке. Карточки предъявляются пользователям, которых инструктируют сгруппировать наиболее логичным, по их мнению, образом. Полученную в результате карточной сортировки информацию используют для организации пользовательского интерфейса.