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

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

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

Выводы

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

6.5. Программа имеет многодокументный интерфейс

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

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

Выводы

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

6.6. Отсутствует единый стиль

Целостность - одно из важных свойств интерфейса. Целостность облегчает обучение новых пользователей и повышает производительность опытных.

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

Явный пример отсутствия целостности (рис. 6.6-1)

Рис. 6.6-1.

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

Рис. 6.6-2.

Выводы

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

6.7. Программа перегружена окнами сообщений

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

В программе Зарплата 2000 встречается пример неудачного использования диалоговых окон (Рис. 6.7-1). Для расчета зарплаты запись о работнике нужно добавлять в расчетную ведомость. Если же запись об этом работнике уже есть, программа выдает 2 (!) сообщение подряд. Мало того что сообщение здесь излишне - программу можно реализовать так, что ситуация с внесением работника повторно может никогда не произойти, так еще оно разбито на два. А если у вас 100 сотрудников и пользователь нажмет кнопку Добавить всех (которая, кстати, присутствует в этой программе)? В результате ему придется 200 раз нажимать на кнопку Ok! Будете ли он делать это? Скорее всего просто закроет эту программу.

Рис. 6.7-1.

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

Еще одно бесполезное сообщение (рис. 6.7-2). Вместо того чтобы предложить пользователю варианты решения проблемы или самой догадаться о способе решения, система ограничивается бесполезным, а зачастую просто раздражающим сообщением.

Рис. 6.7-2.

Выводы

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

6.8. Интерфейс отражает внутреннюю структуру реализации и мышление программистов

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

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

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

Рис. 6.8-1.

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

Рис. 6.8-2.

Выводы

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

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

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

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

Меню и панель инструментов переводчика PROMT (6.9-1). Упуская вопросы количества и понятности пиктограмм, следует отметить, что кнопка основной функции программы - перевода - никаким образом не доминирует над всем этим многообразием элементов управления.

Рис. 6.9-1.

Меню и панель инструментов программы распознавания текста FineReader (рис. 6.9-2). Не говоря уже о том, что количество пиктограмм на порядок меньше, а понятность их на порядок выше, триада основных функций программы - отсканировать, распознать, проверить - сразу бросается в глаза. Кнопки расположены именно там где пользователь и ожидает их найти. А расположение и обозначение кнопок в виде неделимой последовательности действий, сокращает время обучения практически до 0. Отличный интерфейс.

Рис. 6.9-2.

Выводы

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

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

6.10. Пиктограммы используются некорректно

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

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

Пример избыточной детализации пиктограмм (рис. 6.10-1). Например, зачем нужен зеленый значок на папке с документами? Или к чему рисовать содержимое корзины, когда метафора самой корзины и так легко узнаваема?

Рис. 6.10-1.

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

Рис. 6.10-2.

Для запуска проверки на вирусы в Dr. WEB неудачно использована метафора светофора (рис. 6.10-3). Красная она потому, что в данный момент пользователь не выбрал ни один элемент для сканирования. Но как пользователь догадается, что нужно сделать, чтобы она стала зеленой? Список доступных дисков для сканирования не подает никакого сигнала о том, что эти диски можно выбрать. А красный цвет на кнопке "отпугивает" пользователя от ее нажатия. Некорректное использование метафоры заключается в том, что здесь индикатор совмещен с элементом управления (кнопкой). Тогда как в реальной жизни светофор сам меняет свое состояние.

Рис. 6.10-3.

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

Рис. 6.10-4.

Выводы

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

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

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

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

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

Окна При проектировании было учтено, при каком разрешении, а так же размере монитора и шрифтов будут работать пользователи. Заголовки Заголовки короткие и адекватные содержимому окна. Заголовки соответствуют названиям элементов, при помощи которых окна были вызваны. Если окно вызывается элементом, не имеющим явного названия, в заголовке окна отражается название экранной формы. Дизайн окна Тип окна (модальное, немодальное, возможность минимизации/максимизации) был выбран осознанно, в соответствии с задачами пользователей. Управляющие и информационные элементы расположены достаточно далеко друг от друга (не менее 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) Для недоступных полей используются серый цвет (название, текст и фон поля). Высота всех текстовых полей в окне одинакова. Содержимое полей выровнено по левому краю, за исключением полей с числовыми значением (напр., для вывода денежных сумм). Длина поля не меньше длины вводимых в него данных. Если в поле вводится численное значение границы диапазона выводятся во всплывающей подсказке. Порядок табуляции фокуса ввода При открытии окна фокус попадает на элемент внутри окна. Схема табуляции соответствует очередности заполнения полей (слева направо, сверху вниз). Командные кнопки включены в табуляцию. Невидимые и недоступные элементы исключены из схемы табуляции. Пиктограммы Направление теней во всех пиктограммах одинаково: слева сверху. Взаимодействие с пользователем Система, завершив какую-либо длительную операцию, пищит через встроенный динамик компьютера. Цифры, предназначенные для сравнения либо для копирования в буфер обмена, выводятся непропорциональным шрифтом.

Литература

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

2. http://www. *****/ui

www. *****

3. Головач «Дизайн пользовательского интерфейса» http://www. *****/

6.Юзабилити в России http://www. *****/

Статьи Якоба Нильсена: http://www. /personas/nielsen. asp

Ководство. Артемий Лебедев. http://www. *****/kovodstvo2/sections/

Alan Cooper «About Face : The Essentials of User Interface Design»
Перевод некоторых статей Купера можно найти на сайте Андрея Седельникова

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

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)

 [Krol1]по этому пункту нет детализации.

 [Krol2]линк

 [Krol3]нет детализации