Уменьшение числа манипуляций

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

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

После этого:

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

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

наверх     к оглавлению

Уменьшение необходимости ввода данных

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

1. Автоматически заполняйте поля новой записи значениями предыдущей.

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

3. Исследуйте другие способы получения информации.

наверх     к оглавлению

Память программы

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

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

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

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

У Алана Купера идея того, что программа может предсказать действия пользователя, обозначается термином "связность задач" (task coherence). Когда человек работает с программой, существует 80-процентная вероятность, что в следующий раз он сделает то же самое, что и в предыдущий. Таким образом, можно со значительной долей уверенности предсказать поведение пользователя, просто запомнив его последнее действие. Это позволит значительно уменьшить число вопросов, которые программа задает пользователю.

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

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

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

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

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

Связность задач может предсказать, что именно будет делать пользователь в будущем со значительной, но не абсолютной вероятностью. Если программа может надежно предсказать действия пользователя в 80% случаев, это значит, что в 20% случаев она будет неправа, потому что в каждом конкретном случае она не знает, в 20 она или в 80 процентах. Может показаться, что это как раз тот случай, когда нужно спросить пользователя, но это не так. Вместо предоставления выбора, программа должна продолжать делать то, что она считает наиболее подходящим, вместе с тем давая пользователю возможность изменить или отменить это. Если возможность отмены достаточно легка и понятна, пользователь не будет беспокоится о ней. В крайнем случае, ему придется отменять решение программы только в 2-х случаях из 10, вместо того, чтобы иметь дело с излишним диалоговым окном 8 раз из 10.

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

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

Длительность реакции системы << к предыдущей главе     к следующей главе >>

Часто пользователи надолго прерывают свою работу. Помимо потери фокуса внимания, о котором уже сказано, это плохо тем, что лишенная руководства система начинает простаивать. Разумеется, мы ничего не можем сделать с этой ситуацией: странно было бы, если бы, как только пользователь отходил в туалет, система, скажем, начинала бы форматировать жесткий диск. Тем не менее, несомненно и другое: пользователь нередко отвлекается не потому, что появляются внешние раздражители, а потому, что система не реагирует на внешний раздражитель в лице пользователя. Попросту говоря, система делает что-либо длительное. Ни один же человек в здравом уме не будет упорно смотреть в экран, зная, что система будет готова к приему новых команд не ранее, чем через пять минут. Соответственно, человек отвлекается. Проиллюстрировать это очень удобно на процессе печати. Печать документа в сто страниц даже на быстрых принтерах занимает существенное время, соответственно, большинство людей, отправив такой документ в печать, начинают бездельничать, поскольку, чтобы начать следующее действие в их трудовом процессе, им нужна распечатка, которой ещё нет. Проблема в том, что сразу после того, как человек отвлекается, системе зачастую, во что бы то ни стало, начинает требоваться что-либо от человека. Человек же, уверенный в том, что система работает, уходит в другую комнату. Таким образом, человек и система бездельничают. При этом раздражение человека, вернувшегося с обеденного перерыва и вместо распечатанного документа нашедшего диалоговое окно с вопросом «Вы уверены?», обычно оказывается безмерным. Это делает всегда верным следующее правило: если процесс предположительно будет длительным, система должна убедиться, что она получила всю информацию от пользователя до начала этого процесса. Есть другое решение этой проблемы: система может считать, что если пользователь не ответил на вопрос, скажем, в течение пяти минут, то его ответ положительный. Таким образом, тот же самый сценарий решается подругому: пользователь отправляет документ на печать и уходит, система спрашивает «Вы уверены?» и ждет пять минут, после истечения этого времени она начинает печать. Этот метод вполне работоспособен, так что им стоит пользовать всегда, когда невозможен первый метод (разумеется, за исключением случаев, когда ответ Да может иметь катастрофические последствия). Есть и другая причина отвлечения пользователя. Пользователь запускает какой-либо процесс. Система показывает ему индикатор степени выполнения. Процент выполнения за минуту едва доходит до четверти размера индикатора. Пользователь анализирует эти данные и резонно решает, что у него есть три минуты, чтобы размяться. Однако, как только он отходит от компьютера, процент выполнения с нечеловеческой скоростью начинает расти и за секунду доходит до максимума. Процесс успешно заканчивается, а пользовать еще три минуты бездельничает. Происходят подобные случаи исключительно потому, что индикаторы степени выполнения обычно рассматриваются программистами не как показатели процента выполнения задачи, но как индикаторы того, что система вообще работает. Для них это очень удобно: поскольку единый с точки зрения пользователя процесс часто состоит из многих принципиально разных системных процессов, выполняющихся с разной скоростью, можно не утруждаться, стараясь так сбалансировать рост индикатора, чтобы он всё время происходил с одинаковой скоростью. Иногда это «неутруждение» принимает довольно комичные формы. Так, индикатор выполнения может сначала расти, потом снижаться, потом опять расти. Проблема в том, что пользователи рассматривают такие индикаторы именно как способ узнать, когда процесс завершится. Так что врать пользователю тут нехорошо. наверх     к оглавлению Фоновый режим выполнения задач Выполняя все асинхронные операции в фоновом режиме, можно отделить задачи пользователя от задач компьютера, позволяя пользователю работать без перерывов. Сетевая печать была асинхронной операцией более 15 лет. Пользователи нажимали кнопку “Печать” и шли заниматься своими делами, пока шел процесс. Над проблемой печати стали работать в первую очередь, потому что Печать отнимает много времени Печать не требует вмешательства пользователя Общее время выполнения задачи предсказать нельзя Следующее задача пользователя обычно не связана с результатами печати Если принтер подключен к высокоскоростной сети и в очереди печати нет заданий, все происходит довольно быстро. Однако, если кто-то только что начал печатать 300-страничный документ, то компьютер может оказаться “замороженным“ на длительный период времени. Та же самая ситуация сложилась сейчас с Интернетом. Загрузка страниц занимает длительное время, не требуя вмешательства пользователя в этот процесс, и предугадать, будет ли она длиться 5 секунд или минуту, невозможно. Всякая операция, которая подходит под вышеописанные критерии и может быть выделена в отдельную задачу, должна быть выделена. Если нужно передать длинную форму после того, как пользователь нажмет Submit, это нужно сделать в фоновом режиме, пока пользователь переходит к следующей форме.

Человеческие ошибки << к предыдущей главе     к следующей главе >>

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

Методы предотвращения ошибок << к предыдущей главе     к следующей главе >>

