Критерии хорошего диалога




 

Поскольку при построении диалога «человек-компьютер» машина не может полностью сыграть роль человека, то разработчику не следует слишком сильно ориентироваться на модели общения людей друг с другом. Однако, как правило, пригодность структуры диалога можно оценить путем анализа того, какая структура диалога "человек-человек" используется в аналогичной ситуации.

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

- естественность;

- последовательность,

- краткость,

- поддержка пользователя;

- гибкость/тактичность.

Рассмотрим эти критерии более подробно.

 

Естественность.

 

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

Естественный диалог максимально поддерживает привычки пользователя. Сказанное относится и к смене версий программы. Новая версия должна унаследовать основные черты интерфейса для облегчения адаптации пользователя. К сожалению, этого нельзя сказать о продуктах Microsoft, например, при смене Office 2003 на Office 2007 или Windows XP на Windows 8 – интерфейс поменялся на 90% и стал далеко неочевидным.

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

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

Фразы по возможности не должны требовать дополнительных пояснений. Слова ПЕЧАТЬ, КОПИРОВАТЬ, ПЕРЕМЕСТИТЬ имеют очевидное значение, в то время как команды PIP (СР/М) или MV (UNIX) неочевидны.

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

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

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

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

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

 

Последовательность/стандартизация.

 

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

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

Программное обеспечение имеет четыре элемента, описывающих пользовательский интерфейс:

1. Представление (Presentation) – что пользователь видит.

2. Взаимодействие (Interaction) – как пользователь взаимодействует с компонентами.

3. Действия (Actions) – каким образом выполняются сходные операции

4. Последовательность действий (Process Sequence) – как пользователь и компьютер взаимодействуют друг с другом. (подробной информации нет)

Рассмотрим эти элементы несколько подробнее.

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

Основными компонентами пользовательской среды являются экран, окна, пиктограммы, курсор/указатель мыши и выпадающие меню. Отсюда появляется аббревиатура WIMP: Windows, Icons, Mouse, Pull down menu. В окнах помещаются объекты, которыми управляет пользователь, пиктограммы изображают объекты, которые доступны, но временно не используются, указатель мыши – курсор, который, двигаясь внутри окна/экрана, позволяет пользователю выбрать любое действие, выпадающее меню необходимо для выбора действий из списка возможных.

1. Взаимодействие – описывает механизм, с помощью которого пользователь работает с компонентами интерфейса. В интерфейсе, управляемом пользователем, фундаментальной является концепция УКАЖИ и ВЫБЕРИ (Point-and-Select), то есть пользователь указывает и выбирает то, что он хочет. Управление при этом осуществляется как с клавиатуры, так и с помощью мыши, причем, при использовании клавиатуры действия пользователя ограничены активным окном, а при помощи мыши пользователь может указать любой видимый объект на экране.

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

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

Стандартные ответы или реакции системы должны быть действительно стандартными. Если пользователь для ответа на какой-либо вопрос может получить помощь, нажав клавишу F1, то при ответе на любой другой вопрос он должен получать помощь путем нажатия клавиши F1. В идеальном случае клавиша F1 не должна иметь других функций, кроме функции вызова справочной информации или помощи системы. Аналогично клавиатурная комбинация Ctrl-C во всех приложениях Windows означает копирование объекта или фрагмента.

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

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

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

 

Краткость.

 

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

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

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

Метка окна ввода должна быть краткой, например, иметь вид «Фамилия», а не «Введите здесь фамилию клиента». По возможности нужно использовать минимальное количество слов.

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

 

Поддержка пользователей.

 

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

Инструкции для пользователя выводятся в виде подсказок либо справочной информации. Характер и количество инструкций должны соответствовать опыту работы пользователя с системой и его намерениям. Нерационально выдавать инструкции, которые не требуются пользователю или не имеют отношения к его проблеме. Справочная информация должна появляться тогда, когда она требуется, в приемлемой форме и в фокусе внимания пользователя. Для простейших справок подходят хинты (hints) – всплывающая подсказка, появляющаяся после наведения курсора на объект или команду.

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

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

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

 

Сообщения об ошибках

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

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

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

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

 

Как правило, ошибки возникают из-за некорректного ввода данных пользователем. Условно ошибки можно разделить на 3 класса:

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

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

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

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

1. В чем заключается ошибка?

