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. Вы убьете этим сразу двух зайцев:

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