Необходимо стремиться минимизировать количество ошибок, поскольку только это позволяет сберечь время (т.е. повысить производительность) и сделать пользователей более счастливыми за счет отсутствия дискомфорта. Суммируя, при борьбе с ошибками нужно направлять усилия на: плавное обучение пользователей в процессе работы; снижение требований к бдительности; повышение разборчивости и заметности индикаторов. Дополнительно к этим трём направлениям, есть и четвертое: снижение чувствительности системы к ошибкам. Для этого есть три основных способа, а именно: блокировка потенциально опасных действий пользователя до получения подтверждения правильности действия; проверка системой всех действий пользователя перед их принятием; самостоятельный выбор системой необходимых команд или параметров, при которых от пользователя требуется только проверка. к оглавлению Повышение разборчивости и заметности индикаторов В интерактивном процессе используются 2 типа визуальных элементов, а именно кнопки и индикаторы. Существенной отличий между ними нет, нужно только передать разницу между ними (случаев, когда кнопка является также индикатором, следует, по возможности, избегать). Существуют два основных критерия оценки эффективности интерактивного визуального элемента, это: качество/скорость восприятия элемента; физическая реализация элемента. Качество/скорость восприятия элемента При прочих равных, элемент, назначение которого трудно воспринять, не может квалифицироваться как удовлетворяющий требованиям интерактивности. Проблемы восприятия проявляются тремя способами: либо восприятие назначения элемента занимает избыточное время (более половины секунды), либо значение не воспринимается вообще, либо, что хуже всего, значение воспринимается неправильно. Применительно к Web, можно утверждать, что элемент, восприятие которого замедлено, не будет воспринят вообще, за исключением тех случаев, когда у пользователя есть действительно сильная мотивация (пользователи склонны пропускать все, что с первого взгляда не кажется им интересным или нужным). Причинами ухудшения восприятия элемента являются: Ошибочно выбранный визуальный сюжет элемента. Некоторые понятия могут быть выражены простыми сюжетами (характерный пример — изображение принтера = печать), некоторые же выражаются сюжетами сложными либо многозначными (характерный пример — лупа = изменение масштаба либо поиск). В большинстве случаев эта проблема имеет наименьший приоритет, так как рисование сложных сюжетов вообще не практикуется. Некоторые понятия имеют однозначные визуальные репрезентации только для какой-либо одной аудитории, так что если эта аудитория является целевой, необходимо проверять качество восприятия символа на представителях именно этой аудитории (понятность или непонятность сюжета для всех остальных в таких случаях не может служить индикатором эффективности). Нестандартно выбранный сюжет элемента или реализация сюжета. Пиктограмма дома в Web исторически обозначает переход на титульную страницу сайта. Благодаря этому пользователю не нужно проявлять излишнюю мыслительную активность при определении значении такого элемента (вообще говоря, человеческий мозг наиболее успешно решает задачи, метод решения которых основан на проведении аналогии). Таким образом, чем стандартнее сюжет, тем выше скорость его восприятия. Важна также стандартность реализации выбранного сюжета, например, пиктограмма перехода на титульную страницу, выполненную как изображение избушки на курьих ножках является скорее нестандартной и будет вызывать замешательство, по крайней мере на первых порах. В таких условиях наилучшим методом выбора сюжета является поиск репрезентации, привычной целевой аудитории. Источниками стандартных сюжетов/реализаций являются (отсортированы по степени знакомства с ними пользователей): операционная система, системы конкурентов, среда. Таким образом, сюжет, взятый из операционной системы всегда оптимален (поскольку наиболее знаком). Избыточная детализация сюжета. Объекты реального мира перегружены мелкими деталями. Перенос этих деталей в сюжет символа неоправдан — в реальном мире эти детали нужны (придают объекту уникальность), а на пиктограмме лишь отвлекают внимание и тем самым замедляют распознавание. Более того, скорость восприятия чистых абстракций чаще всего выше скорости восприятия даже максимально упрощенных символов, т.е. символ человеческого лица, нарисованный по принципу "круг, две точки и две черточки" воспринимается быстрее и легче, нежели тот же символ, нарисованный, например, в стилистике комиксов. Физическая реализация элемента Любой элемент, предназначенный для совершения каких либо действий над ним (кнопка, переключатель и т.п.), согласно закону Фитса должен быть достаточно большим физически. Между кнопками необходимо выдерживать пустое пространство, чтобы избежать случайного нажатия посторонней кнопки. По той же причине лучше сигнализировать о попадании курсора в область элемента видом этого элемента (с другой стороны, если при этом меняется курсор, как он меняется, например, при подведении к гиперссылке, дополнительная индикация не обязательна). Выпуклость является единственным способом показа элементом своей "кнопочности", т.е. того, что элемент можно нажать. Соответственно, в однократно используемых системах кнопки делать выпуклыми необходимо, в часто же используемых — желательно. Понятно, что все сюжеты/реализации визуальных элементов в системе должны быть выдержаны стилистически. Помимо этого необходимо визуально разделять кнопки, индикаторы и просто надписи. В данном примере элементы никак не разграничены по функциям: кнопки Site Map и Help выполнены не как остальные кнопки, но как надписи. В результате многие пользователи либо будут безуспешно нажимать псевдокнопку Quotes, либо никогда не нажмут кнопки Site Map и Help. наверх     к оглавлению Блокировка потенциально опасных действий до получения подтверждения Блокируйте системные файлы. Команда удаления файла в любой операционной системе снабжена требованием подтвердить удаление. Этот метод приносит пользу только начинающим пользователям, которые проверяют каждый свой шаг. Для опытных пользователей это диалоговое окно с требованием подтверждения не работает. Для них это что-то вроде ритуала: «после нажатия на клавишу Delete выскочит окошко, в котором нужно нажать ОК». Естественно, что даже в случае неверно выбранного файла это диалоговое окно не сможет предотвратить его удаления. К тому же оно без пользы отвлекает пользователя и тратит его время. Новичков же окно лишний раз пугает, уменьшая субъективное удовлетворения от системы. Правильнее блокировать файлы, изменение или удаление которых может привести к краху ОС или программы, к которой они относятся. В данном случае термин блокировка не предусматривает появление диалогового окна. В данном случае удаление должно быть не возможно в принципе. Все остальные файлы следует разрешать удалять без предупреждения (без диалогового окна), при этом предусматривая удобный способ восстановления (корзина в ее нынешнем виде – не самый удобный способ, но это уже другой вопрос). Не делайте опасные для пользователя кнопки кнопками по умолчанию. Фокуса ввода необходимо снимать с терминационных кнопок, чтобы пользователь не мог, не разобравшись, нажать на Enter и тем самым начать потенциально опасное действие. Действительно, если пользователям приходится прилагать какие-либо усилия, чтобы запустить действие, есть надежда, что во время совершения этих усилий он заметит вкравшуюся ошибку. Обычно проще всего в опасных случаях не делать главную кнопку кнопкой по умолчанию. Важно только не делать кнопкой по умолчанию и кнопку Отмена (как часто случается). Если это сделать, пользователи будут ошибочно закрывать окно, т.е. одна ошибка заменит другую. наверх     к оглавлению Проверка действий пользователя перед их принятием Существует два универсальных и работающих способа проверки команд. Во-первых, это меню. В случаях, когда пользователь выбирает команду из списка, система может без труда делать так, чтобы в этот список попадали только корректные команды. Во-вторых, если действие запускается непосредственным манипулированием объектами, можно индицировать возможные действия изменением поведения этих объектов. Например, если бы форматирование диска запускалось не нажатием кнопки, а перенесением пиктограммы диска в область форматирования, можно было бы показывать пользователю, как с выбранного диска исчезают все файлы и папки. При этом не только снизилась бы вероятность ошибочного форматирования диска, поскольку перенести объект в другую область труднее, чем просто нажать на кнопку, но при этом исчезла бы необходимость предупреждать пользователя о грядущей потере данных с помощью сообщения. Проверкой всех действий пользователя перед их принятием можно также успешно защищать вводимые пользователем данные, в особенности данные численные. Дело в том, что большинство численных данных имеют некий диапазон возможных значений, так что даже в ситуациях, когда невозможно проверить корректность данных, можно, по крайней мере, убедиться, что они попадают в нужный диапазон. Пример крутилок. Как не крути, а больше 360 градусов не накрутишь В большинстве ОС есть специальный элемент управления, именуемый крутилкой (spinner). Фактически это обычное поле ввода, снабженное двумя кнопками для модификации его содержимого (в сторону уменьшения и увеличения). Интересен он тем, что пользователь может не пользоваться клавиатурой для ввода нужного значения, взамен клавиатуры установив нужное значение мышью. Этот элемент имеет то существенное достоинство, что при использовании мыши значение в этом элементе всегда находится в нужном диапазоне и обладает нужным форматом. Кстати, если говорить о границах диапазона, то их всегда надо показывать во всплывающей подсказке. Но что делать, если пользователь ввёл некорректное число с клавиатуры? Ответ прост. Для этого надо индицировать возможную ошибку изменением цвета шрифта или фона на красный. Классический пример использования ползунка. В тех же случаях, когда количество возможных значений невелико, лучше использовать другой элемент управления – ползунок. Мало того, что он позволяет устанавливать только определенные значения (с этим справился бы и выпадающий список или комплект переключателей), но он позволяет пользователю видеть взаимосвязь возможных значений и при этом использование этого элемента понятно даже новичку. наверх     к оглавлению Самостоятельный выбор параметров Чем меньше действий требуется совершить пользователю, тем меньше вероятность ошибки (при этом пользователь, которого избавили от рутинной работы, уже радуется). Вопрос состоит в том, как системе узнать, что именно нужно пользователю. Проиллюстрировать сферу применения данного метода удобно на примере печати в MS Word. Существует две команды меню Файл, а именно Печать и Параметры печати. Обе команды вызывают одноименные диалоговые окна. Проблема заключается в том, что по закону Хика обилие элементов управления замедляет восприятие этих окон и увеличивает вероятность ошибки. Для такой часто используемой функции как печать, ее диалоговое окно содержит слишком много параметров Чем меньше элементов управления, тем меньше вероятность ошибки. Система может уменьшить число элементов, если она знает сама, какими именно параметрами она должна руководствоваться. Главной причиной появления этих диалоговых окон является печать нескольких копий. Причем есть простая зависимость – «количество копий обратно пропорционально частоте печати такого количества», т.е. сто копий печатают примерно в сто раз реже, чем печатают одну копию. Стандартное диалоговое окно печати содержит также область выбора принтера из числа установленных в системе. Большинство же пользователей имеет только один принтер. Так зачем заставлять это большинство каждый раз вдумчиво воспринимать совершенно не нужные им элементы интерфейса? С другой стороны на панели инструментов есть кнопка, нажатие на которую вызывает печать одного экземпляра с текущими настройками. Это, впрочем, тоже нехорошо. Во-первых, кнопка называется Печать, каковое название конфликтует с такой же командой в меню (называть кнопку Печать одного экземпляра с текущими настройками тоже не выход). Сама же по себе идея иметь в программе две кнопки с одинаковыми названиями и разным действием порочна. Во-вторых, нормальная программа должна иметь меню, содержащее полную функциональность, и панель инструментов, представляющую собой выжимку из меню. А здесь получается, что в панели инструментов есть команда, которую нельзя вызвать никаким иным способом. Каким образом можно улучшить вызов печати? В меню есть те же две команды – Печать и Параметры печати. Выбор первой команды вызывает немедленную печать документа с текущими настройками. Выбор второй вызывает диалог со всеми доступными параметрами печати, т.е. в системе с одним принтером никогда не появится ненужная группа элементов. Если же пользователь начинает проявлять буйную активность и печатать несколько копий разом, включается другой механизм. В первый раз, когда пользователь меняет число копий в окне настроек печати, программа запоминает его действие и при следующем выборе команды Печать выводит диалоговое окно со всего двумя элементами управления – полем ввода, в котором уже стоит число копий (которое было запомнено в предыдущий раз) и кнопкой ОК. Поскольку программа не может быть уверена в правильности числа копий, цифру лучше всего выводить нестандартным цветом, чтобы привлечь внимание пользователя. И так до тех пор, пока пользователь два раза подряд не введет единицу в поле ввода (что переводит его в разряд представителей большинства) или не введет новое число копий (каковое и будет запомнено). Причём такая метода применяется абсолютно ко всем возможным настройкам, а не только к числу копий. Таким образом, большинство пользователей становится счастливо, а количество ошибок сокращается, что хорошо. Суммируя, можно сказать, что система сама может узнать большинство из тех сведений, которые она запрашивает у пользователя. Главными источниками этих сведений являются: здравый смысл разработчика системы; предыдущие установленные параметры; наиболее часто устанавливаемые параметры. Единственная проблема этого метода заключается в том, что для его использования к проектированию системы нужно подходить значительно более творчески и тщательно, нежели обычно практикуется.