2. Как исправить проблему сейчас?

3. Как сделать так, чтобы ошибка не повторилась?

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

 

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

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

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

 

 

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

Другой превосходный способ избавиться от сообщений об ошибках – сделать программу достаточно сообразительной, чтобы она не требовала лишнего. Многие сообщения об ошибках имеют такой вид: «Неправильный ввод. Пользователь должен ввести ХХХХ». Если программа знает, что именно должен ввести пользователь, почему бы ей не ввести это самой, перестав трепаться попусту? Вместо того чтобы требовать от пользователя ввести имя файла и давать ему возможность ошибиться, заставьте программу запомнить, с какими файлами он работал раньше, и выведите их список. Еще один пример: сделайте так, чтобы программа получала дату от системных часов, а не требовала ее пользователя.

Одной из проблем сообщений об ошибках является то, что они уведомляют о неприятностях по факту. Они говорят: «Случилось нечто плохое, и все, что вы можете сделать, – признать катастрофу». Полезность таких сообщений сомнительна. И все эти диалоговые окна снабжены кнопкой ОК, требующей от пользователя стать соучастником преступления.

 

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

 

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

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

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

 

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

 
 

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

 

 

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

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

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

 

Звуковая обратная связь 611

 

 

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

 

 

Гибкость, тактичность

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

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

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

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

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

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

Наиболее важные качества следующие:

1. Проявлять интерес

2. Вести себя почтительно

3. Проявлять услужливость

4. Проявлять здравый смысл

5. Предупреждать желания людей

6. Проявлять инициативность

7. Не перекладывать на других свои проблемы

8. Держать коллегу в курсе дела

9. Проявлять понятливость

10. Иметь уверенность в себе

11. Не задавать лишних вопросов

12. Принимать ответственность

13. Знать, когда можно отклониться от правил

 

 

Гибкая программа:

1. Всегда интересуется пользователем и его предпочтениями, запоминает его привычки – с чем пользователь чаще работает, кому отсылает письма, настройки, вид представления. Примером являются браузеры Firefox и Microsoft Internet Explorer, которые запоминают вводимую пользователем на сайтах информацию, например, адреса доставки или регистрационное имя.

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

2. Тактичная программа относится к пользователю как к начальнику. Она его не критикует, а если что-то не так – объяснит что будет и подчинится воле пользователя.

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

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

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

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

ПРИНЦИП проектирования: Следует запоминать все, что выбирает пользователь.

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

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

 

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

8. В случае сбоев программа не перекладывает ответственность на пользователя, который к тому же не понимает о чем идет речь и каковы будут последствия любого варианта: «Системный файл Table.dbf изменен. Сохранить? Да/Нет».

9. Работает в условиях неопределенности. Системам, работающим вручную, присуща гибкость в плане возможности выполнения работы в состоянии неопределенности или в ситуациях с неполной информацией: «Ты начни пока оформлять, а остальное я привезу попозже». Человек может обойти инструкции, автоматизированная система – нет, даже ради некоторого выигрыша. Большинство программ признают только два состояния: объект либо отсутствует, либо полностью соответствует требованиям. Промежуточные состояния не распознаются и не принимаются. В ручном варианте можно выполнять действия в нестандартной последовательности или с нарушением формальностей – с человеком можно договориться. В автоматизированной системе сговорчивость теряется, если интерфейс следует модели реализации. Программист не видит необходимости в создании промежуточных незавершенных состояний, потому что компьютер в них не нуждается. Сговорчивая программа тоже должна работать в состоянии неопределенности, частично выполнять свои функции и следить за получением формальных данных к концу этапа. В реальном мире ограничения нарушаются постоянно. Тактичный продукт должен осознавать и учитывать этот факт.

 

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

 

В заключение можно привести слова крупнейшего на сегодняшний день американского специалиста по интерфейсам Алана Купера: «Без сомнения, все эти решения потребуют от программистов большей работы. Это нисколько меня не волнует. Я не хочу, чтобы программисты больше работали, но, выбирая из сложности работы программистов и сложности работы пользователей, я немедленно заставляю программистов работать. Работа программиста - удовлетворить пользователя, а не наоборот ».



Поделиться:




Поиск по сайту

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-04-27 Нарушение авторских прав и Нарушение персональных данных


Поиск по сайту: