Взаимодействие человека и компа

потому что клавиша Alt+F4 не закрывает приложения. Многие интерфейсные

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

Предположим, что ваша фирма выходит на рынок с новой моделью

аудиомагнитофона, отличающейся от всех остальных некой возможностью А. Для

успешной продажи этой модели та кнопка на панели управления, которая

реализует А, должна быть как можно заметнее. Тогда потенциальный покупатель

сам спросит "А что это?" - и продать ваше изделие будет гораздо легче.

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

пользоваться стандартными кнопками для стандартных действий, показывая

возможность А только гостям.

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

и того же товара. Первая функция - продавать самого себя за счет

привлекательности и/или необычности внешнего вида, а вторая -

использоваться по назначению. С точки зрения продавца (а часто, и

производителя), первая функция гораздо важнее. Поэтому навязывается

"стандарт", направленный именно на успешность первой функции. Замените

аудиомагнитофон интерфейсными средами, и станет понятным, что имеется в

виду.

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

Пожалуй, главная из них - какие формы должно принимать авторское право на

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

хороший интерфейс - очень сложная задача, и авторы такого интерфейса должны

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

"защитить" такое решение патентом с последующими лицензионными выплатами,

это может спровоцировать авторов новых продуктов искать свои, нехоженые и,

зачастую, худшие пути в интерфейсе. В качестве яркого примера можно

попробовать представить себе последствия патентования использования клавиши

"F1" для вызова справки.

С проблемой защиты авторского права в области пользовательского интерфейса

связаны два громких судебных процесса - Apple Computer против той же

Microsoft, где предметом был сам оконный интерфейс, и Lotus против Borland,

где c правовой точки зрения оспаривалось включение в Qattro Pro (наравне с

несколькими другими) интерфейса Lotus 1-2-3. Нельзя сказать, что решения по

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

пользователей в них почти не учитывались, а результат, как это часто

бывает, соответствовал финансовым затратам сторон.

К сожалению, сегодняшнее состояние рынка программного обеспечения таково,

что дорогу себе прокладывают не лучшие решения, а решения, имеющие "большую

пробивную силу", в основном связанную с финансовой мощью предлагающих их

компаний. Это особенно верно для пользовательского интерфейса. Если

взглянуть на программы просмотра WWW, то вообще трудно говорить о дизайне

интерфейса - получилось как получилось. Терпимо, но не более. А ведь этими

программами пользуется большее число людей, чем какими-либо другими. Теперь

такой интерфейс становится фактическим стандартом, а это значит, что