Обучение работе с системой << к предыдущей главе     к следующей главе >>

Начиная с определенного объема функциональности системы, количество пользователей, знающих всю функциональность, неуклонно снижается. Чем объемней система, тем больше шансов на то, что среднестатистический пользователь знает о ней очень немного (относительно общего объема функциональности). Например средний пользователь MS Word, скорее всего, умеет пользоваться не более чем пятью процентами его возможностей. Плохо это по многим причинам: во-первых, пользователи работают с системой не слишком эффективно, поскольку вместо методов адекватных они используют методы знакомые. Во-вторых, достаточно часто случается, что пользователи, не зная, что имеющийся продукт делает то, что им нужно, ищут (и находят) продукт конкурента. В-третьих, при таком положении вещей затруднительно продавать новые версии продукта: если пользователь не умеет пользоваться и тем, что есть, убеждать его совершить покупку ради новой функциональности придется на довольно шатком фундаменте. Почему пользователи учатся Люди делают что-либо только при наличии стимула, при этом тяжесть действия пропорциональна силе стимула. Обучение есть действие: если обучаться легко, пользователям будет достаточно слабого стимула, если тяжело, стимул придется увеличивать. Пользователь обучится пользоваться программой или сайтом только в том случае, если он будет уверен, что это сделает его жизнь легче и приятней. Пользователь будет учиться какой-либо функции, только если он знает о её существовании, поскольку, не обладая этим знанием, он не способен узнать, что за её использование жизнь даст ему награду. Т.е. одного стимула недостаточно, если пользователь не знает, за что этот стимул дается. Таким образом, чтобы пользователь начал учиться, ему нужно рассказать о функциональности системы, причем не только безучастно сообщать о наличии той или иной функции, но и расхваливать преимущества, которые пользователь получит, этой функции обучившись. А дальше пользователь сам будет учиться, если, конечно, стимул достаточен. Без этого любая система не вызовет никакого желания учиться, даже если это обучение принесло бы пользователю множество пользы. Простота же обучения системе есть всего лишь метод уменьшить «необходимый и достаточный» стимул; при достаточно сильном стимуле люди охотно учатся и без всякой простоты (другой разговор, что получение достаточно весомого стимула часто более сложно для разработчика, чем облегчение обучения). Разрабатывая систему и прорабатывая вопросы простоты обучения пользования этой системой, рассчитывайте на средних пользователей, а не новичков или на профессионалов: средних пользователей, как-никак, абсолютное большинство. наверх     к оглавлению Средства обучения Обычно считается, что в случае ПО есть два способа повысить эффективность обучения, а именно бумажная документация и «оперативная справка». Это категорически неправильно. Во-первых, способов много, и самые главные способы в эту систему не попали. Во-вторых, одно из понятий, входящих в эту таксономию, просто некорректно: оперативность справки зачастую бывает отрицательной (т.е. поиск в ней занимает больше времени, чем поиск того же в бумажной документации). Поэтому разумно привести более совершенный список средств обучения: Общая «понятность» системы Обучающие материалы

Обучающие материалы << к предыдущей главе     к следующей главе >>

Типы обучающих материалов Среды передачи обучающих материалов Спиральность к оглавлению Типы обучающих материалов Базовая справка объясняет пользователю сущность и назначение системы. Обычно должна сработать только один раз, объясняя пользователю, зачем система нужна. Пример базовой справки. Показывается при первом запуске программы. Далее показ можно отключить В последнее время появилась возможность интегрировать в справочную систему видео при помощи либо Macromedia Flash, либо Shockwave. Нет сомнений, что реклама, поданная не просто в виде текста с картинками, но в виде анимации, способна как повысить желание её просмотреть, так и повысить субъективное удовлетворение пользователей от системы. Фактически, всем содержимым этой анимации является показ сменяющих друг друга скриншотов (разработкой которых, должен заниматься графический дизайнер). Также, необходимо создать более-менее хороший сценарий (его лучше отдать профессиональному писателю). Дизайнер интерфейса в этом случае должен только составить список функций, которые нужно рекламировать. Обзорная справка рекламирует пользователю функции системы. Нужна и ПО и сайтам, и нужна тем более, чем более функциональна система. Поскольку у зрелых систем функциональность обычно очень велика, невозможно добиться того, чтобы пользователи запоминали её за один раз. В этом случае оптимальным вариантом является слежение за действиями пользователя и показ коротких реклам типа «А вы знаете, что…» в случае заранее определенных действий пользователей. «Помощник» поиска в Windows XP Справка предметной области отвечает на вопрос «Как сделать хорошо?». Поскольку от пользователей зачастую нельзя рассчитывать знания предметной области, необходимо снабжать их этим знанием на ходу. При этом действуют два правила: во-первых, пользователи ненавидят признавать, что они чего-либо не знают, соответственно, подавать это знание надо максимально «небрежным тоном»; во-вторых, наличие такого знания всегда повышает субъективную оценку справочной системы в целом, т.е. приводит к тому, что пользователи чаще обращаются к справочной системе и от этого эффективней учатся. Это окошко появляется при каждой загрузке программы, постепенно и ненавязчиво информируя пользователя о функциях программы Справка предметной области также реализуется обычно в бумажной документации. Однако, как минимум, часть её можно подавать пользователям в интерфейсе вместе с выдержками из обзорной справки. После того как была исправлена ошибка, у «помощника» зажегся индикатор, указывающий на то, что у него есть совет для пользователя. При щелчке по индикатору появилось следующее сообщение . Отличный пример ненавязчивой и полезной справки. Справка предметной области является самой важной подсистемой справки. Грамотный и опытный пользователь сможет воспользоваться системой, лишенной всех справочных систем, более того, такой пользователь сможет даже научиться пользоваться такой системой. Но без знания предметной области он никогда не сможет пользоваться системой правильно и эффективно. Процедурная справка отвечает на вопрос «Как это сделать?». В идеале она должна быть максимально более доступна, поскольку если пользователь не найдет нужную информацию быстро, он перестанет искать и так и не научится пользоваться функцией (возможно, никогда). Пример процедурной справки с «помощником» из MS Office Лучшим местом для процедурной справки является выделенная справочная система. Необходимо стараться привязывать темы справки к интерфейсу: когда пользователям непонятно, как выполнить нужное им действие, им не придется подолгу искать в справочной системе нужную тему. Контекстная справка отвечает на вопросы «Что это делает?» и «Зачем это нужно?». Как правило, наибольший интерес в ПО представляет первый вопрос, поскольку уже по названию элемента должно быть понятно его назначение (в противном случае его лучше вообще выкинуть), а в интернете – второй (из-за невозможности предугадать, что именно будет на следующей странице). Поскольку пользователи обращаются к контекстной справке во время выполнения какого-либо действия, она ни в коем случае не должна прерывать это действие (чтобы не ломать контекст действий), её облик должен быть максимально сдержанным, а объем информации в ней – минимальным. Для контекстной справки заслуженно используют всплывающие подсказки (ToolTip) и, в последнее время, пузыри. Пример всплывающей подсказки Справка состояния отвечает на вопрос «Что происходит в настоящий момент?». Не может быть вынесена из интерфейса. Пример справки состояния. Информирует пользователя о действиях системы наверх     к оглавлению Среды передачи обучающих материалов Бумажная книга.На одном листе может быть сконденсировано очень много материала, легко позволяет читателю получить большой объем материала за один сеанс, наилучшим образом работает при последовательном чтении. Сравнительно плохой поиск нужных сведений. Объем практически всегда лимитирован. Справочная карта. Отдельная краткая бумажная документация, демонстрирующая основные способы взаимодействия с системой. Будучи реализована на едином листе бумаги, позволяет пользователю повесить её перед собой. Хороша как средство обучения продвинутым способам взаимодействия с системой и устройству навигации в системе. Структурированная электронная документация.Плохо предназначена для чтения больших объемов материала, зато обеспечивает легкий поиск и не имеет лимита объема. Занимает большой объем пространства экрана. Плохо подходит для показа крупных изображений, зато в неё могут быть легко интегрированы видео и звук. Фрагменты пространства интерфейса, показывающие справочную информацию. Занимают пространство экрана, но пространство ограниченное. Отвлекая внимание, как минимум один раз воспринимаются всеми пользователями. Как правило, неспособны передавать большой объем информации. Всплывающие подсказки. Хорошо справляются с ответом на вопросы «Что это такое» и «Зачем это нужно», при условии, что объем ответов сравнительно невелик. Поскольку вызываются пользователями вручную, в обычном режиме не занимают пространства экрана и не отвлекают внимания пользователей. С другой стороны, очень легко вызывают отвыкание – после первого же случая неудовлетворения пользователя подсказкой, пользователь перестает вызывать и все остальные подсказки. наверх     к оглавлению Спиральность Поскольку пользователи обращаются к справочной системе при возникновении проблем, можно смело сказать, что использование справочной системы всегда воспринимается негативно. Таким образом, следует всемерно сокращать объем справочной системы, чтобы тем самым сократить длительность неудовольствия. К сожалению, сокращение объема не приводит к полному счастью, поскольку при малом объеме справочной системы возрастает риск того, что пользователи не найдут в ней ответы на свои вопросы. Есть, однако, исключительно эффективный метод решения этой проблемы: так называемые спиральные тексты. Идея заключается в следующем. При возникновении вопроса пользователь получает только чрезвычайно сжатый, но ограниченный ответ (1-3 предложения). Если ответ достаточен, пользователь волен вернуться к выполнению текущей задачи, тем самым длительность доступа к справочной системе (и неудовольствие) оказывается минимальной. Если ответ не удовлетворяет пользователя, пользователь может запросить более полный, но и более объемный ответ. Если и этот ответ недостаточен (что случается, разумеется, весьма редко), пользователь может обратиться к ещё более подробному ответу. Таким образом, при использовании этого метода, пользователи получают именно тот объем справочной системы, который им нужен. Спиральность текста считается нормой при разработке документаций. Есть веские основания считать, что она необходима вообще в любой справочной системе. Рекомендуется делать её во всех случаях.

Субъективная удовлетворенность << к предыдущей главе     к следующей главе >>

Субъективная удовлетворенность складывается из многих составляющих. Ниже приведены некоторые из них: Эстетика Субъективное восприятие скорости работы Приемы для уменьшения субъективного восприятия Уменьшение вероятности стрессовых ситуаций Пароли Сообщения об ошибках к оглавлению Эстетика Конструируемый предмет должен быть незаметен в процессе его использования. Странно интересоваться, как выглядит стул, на котором сидишь. Когда человек читает книгу, он чаще всего не замечает её верстку. В то же время предмет должен приятно ощущаться на бессознательном уровне. Таким образом, во что бы то ни стало, необходимо добиваться неощущаемости интерфейса. Для этого: Избегайте развязности в визуальном дизайне. Избегайте ярких цветов. Существует очень немного цветов, обладающих и яркостью, и мягкостью (т.е. не бьющих по глазам). На экране их значительно меньше, поскольку в жизни такие цвета обычно моделируются как собственно цветом, так и текстурой, с чем на экране есть проблемы. Избегайте острых углов. Старайтесь сделать дизайн максимально более легким и воздушным. Старайтесь добиваться контраста не сменой насыщенности элементов, но расположением пустот. Красота понятие относительное. Необходимо стремитесь не столько к красоте интерфейса, сколько к его элегантности. Во-первых, элегантный интерфейс не надоедает. Во-вторых, он редко осознается потребителями, обеспечивая неощущаемость. В-третьих – он приносит эстетическое удовольствие независимо от культурного уровня потребителя. В-четвертых, в производстве он гораздо удобнее красоты, поскольку сравнительно легко ставится на поток. Чтобы добиться элегантности, надо действовать следующим образом: Старайтесь сделать интерфейс максимально насыщенным визуальными закономерностями. Есть универсальное правило – чем больше закономерностей, тем больше гармонии. Даже самые незначительные закономерности всё равно воспринимаются. Под закономерностью понимается любое методически выдерживаемое соответствие свойств у разных объектов, например, высота кнопок может быть равна удвоенному значению полей диалогового окна. Пример закономерностей в диалоговом окне. Старайтесь минимизировать количество констант (тем более, что двух констант обычно хватает на все). Разумеется, единожды примененных закономерностей необходимо придерживаться во всей системе. Всемерно старайтесь использовать модульные сетки, т.е. привязывайте все объекты к линиям (лучше узлам) воображаемой сетки, которую выдерживайте во всем интерфейсе. Старайтесь привязывать все размеры и координаты (как минимум пропорции диалоговых окон) к золотому сечению (0.618 х 0.382). наверх     к оглавлению Субъективное восприятие скорости работы Субъективное ощущение времени зачастую сильно отличается от объективного. Воспринимаемая продолжительность действий напрямую зависит от уровня активности пользователя, так что субъективная длительность последовательности действий всегда ниже такой же по времени паузы. Пользователи часто жалуются, что им “кажется”, что процесс происходит медленнее, чем есть на самом деле. Классический пример произошел в Нью-Йорке в 1930 году, когда пользователи нового офисного здания постоянно жаловались на долгое время ожидания лифтов. Когда пригласили инженеров для консультации, выяснилось, что нет никакой возможности ни ускорить лифты, ни увеличить их число или вместимость. Тогда пригласили дизайнера, который смог решить проблему. Дизайнер понял, что настоящая проблема была не в том, что время ожидания лифтов было слишком большим, а в том, что оно воспринималось таковым. Дизайнер решил проблему восприятия размещением зеркал на стенах площадок для ожидания лифта. Теперь люди были заняты рассматриванием себя и других в множестве отражений. Их мозг был полностью занят, а время летело. В одном из исследований этого феномена пользователей попросили выполнить одно и то же задание с помощью клавиатуры и мыши. Работа с клавиатурой была напряженной и требовала принятия множество мелких решений. Версия для мыши была гораздо легче и принятия решений не требовала. Все пользователи выполнили задание с помощью мыши примерно на 50% быстрее. Но что интересно, все высказались, что они выполнили задание гораздо быстрее с помощью клавиатуры. Таким образом, нужно всегда принимать во внимание субъективные убеждения пользователей о том, насколько быстрым или медленным является процесс. Не принимайте решение на основе только своего собственного мнения. Тестируйте программу на пользователях. Основная стратегия уменьшения субъективного времени восприятия: Пользователи должны быть постоянно заняты Когда в процессе работы возникает неизбежная пауза, например, потому что программа должна обратиться к серверу, убедитесь, что пользователь занят и развлечен. Идеальное занятие – это занятие, имеющее отношение к текущей задаче. Перед тем, как обращаться к серверу, дайте пользователю прочесть что-нибудь, что подготовит его для следующей задачи. Пример сокращения субъективного времени восприятия Во время ожидания конца инсталляции пользователю показывается ряд меняющихся экранов с картинками и текстом. В данном случае выполняются две задачи: дается справка о новых возможностях продукта и сокращается субъективное время восприятия. наверх     к оглавлению Приемы для уменьшения субъективного восприятия Все приводимые указания зависят от использования индикаторов. Следующие типы индикаторов приведены в порядке от наиболее до наименее желаемого: Индикатор оставшегося времени. Поместите его либо в модальный диалог, либо в строку статуса. Индикатор “Система жива”. Когда оставшееся время предугадать невозможно, покажите анимированный объект, который даст пользователям понять, что система не зависла. Индикатор “Слышу и понимаю”. Когда ожидаемая задержка менее 2 секунд, показывать оставшееся время бессмысленно, поэтому просто измените форму курсора на “песочные часы”. Для задержек от 0,1 секунды до 10 секунд: Подтвердите щелчок мыши или нажатие клавиши в течение 0,1 секунды. Измените форму курсора на “песочные часы” или другой анимированный указатель для любой задержки более 0,5 секунды. Покажите, когда пользователь может продолжать. Для задержек от 10 секунд до 1 минуты: Подтвердите щелчок мыши или нажатие клавиши в течение 0,1 секунды. Привлеките внимание пользователя Укажите время ожидания точно или приблизительно. Выведите индикатор Покажите, когда пользователь может продолжать. Для задержек от минуты до целой ночи: Подтвердите щелчок мыши или нажатие клавиши в течение 0,1 секунды. Привлеките внимание пользователя. Индикатор, который трудно заметить, может и не существовать. Сообщите пользователю, насколько долгим будет ожидание. Если не знаете – предположите диапазон значений. Даже довольно широкого диапазона (от 3 до 15 минут) пользователю может быть достаточно для принятия решения – переключиться на другую задачу, или же пойти попить кофе. Выведите индикатор. Четко и ясно сообщите пользователю, когда он может продолжать. Это не значит, что вы должны вывести сообщение шрифтом 96 размера. Это значит, что изменения на экране должны быть значительными, для того чтобы их можно было визуально различить. наверх     к оглавлению Уменьшение вероятности стрессовых ситуаций Нет ничего более неприятного, чем психологическое напряжение, иначе говоря – стресс. Почти всё время пользователь может что-либо испортить и знает это. Он может отформатировать жесткий диск, может стереть или испортить нужный файл. Неудивительно, что пользователь часто боится. А если не боится, то склонен недооценивать свои возможности к разрушению, отчего снижается бдительность. Единственным полноценным решением является возможность отмены пользователем своих предыдущих действий, без ограничения количества уровней отмены и типа отменяемых действий. Пользователь, знающий, что он не может совершить ошибку, испытывает радость и умиротворение. К сожалению, создание таких систем, не будучи исключительно трудным делом с точки зрения технологии требует смены парадигмы мышления программистов. Зачастую более реалистичным решением является давно уже существующая практика прятать опасные для пользователя места интерфейса. Формально, это хороший и правильный способ. Проблема заключается в том, что при этом логично прятать все функции, изменяющие данные, например банальная функция автоматической замены может мгновенно уничтожить текст документа (достаточно заменить одну букву на любую другую и забыть отменить это действие). Другим фактором, существенно влияющим на субъективное удовлетворение пользователей, является чувство контроля над системой. Существует значительная часть пользователей, для которой использование компьютера не является действием привычным. Для таких пользователей ощущение того, что они не способны контролировать работу компьютера, является сильнейшим источником стресса. Для остальных пользователей отсутствие чувства контроля не приносит стресса, но всё равно приводит к неудовольствию. Таким образом, пользователей нужно всемерно снабжать ощущением, что ничего не может произойти, пока этого не захочется самому пользователю. Функции, работающие в автоматическом режиме, но время от времени просыпающиеся и требующие от пользователей реакции, вызывают стресс. В любом случае, стоит всеми силами внушать пользователям мысль, что только явно выраженное действие приводит к ответному действию системы. наверх     к оглавлению Пароли Пароли имеют три принципиальных проблемы: пользователи не любят их вводить пользователи либо забывают пароли, либо пароли не работают, т.е. ничего не защищают, поскольку пользователи используют те пароли, которые они помнят и которые, соответственно, непроблематично подобрать. в интернете часто происходит так, что пользователи, не желая вводить пароль (и регистрироваться, к слову говоря) так никогда не попадают в главную часть сайта. Каким же образом можно решить эти проблемы. Для этого есть несколько путей. Во-первых, от паролей можно отказаться вообще. Этот путь почти всегда предпочтителен, проблема в том, что он вызывает существенное отторжение у сетевых администраторов. В самом деле, зачем требовать от пользователя пароль, если подобрать этот пароль злоумышленник сможет без труда? И обратно: поскольку единственным способом создания действительно трудноподбираемых паролей является генератор случайных чисел, каковые числа (символы, по необходимости) невозможно запомнить, пользователи либо будут записывать их на бумажке (в этом случае пароли еще легче украсть), либо будут забывать, что дорого стоит. Этот метод хорош, когда дело касается защиты информации. Однако гораздо чаще, особенно в интернете, важна не столько защита информации, сколько идентификация пользователя (которая может сопрягаться с защитой, а может и не сопрягаться). В этом случае от паролей отказаться невозможно, просто потому, что не существует другой, столь же эффективной, технологии идентификации. При этом содержимое пароля как таковое не очень важно, важно его отличие от паролей других пользователей (в этом случае само по себе имя пользователя является паролем). Обычно в таких условиях при регистрации применяют стандартную группу элементов «имя, пароль, подтверждение пароля», после чего, уже при нормальной деятельности, пользователь получает возможность ввести пароль только в первый раз. В этом случае появляется следующий недостаток: пользователь, однократно введя пароль, потом его забывает, поскольку из-за отсутствия повторения пароль никогда не попадает в долговременную память. В результате, когда пользователь переходит на другой компьютер или переустанавливает ОС, ему приходится регистрироваться снова, что нехорошо. Во-первых, эта лишняя работа раздражает. Во-вторых, база пользователей при этом разбавляется дубликатами, что всегда плохо сказывается на стоимости этой базы. В-третьих, что иногда самое главное, зарегистрировавшийся во второй раз пользователь лишается возможности получить уже использованное им ранее имя, что огорчительно: например, пользователь, забывший пароль от почтовой службы, лишается как доступа к своему почтовому ящику, так и возможность получить прежний почтовый адрес. Конечно, некоторые пользователи воспользуются тем или иным способом узнать свой прежний пароль, но отнюдь не все. Это значит, что помимо какого-либо механизма напоминания пользователям их потерянных паролей, очень полезно не скрывать от пользователей их пароль, т.е. выводить его в поле ввода не звездочками, а открытым текстом. Это решение хорошо ещё и тем, что количество ошибочно набранных паролей здорово сократится (тяжело набирать на клавиатуре невидимое). Таким образом, эффективнее всего максимально здраво определить степень важности защищаемой информации, после чего выбрать адекватную схему защиты, стараясь, чтобы она была максимально лёгкой для пользователей. Как правило, их субъективное удовлетворение важнее потенциального вреда от потери информации.