последующий переход к более естественному интерфейсу (который, безусловно,

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

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

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

плохого интерфейса другим.

Заметим обычные ошибки.

1. Лишний выбор.

Программы тоже имеют свои хронологические записи – они называются окнами

настроек. Откройте Tools | Options и вы увидите историю аргументов

разработчиков по поводу дизайна программы. Должна ли программа

автоматически открывать последний файл, над которым работал пользователь?

Да! Нет! После двухнедельных дебатов, чтобы никого не обидеть, прнимается

решение сделать это настройкой.

Необязательно даже, чтобы это была дискуссия между двумя людьми, это может

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

быть оптимизированной по размеру или по скорости доступа. В результате мы

получаем самый идиотский «мастер» во всей истории Windows. Это окно

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

категории наград. Это окно, которое возникает при попытке в первый раз

найти что-то в файле справки:

[pic]

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

обращаетесь за помощью к файлу справки, и вам нет никакого дела, по крайней

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

покрытой шоколадом. Тем временем эта наглая программа читает вам лекцию о

том что она должно создать список (или базу данных). Наконец это окно даже

не диалог, а «мастер» (вторая страница которого, если перефразировать,

говорит что-то типа «спасибо за то что вы бесполезно потратили свое

время»). Очевидно, что у разработчиков была какая-то идея, какой из

способов лучше, но они так и не смогли порекомендовать пользователю ни один

из вариантов. Это приводит нас ко второму главному правилу дизайна

интерфейсов:

|Каждый раз, предоставляя пользователю выбор, |

|вы просите его принять решение |

Просить пользователя принять решение само по себе не так плохо. Свобода

выбора - это замечательно. Проблема возникает, когда этот выбор им не

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

сделать, но они не знают как. Например, создать приглашение на день

рождения. Это занятие может быть прервано тем, что они не знают, как

перевернуть картинку с воздушным шариком вверх ногами, или что-то еще,

поэтому они обращаются за помощью к файлу справки. И вот теперь какой то

программист-системы-индексного-поиска в Microsoft с идеей собственной

значимости имеет наглось еще раз прерывать пользователя и начинать учить

его, как создаются списки (или базы данных).

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

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

какой-то задачи. Они заботятся об этой задаче. Если это графическая

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

лучшего результата. Если это программа для создания web-сайтов, вы можете

быть уверены, что они жаждут сделать свой сайт именно таким, каким они

хотят его видеть. Но они не заботятся о том, где находится тулбар

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

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

ответственность дизайнера сделать этот выбор за них.

Когда в 1990 г. был выпущен Microsoft Excel 3.0, это была первая программа

с новым интерфейсным решением – панелью инструментов (toolbar). Это было

интересное решение, которое нравилось людям, и каждый стал его копировать –

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

инструментов. Успех панели инструментов вдохновил разработчиков Excel на

исследование с использованием специальной версии программы, котороую они

распространили среди узкого круга людей. Эта версия отслеживала наиболее

часто используемые команды и передавала эту информацию в Microsoft. Поэтому

в следующюю версию Excel был добавлен еще один ряд кнопок на панели

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

Великолепно.

Но проблема заключается в том, что создатели панели инструментов не знали,

когда следует остановиться. Они хотели позволить пользователям настраивать

панель инструментов. Они хотели дать пользователям возможность перемещать

панель инструментов по экрану. Затем они подумали о том, что меню – это не

что иное как панель инструментов, с надписями вместо иконок, поэтому они

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

это надо? Я ни разу не встречал человека, который бы хотел расположить меню

в каком либо другом месте, кроме как сверху. Но вот каковы последствия:

если вы случайно чуть-чуть промахнетесь мимо пункта меню Файл и двинете

мышкой, вы вытащите панель с меню туда, где бы вы меньше всего хотели её

видеть – блокируя документ, над которым работаете.

[pic]

Сколько раз вы видели это? И если это произошло по ошибке, не так то

просто догадаться что вы сделали не так, и как это исправить. В итоге

существует возможность (двигать меню), которая никому не нужна (хорошо,

пускай она нужна 0.1% всех людей), но которая мешает практически каждому.

Однажды мне позвонила моя знакомая и попросила помочь ей с проблемой

отправки e-mail. Она сказала «Половина моего экрана - серая».

Половина экрана серая?

За пять минут выяснения, что же все-таки произошло : она случайно

перетащила панель задач Windows к правому краю экрана, а затем случайно

расширила её.

[pic]

Такие вещи никто не делает специально. И множество пользователей просто не

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

какую-нибудь опцию в программе, вы не знаете, как вернуть ее обратно. Это

просто кошмар, как много людей деинсталлируют а затем заново устанавливают

программу, когда что-то идет не так, потомучто по крайней мере это они

умеют.

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

решение. Это не обязательно плохо, но все же вы должны всегда пытаться

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

Это не значит, что надо избавиться от всех случаев выбора. Для пользователя

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

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

случаях, сходите с ума: это здорово давать людям выбор, любыми способами,

чем больше, тем веселее. И есть еще одна категория, когда людям нравится

выбирать – возможность изменить внешний облик программы, не меняя ее

поведения. Все нравятся «скины» в WinAmp, каждый устанавливает себе

картинку на рабочий стол. Так как этот выбор оказывает влияние только на

внешний вид программы, не меняя ее функциональность, это хорошой способ

дать людям выбор.

2.Отрицательная обратная связь.

Когда пользователь видит на экране сообщение об ошибке, он чувствует себя

так же, как будто кто-то громким голосом и в снисходительном тоне сказал

ему "Это серьезная ошибка, приятель. Что за ерунду ты ввел?". Пользователям

это очень не нравится! Программы, работающие таким образом, имеют

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

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

просто не знают, как создавать надежные программы.

Первые компьютеры были маломощными и дорогими. Операторами этих машин были

ученые в белых халатах, которые понимали, что нужно процессору, и не

обижались, увидев сообщение об ошибке. Они знали, насколько сложна работа

компьютера. Они не имели ничего против появления сообщения типа " Abort,

Retry, Fail?" или др. Так зародилась традиция отношения программы к

человеку, как к процессору. С самого начала развития компьютерной техники

программисты уяснили, что самый верный способ взаимодействия программы с

пользователем - это требование от него ввода данных и выражение

недовольства, когда пользователь не смог достичь уровня совершенства

процессора.

Примеры такого силиконового ханжества встречаются везде, где программа

вынуждает пользователя действовать так, как это нужно ей, вместо того,

чтобы адаптироваться к нуждам человека. Силиконовое ханжество - это цикл

отрицательной обратной связи, в котором программа игнорирует пользователя,

когда он делает то, что она хочет, и кричит на него при малейшем

отклонении.

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

Каждый хороший программист знает, что если модуль А передал ошибочные

данные модулю В, то последний должен сразу же отбросить эти данные,

сгенерировав подходящее сообщение об ошибке. Отсутствие такого

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

люди - не модули программы. У людей есть эмоции и чувства - у компьютеров

их нет. Когда один кусок кода отклоняет ввод другого, последний не хмурится

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

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

предлагаете что-то коллеге по работе и он говорит вам "Заткнись, это

глупо!", это задевает ваши чувства. Вы начинаете думать, что вас не так

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

Все эти действия - часть человеческой натуры.

Однако на позитивную обратную связь люди реагируют очень хорошо.

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

введенную пользователем, она показывает некий индикатор успешного

завершения процесса. Если программа не может найти смысл во введенной

информации, она никак не реагирует, что указывает на ошибку. "Если не

можешь сказать ничего хорошего, лучше молчи".

Одна из причин того, почему программы так трудны в обучении - отсутствие

позитивной обратной связи. С позитивной обратной связью люди учатся лучше.

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

программа била им по рукам в случае ошибки. Человеку нужно вознаграждение,

или по крайней мере, уведомление в случае успеха.

Сторонники негативной обратной связи могут привести множество примеров ее

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

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

хотят сделать, но не должны. Но когда дело касается того, что люди хотят

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

инструктора, который кричит на вас или официанта в ресторане, который

громко объявляет, что ваша кредитная карточка недействительна.

Помните, что мы говорим о недостатках негативной обратной связи от

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

неприятна, может быть оправдана в определенных обстоятельствах. Слышать от

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

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

достаточной причиной для оправдания унижения человека. Ничто. Не имеет

значения то, насколько важна для вас целостность базы данных, она не стоит

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

вещь для вас, вы должны позаботиться о методах ее поддержания без унижения

пользователя.

Вот три основных способа избежать сообщений об ошибках:

1. Делайте ошибки невозможными

2. Закладывайте позитивную обратную связь

3. Проверяйте, не редактируйте

Наилучший способ избежать сообщений об ошибках это сделать так, чтобы

пользователь не смог их совершить. Вместо требования ввести данные с

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

Еще один прекрасный способ избежать сообщений об ошибках - это сделать

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

пользователю. Многие сообщения об ошибках говорят что-то вроде "Неверные

данные. Пользователь должен ввести ХХХХ". Почему же программа не может,

зная, что должен ввести пользователь, ввести ХХХХ сама? Вместо запроса у

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

файл, программа может запомнить, с какими файлами велась работа последний

раз, и предоставить их список.

Позитивная обратная связь - хороший способ вознаградить пользователя за

правильное пользование программой. Наилучший способ позитивной обратной

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

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

с ошибкой. Этот звук - публичное клеймо ошибки пользователя. Он громко

объявляет всем в пределах слышимости, что вы только что сделали нечто

глупое. Все то же силиконовое ханжество создало неоспоримую веру в голове

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

никогда более не должен считаться частью дизайна интерфейса. На самом деле

это не так.

В реальной жизни любой объект или система, за исключением компьютерных

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

определяем, что она защелкнулась, услышав щелчок, тишина означает, что

дверь еще не закрыта. Когда мы говорим с кем-либо и они отвечают "Ага" или

"Да-да" мы знаем, что наши слова до них доходят. Когда они молчат, значит

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

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

Наши программы были бы более дружественными и простыми в использовании,

если бы они издавали едва заметные, но легко узнаваемые звуки, когда

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

раз, когда пользователь ввел верное значение. Если программа не понимает

введенную информацию, она молчит. В этом случае пользователь может сразу

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

перетаскивать иконку, программа может коротко щелкнуть, а во время движения

объекта производить тихое шипение. Когда объект находится над областями,

где его нельзя оставить, звук меняется на что-нибудь более неблагозвучное.

Когда наконец пользователь отпустит кнопку мыши, он будет вознагражден

тихим "Да!", если действие завершено успешно, и тишиной из динамиков, если

действие не имеет смысла.

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

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

компьютером, и что они им не нравится, когда компьютер гудит и пикает на

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

установками:

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

об ошибке

2. Компьютерные звуки обычно громкие, монотонные и неприятные

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

обратной связи, они выберут первое. Если им дать выбор между отсутствием

звука и неприятными звуками для позитивной обратной связи, они сделают

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

между отсутствием звука и мягким и приятным звуком для позитивной обратной

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

шанса попробовать высококачественную звуковую положительную обратную связь

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

плохим интерфейсом.

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

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

раз, когда пользователь работает с программой правильно или каждый раз,

когда пользователь вводит информацию, которую программа понимает.

Пользователи быстро начнут зависеть от этих звуков, и начнут работать более

быстро и эффективно.

Без сомнения, все эти решения потребуют от программистов большей работы.

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

работали, но, выбирая из сложности работы программистов и сложности работы

пользователей, я немедленно заставляю программистов работать. Работа

программиста - удовлетворить пользователя, а не наоборот.

Еще один метод избежать сообщений об ошибках для программы, когда

пользователь вводит неправильные данные, состоит в том, чтобы принять, что

они неправильные, потому что программа, а не пользователь, плохо

информирована.

Если, например, пользователь вводит счет-фактуру для несуществующего номера

клиента, программа может принять эти данные, и сделать себе специальную

заметку, которая показывает, что пользователь должен исправить ее. Затем

она будет наблюдать, чтобы удостовериться, что пользователь ввел

необходимую информацию до конца отчетного периода. Так в действительности

работают большинство людей. Они не вводят "неверных" номеров. Просто люди

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

принять не может.

Но если вы настаиваете, я признаю единственную ситуацию, когда сообщение об

ошибке допустимо: Когда ваш принтер горит.

Выясняем, чего ожидают пользователи.

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

ней "с пустого листа". У него уже есть определенные представления о том,

как будет работать программа. Если он уже работал с подобной программой, он

будет думать что и эта программа будет работать точно также. Если они

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

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

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

пользователя: это его собственное понимание того что делает программа.

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

предназначения для исполнения процессором. Она называется "программной

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

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

удачным.

Вот один из примеров. В Microsoft Word (как и в большинстве других

текстовых редакторах) когда вы вставляете картинку в документ, она

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

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

останется в документе.

Однако язык HTML такого делать не позволяет. В HTML-документе изображения

хранятся в отдельных файлах. Если посадить пользователя, до этого

работавшего только с текстовыми редакторами, и ничего не знающего об HTML,

за современный визуальный HTML-редактор типа FrontPage, то он наверняка

решит, что все изображения будут храниться в этом же файле. Назовите это

инерцией модели пользователя, если хотите.

В итоге мы приходим к конфликту между моделью пользователя (изображение

будет встроено) и программной моделью (изображение должно находиться в

отдельном файле), а источником проблем является пользовательский интерфейс.

Если вы разрабатываете такую программу, как FrontPage, вы только что нашли

свою первую интерфейсную проблему. Вы не в силах изменить сам формат HTML.

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

пользователя.

У вас есть два варианта. Можно попытаться изменить модель пользователя. Но,

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

файл справки, но все знают, что пользователи его не читают. Можно вывести

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

в документ, но здесь тоже есть проблемы: сообщение будет раздражать опытных

пользователей, а кроме того пользователи не читают то что написано в окнах

сообщений (мы поговорим об этом позже, в шестой главе).

Итак, если гора не идет к Магомету, то придется изменить программную

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

копию в папку с документом, так что это будет по крайней мере

соответствовать копированию (а оригинал можно спокойно удалить).

Как выяснить, какова пользовательская модель программы?

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

пользователей! Выберите пять разных сотрудников вашей фирмы или друзей и

расскажите им в общих чертах, что делает ваша программа

Вам даже не нужна специальная usability-лаборатория - можно просто взять

первого попавшегося человека и провести с ним небольщой usability-тест.

Только не расказывайте им раньше времени как все работает. Попросите их

"думать вслух" и задавайте открытые вопросы, пытаясь выяснить, какова их

пользовательская модель.

Если модель вашей программы нетривиальна, то она наверняка не соответствует

модели пользователя. Большинство моделей пользователя не очень сложны.

Когда люди пытаются догадаться, как работает программа, они чаще

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

На картинке ниже показан экран компьютера Макинтош, изображающий две

открытых "книги" Excel (Spreadsheet1 и Spreadsheet2), и один документ Word

(Document 1). Любой пользователь, не знакомый с этой программой, подумает,

что все окна независимы, ведь они выглядят независимыми:

[pic]

Согласно модели пользователя, щелчок на окне Spreadsheet1 должен сделать

его активным. Но на самом деле активным становится окно Spreadsheet2:

[pic]

Оказывается, что программная модель MS Excel предполагает наличие

"невидимых" листов, к которым как бы прикреплены окна документов. Когда вы

делаете Excel активным приложением, все его окна тоже появляются сверху

остальных.

Невидимые листы? Какова вероятность того, что модель пользователя включает

в себя концепцию "невидимых листов"? Наверное около нуля. Таким образом

пользователи ранее не работавшие с этой программй будут удивлены таким

поведением.

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

модели, даже когда они просты. Когда же они становятся сложными, это еще

сложнее. Так что используйте самую простую модель.

Будьте последовательны

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

клавиатурой с оригинальной раскладкой клавиш. За ними невозможно будет

работать - пользователи привыкли к QWERTY и ЙЦУКЕН. То же касается и

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

программа будет для пользователя одним большим сюрпризом...

Заимствуйте

Что именно? Да все! Если пользователь привык к чему-либо, он быстрее

научится работать и будет получать больше удовольствия от работы с вашей

программой, так как сможет использовать приобретенные навыки. Базовое

заимствование - это использование стандартных элементов, общих для всех

программ Windows - меню, списки, кнопки и т. п. Более тонкое -

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

Взгляните на интерфейсы коммуникационной программы Trio Communication и

записной книжки Lotus Organizer. Trio выглядит как настоящий телефон, а

Organizer - как настоящая записная книжка. Только почему-то первой

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

Почему? Авторы Trio переделали все элементы управления на свой лад.

Программа разукрашена до такой степени, что на обучение работе с ее

оригинальным интерфейсом уходит масса усилий. Organizer же для стандартных

функций использует стандартные средства.

Не возбраняется заимствовать внешний вид, команды, удачные интерфейсные

решения и т. п. Хотите встроить в свою программу табличный редактор? Лучше

всего, если он будет похож на Excel. Вы убьете этим сразу двух зайцев:

а) пользователю не надо будет тратить время на обучение работе с

редактором;

б) человек вообще чувствует себя комфортнее рядом с чем-то знакомым.

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

хорошо знакомых и таких любимых песен.

Еще один плюс: этот способ позволяет легко добиться последовательности в

интерфейсе. В общем - то, что доктор прописал.

Бритва Оккама

Этот философский принцип гласит: "Не множить сущности без надобности". Или,

как говорят американцы, Keep It Simple, Stupid. На языке интерфейсов это

означает, что:

. любая задача должна решаться минимальным числом действий;

. логика этих действий должна быть очевидной для пользователя;

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

Метод drag'n'drop - перетащи-и-оставь - хорошая иллюстрация этого принципа.

Это абсолютно естественное действие, выполняемое одним движением мыши, с

великолепной оптимизацией движений курсора и глаз просто по определению.

Сам его очень люблю и стараюсь использовать везде, где это возможно.

Видимость отражает полезность

Самая важная информация и элементы управления должны быть на виду, легко

доступными, а менее важная - прятаться где-нибудь в меню. Интерфейс

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

пользователь, и отражать состояние текущего объекта. Хороший пример -

панели управления в Corel Draw 8.0. Они постоянно меняются в зависимости от

того, с каким объектом в данный момент работает пользователь.

Обратная связь

Пользователь должен всегда видеть, чем сейчас занимается программа или к

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