Сообщение об ошибках << к предыдущей главе     к следующей главе >>

Как избежать сообщений об ошибках Каким должно быть сообщение об ошибке Пузырь как альтернатива сообщениям об ошибке Сообщения о завершении операции Ни один пользователь не может долго и продуктивно работать с системой, которая его огорчает и обижает. Тем не менее, такие «скандальные» системы являются нормой. Виной тому сообщения об ошибках. Большинство сообщений об ошибках в действительности не являются собственно сообщениями об ошибках. На самом деле они показывают пользователю, что система, которой он пользуется несовершенна, а именно: недостаточно гибка, чтобы приспособиться к его действиям. В действительности множество действий пользователя направлены не на то, чтобы сделать так, а не иначе, а на то, чтобы сделать примерно так, как хочется. Пользователю часто нет дела, можно добиться точного результата или нет. Показывать ему в таких случаях диалог об ошибке глупо, поскольку пользователю не нужно ничего знать. Ему нужен результат. Вот что бывает , если пользователь попытается ввести значение, которое ему нужно, но которое система не умеет обрабатывать. Тут возможно три альтернативных решения. Во-первых, при проектировании системы можно более тщательно подходить к выбору её функциональности. Во-вторых, можно просто игнорировать неправильность значения, округляя его до ближайшего возможного (в данном примере система так и делает, но зачем же при этом выводить сообщение!?). В-третьих, вместо обычного поля ввода можно использовать крутилку (spinner) недостаточно умна, чтобы показать ему его возможные границы действия. Во многих случаях пользователь совершает действия, которые воспринимаются программой как неправильные, не потому, что он дурак, но потому, что система не показала ему границ возможного действия. Все такие сообщения порочны, поскольку их можно было бы избежать, просто блокировав возможность совершения некорректных действий или показав пользователю их некорректность до совершения действия. Типичное сообщение об ошибке, вызванное нежеланием системы показать пользователю границы его действий. К тому же из сообщения не понятно в чем собственно ошибка, а междометьем «или» система расписывается в своей некомпетентности. Все усугубляется тем, что система не предоставляет ни одного варианта решения проблемы (еще бы! она ведь даже не знает точно, в чем она заключается). Даже опытный пользователь, впервые столкнувшись с этой проблемой, потратит на ее расшифровку несколько минут. Между прочим, это Office XP. Пример из того же Office XP, но уже на порядок лучше. Во-первых, сообщение не выглядит как банальное сообщение об ошибке, а выглядит как диалоговое окно. Во-вторых, пользователю тут же предоставляются варианты выхода из затруднительной ситуации (тут даже язык не поворачивается называть эту ситуацию проблемой). Однако есть существенный недостаток, который буквально перечеркивает все достоинства: совершенно непонятна разница между первым и последним пунктом. Ошибка в данном случае может быть фатальной. Хуже всего, что из-за несовершенства интерфейса в случае перезаписи файла не поможет даже корзина. самоуверенна и считает, что пользователь дурак, которым можно и нужно помыкать. Нормой также являются случаи, когда система пытается выставить дело так, как будто пользователь неправ, а система, наоборот, есть воплощение безошибочности и правоты. В действительности не пользователь сделан для системы, но система для пользователя. Таким образом, как-либо ущемлять пользователя неправильно. Пример подобного сообщения. Для кого неверное? И кто, собственно, виноват, система или пользователь? Суммируя, можно сказать, что почти любое сообщение об ошибке есть признак того, что система спроектирована плохо. Всегда можно сделать так, чтобы показывать сообщение было бы не нужно. Более того. Любое сообщение об ошибке говорит пользователю, что он дурак. Таким образом, почти все сообщения об ошибках должны быть удалены. Разумеется, речь идет не о том, чтобы просто выкинуть куски кода из программы, а о том, что системы изначально надо проектировать так, чтобы в них отсутствовала необходимость в таких сообщениях. Невозможно полноценно работать с системой, которая по нескольку раз за день тебя ругает. наверх     к оглавлению Как избежать сообщений об ошибках Делайте ошибки невозможными. Наилучший способ избежать сообщений об ошибках это сделать так, чтобы пользователь не смог их совершить. Вместо требования ввести данные с клавиатуры, предоставьте пользователю список возможных вариантов выбора. Еще один прекрасный способ избежать сообщений об ошибках - это сделать программу достаточно умной для того, чтобы избежать вопросов к пользователю. Многие сообщения об ошибках говорят что-то вроде "Неверные данные. Пользователь должен ввести ХХХХ". Почему же программа не может, зная, что должен ввести пользователь, ввести ХХХХ сама? Вместо запроса у пользователя имени файла на диске, давая возможность выбрать несуществующий файл, программа может запомнить, с какими файлами велась работа последний раз, и предоставить их список. Вот такое диалоговое окно вынуждены наблюдать пользователи, которые захотят перевести файл в PROMT’e. Банальное открытие файла разработчики превратили в увлекательную игру «Отгадай формат». Не понятно, почему программа сама не может определить, какой формат у открываемого файла. Тем более не понятно, зачем при открытии файла указывать «направление перевода», ведь это можно сделать опционально, уже непосредственно в программе. Самое интересное, что у этой истории есть продолжение. Такое сообщение появляется, если пользователь вводит неправильный формат. При чем вне зависимости от ответа пользователя система не пытается выполнить никаких действий. После этого диалогового окна у пользователя уже не остается никаких сомнений, что программа над ним издевается. Позитивная обратная связь - хороший способ вознаградить пользователя за правильное пользование программой. Наилучший способ позитивной обратной связи это звук. К несчастью, долгие годы окна с сообщениями об ошибках сопровождались громким и пронзительным гудком, и звук стал ассоциироваться с ошибкой. В реальной жизни любой объект или система, за исключением компьютерных программ, используют звук для позитивной обратной связи. Закрывая дверь, мы определяем, что она защелкнулась, услышав щелчок, тишина означает, что дверь еще не закрыта. Когда мы поворачиваем ключ зажигания и ничего не слышим, значит у нас проблемы. Когда мы включаем копир, а он молчит, вместо того, чтобы громко гудеть, мы понимаем, значит что-то не так. Программы должны давать нам постоянные небольшие звуковые подсказки, похожие на тихие щелчки кнопок клавиатуры. Программы были бы более дружественными и простыми в использовании, если бы они издавали едва заметные, но легко узнаваемые звуки, когда действия пользователя верны. Программа должны выдавать мягкий звук каждый раз, когда пользователь ввел верное значение. Если программа не понимает введенную информацию, она должны молчать. В этом случае пользователь может сразу скорректировать данные безо всякого смущения. Когда пользователь начинает перетаскивать иконку, программа может коротко щелкнуть, а во время движения объекта производить тихое шипение. Когда объект находится над областями, где его нельзя оставить, звук меняется на что-нибудь более неблагозвучное. Когда наконец пользователь отпустит кнопку мыши, он будет вознагражден тихим "Да!", если действие завершено успешно, и тишиной из динамиков, если действие не имеет смысла. Звуковая обратная связь должна быть очень тихой, не громче чем звук нажатий клавиш на переносном компьютере. Программа должна производить звук каждый раз, когда пользователь работает с программой правильно или каждый раз, когда пользователь вводит информацию, которую программа понимает. Пользователи быстро начнут зависеть от этих звуков, и начнут работать более быстро и эффективно. Проверяйте – не редактируйте. Еще один метод избежать сообщений об ошибках для программы, когда пользователь вводит неправильные данные, состоит в том, чтобы принять, что они неправильные, потому что программа, а не пользователь, плохо информирована. Если, например, пользователь вводит счет-фактуру для несуществующего номера клиента, программа может принять эти данные, и сделать себе специальную заметку, которая показывает, что пользователь должен исправить ее. Затем она будет наблюдать, чтобы удостовериться, что пользователь ввел необходимую информацию до конца отчетного периода. Так в действительности работают большинство людей. Они не вводят "неверных" номеров. Просто люди обычно вводят информацию в такой последовательности, которую программа принять не может. Мы предполагаем, что запись о клиенте должна уже существовать перед выпиской счета-фактуры, но это не догма. Почему программа не может воспринимать счета-фактуры независимо от записей о клиентах, и попросту считать, что недостающая информация будет введена позже? Если человек забывает ввести недостающую информацию до конца месяца, программа может переместить незаконченные документы на неопределенный счет. Программа не должна прерывать работу и останавливаться с сообщением об ошибке. наверх     к оглавлению Каким должно быть сообщение об ошибке Существуют ситуации, в которых сообщение об ошибке не избежать. Типичные примеры подобных ситуаций: файл, находящийся на сетевом сервере более не доступен; попытка записи на диск, доступный только для чтения; недостаток нужных для работы программы компонентов, и т.д. Каким должно быть сообщение об ошибке в этом случае? Идеальное сообщение об ошибке должно отвечать всего на три вопроса: В чем заключается проблема? Как исправить эту проблему сейчас? Как сделать так, чтобы проблема не повторилась? При этом отвечать на эти вопросы нужно возможно более вежливым и понятным пользователям языком. Например, разберем сообщение о невозможности перезаписать заблокированный файл. Итак, исходное сообщение об ошибке гласит: «Не удается сохранить файл «D:\Только для чтения.doc». Файл с этим именем уже существует и доступен только для чтения. Сохраните файл под другим именем или в другой папке». Каким образом его можно улучшить? Сначала надо разобраться, в каких случаях оно появляется: оно может появляться, если пользователь попытался сохранить файл на компакт-диске, или же пытается сохранить файл, незадолго перед этим скопировав этот файл с компакт-диска. Случаи, когда файл заблокирован сознательно, в жизни редки, так что их чаще всего можно не учитывать. Главный враг – компакт-диск. Тут возможно несколько непротиворечащих друг другу решений. Во-первых, просто можно блокировать возможность что-либо записать на диске, запись на который невозможна. Собственно говоря, запись и так блокируется, но сообщением об ошибке. А можно просто не показывать диски, на которые нельзя записывать, в окне записи, что эффективнее, поскольку делает ошибку невозможной. Во-вторых, можно показывать файлы, защищенные от записи, иначе, чем файлы незащищенные. Это будет работать, но тоже неидеально. Что делать пользователю, который всё-таки хочет перезаписать файл? Сейчас в такой ситуации приходится записывать файл под новым именем, потом стирать старый, а новому давать имя старого. Это и потери времени и ошибочно стертые файлы. Таким образом, сообщение об ошибке должно стать не только сообщением – оно должно позволять разблокировать файлы, разблокировать которые возможно (т.е. записанные не на компакт-диске). Также необходимо помнить следующие общие правила: Никогда не забывайте показывать текст сообщений об ошибке техническому писателю; Всемерно старайтесь делать текст сообщения возможно более коротким. наверх     к оглавлению Пузырь как альтернатива сообщениям об ошибке В Windows появился элемент управления, значительно лучше предназначенный для показа сообщений: пузырь (balloon). Пример пузыря Пузырь, по сравнению с диалоговым окном, имеет существенные достоинства. он гораздо слабее сбивает фокус внимания, нежели окно; чтобы закрыть пузырь, пользователям не обязательно нажимать на какую-либо кнопку, достаточно щелкнуть мышью в любом месте экрана; он не перекрывает значимую область системы; он показывает, в каком именно элементе управления была допущена ошибка. К сожалению, пузыри имеют и недостатки: в них не может быть никаких элементов управления; пузырей пока нет в интернете. наверх     к оглавлению Сообщения о завершении операции Сообщения о завершении операции сходны с сообщениями об ошибках. Они точно также могут вызывать раздражение пользователя, снижать его субъективное удовлетворение от системы и отвлекать от выполнения основной задачи. Тем не менее в отличии от сообщений об ошибках в сообщениях о завершении операции есть необходимость и полностью избавиться от них невозможно. Таким образом, нужно попытаться сделать их как можно менее навязчивыми и «вежливыми». Разрабатывая очередную программу, необходимо учитывать следующие принципы: Необходимо предлагать пользователю обратную связь, не прерывая его. Например, представим, что был произведен поиск по запросу пользователя и теперь должно появится сообщение о результате. Представим, что этот поиск необходим для заполнения одного из полей на форме пользователя, как, например, адрес человека, кому он должны послать ее, полученный из адресной книги. Вместо того, чтобы трубить об успешном результате, необходимо просто заполнить это поле. Если требуется дальнейшая обратная связь, необходимо сделать желтую иконку, мигающую во время поиска. В случае успешного результата необходимо сменить цвет на зеленый, в случае неудачи - на красный. Если форма достаточно большая, пользователь может в это время находиться в другом разделе, поэтому нужно поместить где-нибудь индикатор состояния для всей формы. Индикатор статуса в форме иконки может обозначать следующее: "где-то на этой форме поле помечено красным. Нажмите, чтобы найти его". Когда пользователь закончит заполнять форму и увидит зеленый индикатор, он поймет, что можно идти дальше. Пример самого бесцеремонного прерывания пользователя. Когда пользователь находится в другом приложении, поверх приложения выскакивает не только окошко о завершении операции форматирования, но и само окошко форматирования. Почему не сообщить о завершении операции путем мигания кнопки в панели задач? Используйте само-срабатывающие диалоги.Например, диалоги печати спрашивают пользователя, сколько копий ему нужно, и т.д. Затем они сидят на экране в течении следующих трех дней в ожидании ответа. Пользователь ушел на обед, забыв, что должен появиться этот глупый диалог, и ждет что к его приходу 500-страничный документ будет напечатан. В программе ни к коем случае не должно возникать таких ситуаций. В данном случае программа должна догадаться, что если пользователь послал на печать, значит ему нужна как минимум одна копия. Поэтому, когда пройдет пара минут, необходимо начать печать. Даже если получится так, что пользователю нужны две копии, он всегда может отпечатать еще одну, или даже сделать копию на копировальном аппарате. В любом случае, время не будет потеряно. Если говорить о перспективах, то уже сейчас есть технологии отслеживающие направление взгляда. Эти технологии можно применять и в случае с сообщениями. Увидев что пользователь прочитал сообщение, в течении нескольких секунд система должна сама закрывать окно. ДНеобходимо думать о сообщениях, как о советах ценного помощника. Делать их вежливыми, полезными и прерывающими пользователя, только если это необходимо. наверх     к оглавлению

Типичные интерфейсные ошибки отечественного ПО << к предыдущей главе

Серьёзная эргономическая экспертиза программного продукта (usability testing) - дело нетривиальное и дорогое, проводится по специальным методикам и позволяет получить как качественные, так и количественные оценки эргономичности как программного продукта в целом, так и таких его важных компонент, как пользовательский интерфейс и пользовательская документация. Не имея такой возможности - проводить серьёзное исследование, я попытаюсь лишь предоставить примеры эргономических проблем, возникающих при производстве программных продуктов. Таким образом, предлагаемый обзор является довольно поверхностным, так как используется эвристический метод оценки пользовательского интерфейса и эргономичности программ. Итак, проблемы, как правило, бывают трёх типов: Глобальные эргономические противоречия Неадекватное применение интерфейсной парадигмы Ошибки проектирования элементов пользовательского интерфейса (как целых форм, так и аспектов применения конкретных элементов управления). Оказывается, что практически в любом мало-мальски сложном отечественном программном продукте эргономические проблемы всех трёх типов присутствуют в изобилии. Разберем их подробнее. Программа перегружена элементами управления Терминология не адекватна знаниям пользователя о системе От пользователя постоянно требуется дополнительная информация Программа не готова к немедленной работе и требуют настройки Программа имеет многодокументный интерфейс Отсутствует единый стиль Программа перегружена окнами сообщений Интерфейс отражает внутреннюю структуру реализации и мышление программистов Взаимное размещение объектов на экране не совпадает с их логической связью и/или с их важностью Пиктограммы используются некорректно наверх     к оглавлению Программа перегружена элементами управления Эту проблему без преувеличения можно назвать наиболее типичной для российского программного обеспечения. Суть проблемы заключается в том, что структура пользовательского интерфейса приведена в соответствие с информационными потоками (структурой объектов) внутри самой системы, а не в соответствие со структурой реальной деятельности пользователей. Как следствие, интерфейс "зашумлен" информацией, релевантной объекту, с которым работает пользователь, но либо не нужной ему сейчас, либо не нужной ему вообще, поскольку разным сотрудникам нужна разная информация Так при оптимизации интерфейса большой системы был проведен анализ одного из диалогов запроса данных. В общей сложности, в этом окне было 15 полей ввода и 6 чекбоксов. Как показал анализ интервью пользователей, в работе постоянно нужны только два поля ввода и два чекбокса, ещё одно поле ввода нужно изредка. Таким образом, экран содержал пятнадцать ненужных элементов управления, при этом основные элементы даже не были расположены в первых рядах, на них не позиционировался курсор, они никак не были выделены. Более того, большинство пользователей не могло ответить на вопрос, что означают некоторые из имеющихся полей. Примера перегруженного интерфейса программа для агентств недвижимости Flat. Разработчикам следовало бы разбить это окно как минимум на два. В первом разместить параметры, которые в первую очередь влияют на выбор квартиры. Вторую сделать как окно с дополнительными (второстепенными) параметрами, которые можно просмотреть в том случае если жилье заинтересовало и необходимо сделать выбор между несколькими вариантами. Также примером перегруженного интерфейса можно назвать интерфейс 1С.Ни в одной другой программе вы не найдете такого количества интерфейсных элементов как в 1С Предприятие. Опрос пользователей этой программы выявил следующие факты: Считают программу сложной абсолютно все. Никто из опрошенных не получает никакого удовольствия от работы с этой программой. Опять же из-за ее сложного интерфейса. Большая часть пользуется "необходимым минимуму" и даже не пытается расширять свои знания, считая изучение программы без помощи посторонних практически невозможным делом Многие считают что выполнили бы работу быстрее без программы. Выводы Проектируя систему, прежде всего, необходимо приводить структуру пользовательского интерфейса в соответствие со структурой реальной деятельности пользователей. Спроектированную систему необходимо тестировать, тогда будет точно ясно какая информация первостепенна для пользователей, а какую можно скрыть. Если от большого количества интерфейсных элементов никуда не уйти, необходимо группировать их, причем исходя их логики пользователя, которые будут пользоваться этим ПП. Часто используемые элементы и функции необходимо помещать на самые видные места, помещая на них фокус ввода или каким-нибудь образом отделяя их от второстепенных функций. наверх     к оглавлению Терминология не адекватна знаниям пользователя о системе Так как программы пишут программисты, они часто забывают, что пользоваться ими будут обычные люди, которые не знакомы с их терминологией. Большинство людей в действительности толком не представляют себе что такое, например "база данных" или понятие "записи". Файлы и манипуляции с ними тоже сложны для пользователей. Такая терминология пугает пользователей, в результате чего снижается эффективность их работы. Практически всегда в подобных случаях можно назвать вещи более понятными именами. Программа должна говорить с пользователями на их языке. Прежде всего, это касается ПО для интернета, антивирусных и мультимедиа программ. Аудитория пользователей этих программ чрезвычайно широка, причем основную массу составляют как раз неопытные пользователи. Окно популярной почтовой программы Bat.Для того чтобы начать получать/отправлять почту пользователю необходимо пройти через обязательную процедуру определения параметров получения и отправки почты. Начинающие пользователи в массе свое прибегают в этом случае к помощи более опытных знакомых ("спецов"). Хотя процедура не казалось бы такой сложной, если бы не профессиональная терминология, использованная при обозначении параметров. Прежде всего трудности возникают с серверами. Во-первых, большинство пользователей вообще смутно представляют себе что такое сервер, не говоря уже о том что они просто не знают что такое POP и SMTP. Все было бы проще, если бы поля ввода просто обозначались бы как "Адрес". В купе с помощью размещенной на самих почтовых серверах, это помогало бы пользователю заполнять эти поля "ритуально", без построения ментальной модели. Во-вторых, параметр Connection (не говоря уже о том, что он почему-то написан по-английски), можно убрать во вкладку "Дополнительные параметры", в которую должна быть переименована вкладка "Аутентификация" (еще один не понятный термин). Туда же необходимо поместить и значения портов. Как грамотно организовать вкладку "Дополнительные параметры" это уже отдельный разговор. Тем более, можно предположить, что уже в ней будут залезать, только "продвинутые" пользователи. Выводы Еще на начальной стадии проектирования системы необходимо составлять глоссарий используемых в системе терминов. Этот глоссарий должен отдаваться на рассмотрение потенциальным пользователям, которые должны указать, какие термины им непонятны и должны быть исправлены. После тестирования глоссария, необходимо тестировать саму систему на предмет понятности терминов в контексте программы. наверх     к оглавлению От пользователя постоянно требуется дополнительная информация Нормой в отечественных программах является создание ситуаций, в которых пользователь должен ввести информацию, которую может ввести за него программа. Также повсеместно распространена практика, когда пользователь должен вводить информацию которую он уже когда-то вводил. Зачастую вопросы, которые задает система, могут просто поставить пользователя в тупик и надолго заморозить его работу, из-за того, что пользователь просто не обладает той информацией, что запрашивает система, либо чтобы найти эту информацию нужно время Это сообщение возникает при удалении справочника в программе АРМ Секретарь. Мало того, что программа пугает пользователя непонятными для него терминами (база данных), она еще и спрашивает у него самого, что ей с этим делать. Подобное окно появляется в переводчике Promt при попытке открыть файл с целью перевести его. В нем предлагается выбрать формат открываемого файла. Совершенно не понятно, почему программ сама не может определить формат открываемого файла, перекладывая эту задачу на пользователя, тем самым, провоцируя к созданию ошибочной ситуации. Такой тирадой сообщений засыпает пользователя программа 1С. Ни о какой комфортной работе при таком количестве сообщений не может быть и речи. Выводы Прежде всего, необходимо так проектировать систему, чтобы она, основываясь на информации, которая у нее уже есть, принимала решение сама. Если система не обладает 100% достоверной информацией, она должна принимать решения, основываясь на самом высоковероятном, либо сразу предоставлять пользователю выбор из наиболее вероятных действий. наверх     к оглавлению Программа не готова к немедленной работе и требуют настройки Это проблема особенно характерно для бухгалтерских программ. Зачастую оказывается, что покупка собственно софта и установка его на рабочие места - лишь малая часть всех затрат по работам, связанным с автоматизацией бухгалтерского учёта, это всего лишь вершина айсберга. Оказывается, в придачу к коробке с программой фирме ещё надо покупать специально обученного программиста. Многие пользователи не подозревают об этом, приобретая и устанавливая ПО. Недостатки использования такого решения следующие: Фирма-разработчик перенесла часть своих затрат на приведение своего продукта в готовый вид на своих клиентов. Теперь они несут дополнительные, и часто значительные затраты на начальную настройку и сопровождение с помощью дополнительных людских ресурсов - "настройщиков". Вследствие практически полной настраиваемости внешнего вида программы, конечный интерфейс для пользователя очень сильно зависит от тех самых "настройщиков", которые уж точно не являются специалистами по интерфейсам. Таким образом, пользовательский интерфейс, который должен быть спроектирован специалистами, "настраивается и конфигурируется" пользователями или "настройщиками". В результате неадекватно "настроенного" интерфейса страдают как сами пользователи, так и эффективность их работы. Выводы Вероятнее всего, решение этой проблемы лежит где-то в области разработки более конкретных настроек. Например такую программу как 1С:Предприятие можно спроектировать для специфических организаций ("Завод", "Школа", "Магазин", "Торговая фирма" и т.д), что сведет настройки к минимуму. Что касается интерфейса, то здесь следует, по крайней мере, постоянно работать над качеством в готовых настройках, дабы конечные "настройщики" использовали его в качестве образца. Высшим пилотажем было бы задание типовых интерфейсных стилей или шаблонов наверх     к оглавлению Программа имеет многодокументный интерфейс Практически все отечественные ПП, в которых обрабатываются какие-нибудь текстовые или табличные данные, используют многодокументный (MDI) интерфейс: много документов - одно окно, в то время как в мире уже признали его неэффективность и возвращаются к однодокументному интерфейсу (SDI): один документ - одно окно. Сам по себе этот стиль интерфейса может оказаться полезным только в исключительных случаях, так как он по своей природе заставляет пользователя манипулировать окнами, вместо того, чтобы позволять ему делать свое дело. Пользователю приходится ворочать массу бессистемно открытых и неупорядоченных окон, что явно скажется на эффективности его работы не в лучшую сторону. Такой бессистемный подход может запросто привести к ситуации, когда очередное открытое окно будет просто "потеряно" или надолго оставлено без внимания в мешанине открытых окон. Выводы Для программ, которые работают с разными типами документов решение этой проблемы - разработка набора так называемых рабочих областей (workspaces), то есть экранов, в каждом из которых сосредоточены необходимые функции для решения той или иной задачи пользователя (простейший пример такого приложения - Outlook Express). Для этого необходим тщательный анализ деятельности пользователей программы, включения всего комплекса эргономических работ в процесс проектирования ПО. наверх     к оглавлению Отсутствует единый стиль Целостность - одно из важных свойств интерфейса. Целостность облегчает обучение новых пользователей и повышает производительность опытных. Например, регулярное расположение кнопок (и других элементов интерфейса) оправдывает ожидания пользователя - ему не приходится тратить усилия на поиск и распознавание кнопок. Кроме того, существуют правила оптимизации перемещений курсора мыши, которым рекомендуется следовать при размещении элементов управления пользовательского интерфейса. Явный пример отсутствия целостности Примеры управляющих кнопок, собранные со всей программы. Много говорить здесь не надо - о какой целостности интерфейса может вообще идти речь? Выводы Необходимо соблюдать хотя бы элементарные требования к целостности: кнопки в диалоговых окнах должны располагаться на одном и том же месте в одном и том же порядке, подписи к полям должны быть сделаны одним шрифтом, одна и та же функция встречающаяся в разных местах программы должна называться одинаково и т.д. наверх     к оглавлению Программа перегружена окнами сообщений Привычка при каждой неоднозначной ситуации выводить на экран диалоговое окно, наверное, еще долго будет влиять на создание интерфейсов отечественного ПО. В некоторых программах при закрытии окна документа пользователь может увидеть до 4-х сообщений, на каждое из которых ему придется ответить. В программе Зарплата 2000 встречается пример неудачного использования диалоговых окон. Для расчета зарплаты запись о работнике нужно добавлять в расчетную ведомость. Если же запись об этом работнике уже есть, программа выдает 2 (!) сообщение подряд. Мало того что сообщение здесь излишне - программу можно реализовать так, что ситуация с внесением работника повторно может никогда не произойти, так еще оно разбито на два. А если у вас 100 сотрудников и пользователь нажмет кнопку Добавить всех (которая, кстати, присутствует в этой программе)? В результате ему придется 200 раз нажимать на кнопку Ok! Будете ли он делать это? Скорее всего просто закроет эту программу. Пример бесполезного сообщения, которое появляется при некорректном открытия файла. Система сама предоставляет пользователю выбрать формат и сама же удивляется, если пользователь допускает ошибку. Тем более что вне зависимости от того, какую из кнопок нажмет пользователь, программа не производит никаких действий. Еще одно бесполезное сообщение. Вместо того чтобы предложить пользователю варианты решения проблемы или самой догадаться о способе решения, система ограничивается бесполезным, а зачастую просто раздражающим сообщением. Выводы Прежде всего, систему необходимо проектировать таким образом, чтобы в ней отсутствовали такие ситуации, в которых пользователь может совершить какую-нибудь ошибку. Например, для ввода данным можно использовать интерфейсные элементы с жестко заданным диапазоном значений. Следующее что можно сделать это считать всю информацию, которую пользователь вводит в программу, верной по определению. Все сообщения должны быть протестированы на предмет их целесообразности. Большинство из сообщений о завершении какой-либо операции или сообщении о изменении состояния могут быть безболезненно убраны, остальные преобразованы в другие формы подачи сообщения: пузыри, индикаторы, подсветка и т.д. наверх     к оглавлению Интерфейс отражает внутреннюю структуру реализации и мышление программистов Зачастую разработчики, в особенности небольшие компании, в которых экономят на таких специалистов как юзабилити-эксперт (а в российских фирмах на них экономят всегда), совершенно не задумываются, что пользоваться программой будут люди не знакомые с ее внутренней структурой. Как следствие с конвейера выходят программы совершенно неудобные в использовании, в структуру которых необходимо долго вникать Программирование - очень сильно ориентированный на функции процесс, поэтому пользовательский интерфейс часто создается подобным образом. Например, некоторые разработчики считают, что каждую функцию нужно помещать в отдельное диалоговое окно. Для достижения множества целей пользователю необходима целая серия функций. Если в программе используется одно окно для одной функции, экран быстро становится визуально загроможденным. Опуская тот момент, что меню здесь жутко загромождено во-первых разделителями, а во-вторых - пунктами меню - разделителями (помеченными "======"), следует обратить внимание на структуру программы. Она построена в соответствии со структурой организации, а не в соответствии с порядком использования информации. Такой элемент управления используется в основном в приложениях, работающих с базами данных, и служит для перемещения по записям. Во-первых, этот элемент понятен только программистам. Большинство пользователей не имеют никакого представления о базе данных, таблице (в понимании таблицы с данными) и записях в таблице. Они не знают, что можно "двигаться по записям", и что есть конец и начало записей. Это терминология программиста. Во-вторых, такой элемент управления заставляет пользователя "блуждать в темноте" - в большинстве программ, где он используется, на экране видна одновременно только вся информация об одной "записи", и никакой информации, что стоит за ней, а что перед ней. Более того, люди редко просматривают информацию в такой последовательности вообще (а в данном случае порядок представления информации еще и задается положением записей в таблице ). Чаще всего люди выбирают информацию из списка на экране по какому-то одному критерию (например, фамилия). Предоставление всей информации, которая есть для ориентации бесполезно - пользователь только теряется. И, наконец, элемент навязывает пользователю, что данные расположены как-то горизонтально, хотя физически у них нет направления. Выводы Интерфейс программы необходимо разрабатывать еще на стадии проектирования всего ПП. Важно смоделировать пользовательские роли и сценарии и затем по ним тестировать спроектированный интерфейс. Это поможет избежать глобальных проблем структуры программы. наверх     к оглавлению Взаимное размещение объектов на экране не совпадает с их логической связью и/или с их важностью К сожалению, нормой является ситуация, при которой наиболее важные объекты (и, соответственно, наиболее важные действия) либо заслоняются от пользователя менее важными, либо находятся там, где пользователь не ожидает их найти. Например, типичный случай, когда программа, выполняющая только одну функцию, при этом вызвать эту функцию можно только из меню или с помощью пиктограммы на панели инструментов (при этом нужная пиктограмма не снабжена подписью и теряется на фоне других пиктограмм панели). Если бы кнопка для вызова этой функции была размещена ближе к центру окна программы, была сразу заметна и снабжена однозначной подписью, простота вызова функции увеличилась бы на порядок Программа должна активно помогать организовывать эффективную работу пользователя. В большинстве случаев программа сама может вычислить объём работ и приоритетность выполнения заданий пользователем, и предложить список работ пользователю в виде меню, списка актуальных задач (task framework), требующих пользовательского труда. Меню и панель инструментов переводчика PROMT. Упуская вопросы количества и понятности пиктограмм, следует отметить, что кнопка основной функции программы - перевода - никаким образом не доминирует над всем этим многообразием элементов управления. Меню и панель инструментов программы распознавания текста FineReader. Не говоря уже о том, что количество пиктограмм на порядок меньше, а понятность их на порядок выше, триада основных функций программы - отсканировать, распознать, проверить - сразу бросается в глаза. Кнопки расположены именно там где пользователь и ожидает их найти. А расположение и обозначение кнопок в виде неделимой последовательности действий, сокращает время обучения практически до 0. Отличный интерфейс. Еще один характерный пример. Цель этой программы одна - проигрывать видео. Так почему же кнопка Play одного размера и цвета с, к примеру, настройками видео. Первое, что видит пользователь открыв программу - полтора десятка невыразительных кнопок, а должен видеть только две - открыть и проиграть. Выводы В дизайне интерфейсов, как и в любом дизайне, необходимо уделять внимание "расстановке акцентов". Пользователь должен загружать программу и сразу понимать, что ему нужно сделать в первую очередь. Существует множество способов достижения этой цели и как правило хороший эффект достигается от применения всего комплекса мер по улучшения понятности интерфейса. Это и группировка элементов методом карточной сортировки, и умеренность в пиктограммах, и качество их прорисовки, и построение структуры программы в соответствии с представлениями пользователя, и многое-многое другое. Для правильного построения пользовательского интерфейса, отражающего адекватный алгоритм деятельности пользователя, необходимы usability-исследования с привлечением конечных пользователей и экспертов. Такие сложные работы обычно принято проводить параллельно процессу проектирования ПО, начиная с ранних стадий проектирования. наверх     к оглавлению Пиктограммы используются некорректно Несколько непонятный заголовок этого раздела объясняется тем, что проблем у пиктограмм много и проблемы совершенно противоположны друг другу. В одних случаях применяются излишне детализованные пиктограммы, в других случаях сюжет настолько прост, что может обозначать что угодно. В одних случаях пиктограмм слишком много, в других слишком мало. Вообще, если обобщить, то анализируя российское программное обеспечение (да и не российское тоже) создается впечатление, что используют пиктограммы только с одной целью: "чтоб красивее было". Тем не менее грамотное и самое главное умеренное использование пиктограмм, продуманность из сюжета может положительно сказаться на таких критериях как: высокая скорость обучения пользователя, субъективная удовлетворенность и производительность. Пример избыточной детализации пиктограмм. Например, зачем нужен зеленый значок на папке с документами? Или к чему рисовать содержимое корзины, когда метафора самой корзины и так легко узнаваема? Пример пиктограмм выдержанных в единой стилистике. Во второй строчке оригинальные пиктограммы программы, в первой строчке стандартные Windows пиктограммы (открыть, сохранить, поместить в буфер и т.д.), адаптированные под стилистику программы. Плюсы - хорошо для брэндинга, минусы - уменьшается скорость распознавания - уж слишком пиктограммы похожи друг на друга. Для запуска проверки на вирусы в Dr.WEB неудачно использована метафора светофора. Красная она потому, что в данный момент пользователь не выбрал ни один элемент для сканирования. Но как пользователь догадается, что нужно сделать, чтобы она стала зеленой? Список доступных дисков для сканирования не подает никакого сигнала о том, что эти диски можно выбрать. А красный цвет на кнопке "отпугивает" пользователя от ее нажатия. Некорректное использование метафоры заключается в том, что здесь индикатор совмещен с элементом управления (кнопкой). Тогда как в реальной жизни светофор сам меняет свое состояние. Пример не очень качественных и не очень понятных пиктограмм (пиктограммы не подбирались, а взяты скопом из одной панели). Одинаковая форма, незначительные различия в расцветке и полное отсутствие аналогии с предметами реального мира делают задачу запоминания этих пиктограмм практически невозможным. Выводы Рекомендации тут банальны. Прежде всего, пиктограмм не должно быть очень много как в панели инструментов, так и в меню. Второй момент, сюжет пиктограмм должен быть простым, легко узнаваем и самое главное однозначно ассоциирован. Чтобы пиктограммы хорошо смотрелись их лучше делать в одной стилистике, но при этом стараться чтобы они отличались друг от друга (либо цветом, либо формой элементов, либо еще каким-нибудь внешними характеристиками).