объяснить пользователю, что именно произошло и как это исправить. Например,

вот так.

Производительность компьютера против производительности человека

Существует две разных производительности - производительность компьютера и

производительность человека. Производительность компьютера – широко

известное техническое понятие и для ее увеличения существует множество

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

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

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

производительности человека, но есть и исключения. Во-первых, для этого

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

части. За последние 20 лет сложилась странная ситуация - в то время как

мощность компьютеров увеличилась в несколько тысяч раз, скорость работы

пользователя в некоторых случаях даже замедлилась из-за непомерно раздутых

операционных систем и программ. (В 1978 году мне требовалось три с

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

магнитофона на мой Apple II. Сейчас мой Maк загружается пять минут).

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

желанием инженеров увеличить производительность компьютера. Например,

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

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

Один из методов решения этой проблемы - предварительная загрузка данных.

Так как заранее неизвестно, какие именно данные потребуются, может

возникнуть необходимость загрузки большого объема данных, которые никогда

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

человека и компьютера.

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

не затрагивая аппаратную часть компьютера.

Производительность человека

Существуют два метода, которые ведут к значительному увеличению

производительности человека:

1. Полное отстранение пользователя от работы. Этот метод наиболее

эффективен, и сводит стоимость работы к нулю.

2. Эффективное использование времени пользователя

Хотя с этими методами никто не спорит, применение их на практике может

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

анализ и желание принести в жертву время и даже производительность

компьютера. Далее мы обсудим способы применения этих методов.

Три операции, которые можно упростить

Работая на компьютере, пользователи выполняют три основных операции:

1. Принимают решения на основе информации, касающейся текущей задачи

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

3. Манипулируют компьютером с помощью элементов управления

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

хотят ехать. Затем они находят информацию, необходимую для формирования

маршрута, например карту дорог. Наконец, они манипулируют рулевым колесом,

педалями акселератора и тормоза, тем самым давая машине постоянные

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

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

изменения маршрута, запроса новой информации и т.д.

Современная домашняя швейная машинка является более сложным механизмом, чем

автомобиль. Например, пользователь решил сделать определенный шов. Вместо

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

автомобилем, для большинства действий пользователь использует колесо с

ручкой. Выбор определенного типа шва представляет собой решение

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

привлекательно. Само колесо управления содержит информацию, необходимую для

принятия данного решения. Манипуляции пользователя сводятся к передвижению

ткани, тогда как машина двигает иглу.

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

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

и уменьшая количество манипуляций, необходимых для достижения цели, то

производительность человека при работе с компьютером значительно

увеличится. Давайте рассмотрим эти шаги в обратном порядке.

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

Представьте себе современный фотоаппарат. Единственное решение, которое

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

сфотографировать. Это объясняет большую популярность таких аппаратов,

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

хорошо освещенной и правильно сфокусированной.

Программы часто демонстрируют такую же механическую сложность, как и

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

Любой, кто хотя бы раз обновлял системное программное обеспечение, знает,

насколько сложной может быть эта задача, хотя для этого пользователю не

нужно принимать практически никаких решений.

Что можно вынести из этого примера? Разделяйте все операции на “манипуляции

с механизмом”, и более абстрактные, сообщающие машине то, чего она знать не

может.

После этого:

1. Уменьшайте число манипуляций, насколько это возможно. Действительно ли

необходимо второе окно, или же задание можно выполнить с помощью

одного? Действительно ли здесь требуется нажатие на клавишу? Можно ли

выполнить это задание за один шаг, а не за два?

2. Сделайте оставшиеся манипуляции подходящими к пользовательской модели

задачи. Избегайте требования от пользователя мысленного преобразования

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

наиболее естественный способ управления.

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

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

количество необходимой для ввода информации:

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

2. Минимизируйте, либо полностью устраните необходимость ввода

информации. Можно ли получить информацию на основе логического вывода?

Действительно ли данная информация необходима для выполнения этой

задачи?

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

Первый метод наиболее эффективен, когда ранее введенная информация

может быть использована еще раз. В противном случае все сбереженное

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

значения с новыми.

Этот метод зависит от доступности необходимой информации. На первый взгляд,

для Интернета с его медлительностью, это может показаться неприменимым. Как

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

компьютере? К счастью, в большинстве случаев этого и не требуется. Все что

пользователю необходимо знать – есть данная информация вообще или нет. Если

есть, пользователь может уточнить то, что ему нужно. Во время этого

процесса у системы, скорее всего, будет достаточно времени для передачи

информации в фоновом режиме.

Второй подход, минимизация ввода информации, может быть довольно сложным

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

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

попытаются уменьшить ее эффективность насколько это возможно, тем самым

получая обратно свое время и деньги. Они делают это не потому, что

действительно хотят работать с неэффективной системой, просто они вдруг

понимают, что теперь могут позволить себе потратить время на сбор

дополнительной, вторичной информации.

Третий подход, получение информации другими способами, требует значительных

усилий. Например, можно вводить информацию с бумажных форм в компьютер,

используя сканер и программу оптического распознавания текста. Однако в

зависимости от чистоты и избыточности поступающей информации, такой способ

Страницы: 1, 2, 3