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




(вместо ведения)

Homo sapiens и компьютеры : кто кем управляет ?




Тысячелетия развития промышленности , прошедшие с момента открытия огня и изобретения колеса до начала ЧЧ века, мало повлияли на "соотношения сил" между синими и белыми воротничками. Например, к 1900г.95% трудоспособного населения индустриально развитых стран были заняты физическим трудом. Однако ко времени окончания Второй мировой войны в США уже треть работников обрабатывала информацию, а не материальные объекты, к 1980г. - половина, а в ближайшее время, по некоторым прогнозам, фермеры и рабочие составят лишь 10% американских тружеников. Остальные будут работать с информацией, т.е. сидеть за компьютерами.

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

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

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

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

Судите сами. Вместо человекоподобных роботов Айзека Азимова и равного нам по интеллекту электронного мозга из "Космической одиссеи 2001" Стэнли Кубрика и Артура Кларка мы получили загадочный Солярис Станислава Лема - Интернет. С той существенной разницей, что этот мыслящий электронный океан плещется не где-то в космосе, а на нашей планете.

Впрочем, Интернет как технология не нов - он возник еще в 60-е годы. А вот явление, которое называется "персональный компьютер" , никто из специалистов , в том числе самых авторитетных не предвидел. Еще 20 лет назад невозможно было поверить, что вычислительная мощность IBM/370, занимавшей сотни квадратных метров специально оборудования помещения, еще при нашей жизни сожмется до размеров рабочего стола и будет стоить ненамного дороже телевизора.

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







Часть первая.

«Создатели».

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




На мой взгляд проблемы взаимонепонимания, которые возникают между пользователем и его компьютером может не на все 100%, но на половину из-за того, что к создателям программы применимы какие-то особые принципы. Почему-то считается нормальным то, чтобы создать, к примеру бухгалтерскую программу – программист должен изучить эту сферу, знать первичные документы, формы отчетности и т.д. Потому что, если он не знает этих основ – он не сможет создать корректно работающий продукт. И работники информационных отделов корпят над книгами по бухгалтерии, над новыми указами Министерств и Центрального Банка. Соответственно этому они создают программы, вносят изменения. И это воспринимается всеми, как должное. Почему же тогда не часто встретишь бухгалтера, который работая в своей программе , может объяснить, хотя бы алгоритм того, как это все работает. Часто происходят споры из-за того, что люди, непосредственно работающие с программным обеспечением не хотят не то, чтобы вникнуть в суть происходящего во время их работы, а хотя бы прочитать внимательно то сообщение, которое может выдать программа, при нестандартной для пользователя операции.




Возможно, что если бы во всех организациях при приеме на работу пользователя была бы проверка его знаний компьютера (а не просто прочтение тех умных слов, которые написаны у него в резюме) то возникало бы горазд меньше проблем при работе. Даже , если у работника (потенциального пользователя ПК) нет опыта работы с компьютером – это не его беда. Главное – чтобы руководство осознавало, как это необходимо для нормального хода работы и предпринимало какие-то шаги в сторону решения этой проблемы. Ведь есть компьютерные курсы, на которых непосвященные могут узнать, почему нельзя запускать Формат жесткого диска, почему прежде , чем нажать на кнопку «Да» надо уточнить, с чем именно соглашаешься и зачем надо сохранять, если пишешь длинный текст.




Часть вторая.

«Создателям»

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

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

Hе пытайтесь вникнуть в суть сказанного пользователем! Все равно ничего не поймете. Лучше смиритесь и идите к месту пользовательского преступления. Будьте готовы к тому, что он (она) обязательно пойдет за вами, приговаривая: "Вечером все было нормально, потом я скинул по электpонке , она не скинулась, спросила паспорт, потом показала красную рамочку, я зашел в синий экран, а там какие-то иероглифы, ну ничего не понятно, там еще что-то написала на английском, я нажал эскейп и, вот, сегодня монитор не включается".

Пока вы будете под столом втыкать вилку монитора в розетку, вам дадут несколько добрых советов – вопросов, что-то типа: "Это, наверное, от того, что у меня памяти мало. Давайте память почистим. А еще у меня мышка прыгает. Очень трудно работать. А можно мне код адреса электpонки поменять? А то от меня письма не всегда доходят. Вообще, компьютер у меня какой-то странный. То одно, то другое. Измучился уже с ним. Это пятерка? А память у него какая? А зачем в Экселе рисуночек справа? Ой, заработал!". И упаси вас Боже начать разъяснительную работу -- на вас обидятся. Почему-то считается, что компьютер не может быть выключен из сети по определению, а если это произошло, то только специалист сможет справится с водворением вилки на место.

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

- открываю файл, а там вирус сидит!

- У меня компьютер не работает, просит какой-то прямой Х! (DirectX).

- У нас 95-ый Эксел, а мои знакомые все перешли на 96-ой!

- У нас принтер команду не слушает!

- У меня приказа нет! (File is not ordered).

- Я не знаю, как отксеpить файл из Воpда в Эксел!

И так далее. А что вы хотели? Это для вас очевидно различие электронной почты локальной сети. Это вы не будете слать почтой DOOM на соседний компьютер. У вас рука не поднимется четырнадцать раз открыть бухгалтерскую программу. Вы никогда не засунете лист со скрепкой в лазерный принтер. И не подключите телефон в розетку локальной сети. Hо это вы.

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

Самые безобидные - это трусливые пользователи. Эти боятся всего. Они мучительно думают перед каждым нажатием клавиши. Любая неадекватная реакция техники на их действия вызывает полный ступор с последующей истерикой. Если такой пользователь говорит: "я работала и вдруг все пропало, теперь я боюсь тут чего-нибудь трогать", можете смело идти и развернуть свернутое окно. После этого на вас смотрят, как на Бога. Если вы пытаетесь что-то объяснить, они затыкают уши и просят прекратить говорить такие страшные вещи. Слушать ТАКОЕ - выше их сил.

И слава всем святым, что есть люди, которые хотят чему-то научиться, которые думают, а потом делают, и не делают, если не знают. Люди, которые, не зная, как сформулировать вопрос, просто просят подойти и посмотреть, что случилось. которые будут молча наблюдать за вашими действиями, а потом зададут единственный вопрос: "А что же было?". Им я отвечаю с удовольствием.

Даже , если у работника (потенциального пользователя ПК) нет опыта работы с компьютером – это не его беда. Главное – чтобы руководство осознавало, как это необходимо для нормального хода работы и предпринимало какие-то шаги в сторону решения этой проблемы. Ведь есть компьютерные курсы, на которых непосвященные могут узнать, почему нельзя запускать Формат жесткого диска, почему при наличии дискеты в дисководе не загружается их рабочий стол… И что это такое «рабочий стол»?

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

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

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

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

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

Выяснение целей и ограничений проекта

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

Рекомендуем вам уделить одинаковое внимание следующим пунктам:

• 
  Пользователи: их опыт работы с компьютером, мотивы, размер/важность групп пользователей, образцы (типовые ситуации) использования
  
• 
  Задачи: что послужило причиной создания проекта, этапы создания проекта, какие результаты должны быть получены, какая информация необходима и когда
  
• 
  Технология разработки и платформа, на которой будут работать пользователи
  
• 
  Среда, в которой будет создаваться и использоваться проект (физическая, рыночная, организационная и культурная)
  

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

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

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

• 
  Неожиданное или неконтролируемое повторение процесса разработки, когда некоторые важные факторы становится известны вам слишком поздно в процессе разработки. "Что? У пользователей будут экраны с разрешением 800х600? Окна нашей программы просто не поместятся на экране!"
  
• 
  Много дискуссий без значительного прогресса
  

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









Нужен ли нам специальный метод разработки пользовательского интерфейса?

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

• 
  Пользователи думают, что интерфейс - это и есть программа.
  
• 
  Чтобы пользователи работали более продуктивно, программа должна быть простой в использовании.
  
• 
  Достижения технологии значительно увеличили количество решений, которые необходимо принимать во время разработки интерфейса
  
• 
  Общеплатформенные стандарты пользовательского интерфейса решают только 15% вопросов разработки в типичном проекте.
  
• 
  Большинство программных проектов ограничены во времени.
  
• 
  Пользователи становятся все более привередливыми.
  
• 
  Хороший интерфейс может стать преимуществом против конкурентов, плохой - послужить причиной неудачи всего проекта.
  

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

Пользовательский интерфейс.

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

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

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

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

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

В качестве примера удачной метафоры в интерфейсе можно привести Lotus Organizer, внешний вид которого напоминает привычный еженедельник, функции которого и выполняет этот продукт. Примером неудачной метафоры, точнее ее полного отсутствия там, где она необходима, может служить Explorer Windows 95.

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

Наш (не)удачный предшественник - оконный интерфейс решил только первую задачу концептуального дизайна. В нем есть понятие "контролей" - интерфейсных элементов, с которыми в основном и происходит взаимодействие. В Windows 95 сделана попытка выработки общего изобразительного стиля для контролей. Об общем стиле экранного изображения речи вообще не идет, если только не считать за таковой набор "тем", входящий в состав Microsoft Plus.

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

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

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

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

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

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

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

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

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

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

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

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

Во всех центрах, известных разработкой новых интерфейсов (XEROX PARC, MIT Media Lab, Apple Computer, Carnegie Mellon University), идут разработки разных концепций дизайна интерфейсов, опирающихся на возможности анимации. Прежде чем описывать их надо изложить точку зрения на "физику интерфейса".

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

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

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

Эта возможность не только теоретически осознана, но и уже около пяти лет находится в стадии экспериментального исследования. Две анимированные среды интерфейса разработаны в той самой фирме XEROX PARC, которой мы обязаны появлением идеи оконного интерфейса (и даже в группе того самого Стюарда Карда, которому принадлежит авторство этой идеи). Одна - "Конические деревья" - является визуализацией файловой системы компьютера и похожа на систему детских пирамидок, каждый уровень которой соответствует уровню файлового каталога. Сами файлы из каталога отображаются в виде 3-мерной карусели под своим каталогом. Соль модели в том, что нужный файл можно "приблизить" поворотом карусели (может быть, не одной), идущим в режиме анимации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цитата из обзора интерфейсов - "Интерфейс этой программы неестественен, потому что клавиша Alt+F4 не закрывает приложения. Многие интерфейсные проблемы являются естественным продолжением маркетинговых достижений. Предположим, что ваша фирма выходит на рынок с новой моделью аудиомагнитофона, отличающейся от всех остальных некой возможностью А. Для успешной продажи этой модели та кнопка на панели управления, которая реализует А, должна быть как можно заметнее. Тогда потенциальный покупатель сам спросит "А что это?" - и продать ваше изделие будет гораздо легче. Однако, купив его и включив дома, этот покупатель будет, скорее всего, пользоваться стандартными кнопками для стандартных действий, показывая возможность А только гостям.

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

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

С проблемой защиты авторского права в области пользовательского интерфейса связаны два громких судебных процесса - Apple Computer против той же Microsoft, где предметом был сам оконный интерфейс, и Lotus против Borland, где c правовой точки зрения оспаривалось включение в Qattro Pro (наравне с несколькими другими) интерфейса Lotus 1-2-3. Нельзя сказать, что решения по этим делам могут использоваться как прецеденты, так как интересы пользователей в них почти не учитывались, а результат, как это часто бывает, соответствовал финансовым затратам сторон.

К сожалению, сегодняшнее состояние рынка программного обеспечения таково, что дорогу себе прокладывают не лучшие решения, а решения, имеющие "большую пробивную силу", в основном связанную с финансовой мощью предлагающих их компаний. Это особенно верно для пользовательского интерфейса. Если взглянуть на программы просмотра WWW, то вообще трудно говорить о дизайне интерфейса - получилось как получилось. Терпимо, но не более. А ведь этими программами пользуется большее число людей, чем какими-либо другими. Теперь такой интерфейс становится фактическим стандартом, а это значит, что последующий переход к более естественному интерфейсу (который, безусловно, рано или поздно произойдет) будет связан с тяжелой психологической ломкой.

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

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

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

Программы тоже имеют свои хронологические записи – они называются окнами настроек. Откройте Tools | Options и вы увидите историю аргументов разработчиков по поводу дизайна программы. Должна ли программа автоматически открывать последний файл, над которым работал пользователь? Да! Нет! После двухнедельных дебатов, чтобы никого не обидеть, прнимается решение сделать это настройкой.

 

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



 

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

 

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

 

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

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

 




Когда в 1990 г. был выпущен Microsoft Excel 3.0, это была первая программа с новым интерфейсным решением – панелью инструментов (toolbar). Это было интересное решение, которое нравилось людям, и каждый стал его копировать – до такой степени, что сейчас уже непривычно видеть программу без панели инструментов. Успех панели инструментов вдохновил разработчиков Excel на исследование с использованием специальной версии программы, котороую они распространили среди узкого круга людей. Эта версия отслеживала наиболее часто используемые команды и передавала эту информацию в Microsoft. Поэтому в следующюю версию Excel был добавлен еще один ряд кнопок на панели инструментов, на этот раз содержащий большинство часто используемых команд. Великолепно.

 

Но проблема заключается в том, что создатели панели инструментов не знали, когда следует остановиться. Они хотели позволить пользователям настраивать панель инструментов. Они хотели дать пользователям возможность перемещать панель инструментов по экрану. Затем они подумали о том, что меню – это не что иное как панель инструментов, с надписями вместо иконок, поэтому они дали пользователям возможность перемещать меню по экрану. Проблема: кому это надо? Я ни разу не встречал человека, который бы хотел расположить меню в каком либо другом месте, кроме как сверху. Но вот каковы последствия: если вы случайно чуть-чуть промахнетесь мимо пункта меню Файл и двинете мышкой, вы вытащите панель с меню туда, где бы вы меньше всего хотели её видеть – блокируя документ, над которым работаете.






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

 

Однажды мне позвонила моя знакомая и попросила помочь ей с проблемой отправки e-mail. Она сказала «Половина моего экрана - серая».

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

За пять минут выяснения, что же все-таки произошло : она случайно перетащила панель задач Windows к правому краю экрана, а затем случайно расширила её.



 

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

 

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

 

Это не значит, что надо избавиться от всех случаев выбора. Для пользователя есть достаточно решений, которые он должен принять в любом случае: как будет выглядеть документ, как будет работать веб-сайт, и т.д. В этих случаях, сходите с ума: это здорово давать людям выбор, любыми способами, чем больше, тем веселее. И есть еще одна категория, когда людям нравится выбирать – возможность изменить внешний облик программы, не меняя ее поведения. Все нравятся «скины» в 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). Любой пользователь, не знакомый с этой программой, подумает, что все окна независимы, ведь они выглядят независимыми:



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



Оказывается, что программная модель 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. 
   Быстро и точно предоставляйте пользователю информацию, необходимую для принятия решений.
   
4. 
   Избавляйтесь от ненужной информации.
   
5. 
   Визуально выделяйте наиболее вероятные варианты ответа.
   

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

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

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

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

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

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

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

Вместо такого вопроса:

Предложите следующий вариант:

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

Не задавайте также пользователю вопрос о какой-нибудь настройке, смысл которой неясен. Чтобы ответить на этот вопрос и решить, нужна ему эта настройка или нет, пользователю придется узнать все о ней. Спрячьте такую настройку в раздел “advanced”.

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

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

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

1. 
   Печать отнимает много времени
   
2. 
   Печать не требует вмешательства пользователя
   
3. 
   Общее время выполнения задачи предсказать нельзя
   
4. 
   Следующее задача пользователя обычно не связана с результатами печати
   

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

Та же самая ситуация сложилась сейчас с Интернетом. Загрузка страниц занимает длительное время, не требуя вмешательства пользователя в этот процесс, и предугадать, будет ли она длиться 5 секунд или минуту, невозможно.

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

Уменьшайте субъективное время восприятия

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

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

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

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

Все пользователи выполнили задание с помощью мыши примерно на 50% быстрее. Но что интересно, все высказались, что они выполнили задание гораздо быстрее с помощью клавиатуры.

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

Основная стратегия уменьшения субъективного времени восприятия:

Пользователи должны быть постоянно заняты

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

Приемы для уменьшения субъективного восприятия

Индикаторы

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

1. 
   Индикатор оставшегося времени. Поместите его либо в модальный диалог, либо в строку статуса.
   
2. 
   Индикатор “Система жива”. Когда оставшееся время предугадать невозможно, покажите анимированный объект, который даст пользователям понять, что система не зависла.
   
3. 
   Индикатор “Слышу и понимаю”. Когда ожидаемая задержка менее 2 секунд, показывать оставшееся время бессмысленно, поэтому просто измените форму курсора на “песочные часы”.
   

Для задержек от 0,1 секунды до 10 секунд:

1. 
   Подтвердите щелчок мыши или нажатие клавиши в течение 0,1 секунды.
   
2. 
   Измените форму курсора на “песочные часы” или другой анимированный указатель для любой задержки более 0,5 секунды.
   
3. 
   Покажите, когда пользователь может продолжать.
   

Для задержек от 10 секунд до 1 минуты:

1. 
   Подтвердите щелчок мыши или нажатие клавиши в течение 0,1 секунды.
   
2. 
   Привлеките внимание пользователя
   
3. 
   Укажите время ожидания точно или приблизительно.
   
4. 
   Выведите индикатор
   
5. 
   Покажите, когда пользователь может продолжать.
   

Для задержек от минуты до целой ночи:

1. 
   Подтвердите щелчок мыши или нажатие клавиши в течение 0,1 секунды.
   
2. 
   Привлеките внимание пользователя. Индикатор, который трудно заметить, может и не существовать.
   
3. 
   Сообщите пользователю, насколько долгим будет ожидание. Если не знаете – предположите диапазон значений. Даже довольно широкого диапазона (от 3 до 15 минут) пользователю может быть достаточно для принятия решения – переключиться на другую задачу, или же пойти попить кофе.
   
4. 
   Выведите индикатор.
   
5. 
   Четко и ясно сообщите пользователю, когда он может продолжать. Это не значит, что вы должны вывести сообщение шрифтом 96 размера. Это значит, что изменения на экране должны быть значительными, для того чтобы их можно было визуально различить.
   

Принципы вежливости программ.

Профессора Стэндфордского Университета Клиффорд Насс (Clifford Nass) и Байрон Ривз (Byron Reeves) занимались изучением реакции человека на компьютер. Применяя классические методы социальной психологии, они обнаружили в поведении людей нечто интересное. Результаты их работы, опубликованные в книге "The Media Equation", показывают, что человек реагирует на компьютер так же как на других людей. Из этого исследования следует важный вывод: Если мы хотим, чтобы наша программа понравилась пользователям, мы должны сделать ее поведение похожим на поведение человека. Довольно просто, не правда ли?

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

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

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

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

Может ли компьютер “лгать” вам? Может ли компьютер сказать вам, что у вас на счету “около 500$”? Может ли компьютер дать вам другой ответ, чем только что кому-то еще? Если мы увеличиваем человечность, мы должны уменьшить некоторую “компьютерность”, по крайней мере в сравнении.

Действительно, компьютер никогда не выдаст вам приблизительный баланс, но тогда компьютер не увидит разницы между выдачей сообщения о том, что у вас на счету “около 500$” за долю секунды, и точной суммы 503.47$ за 17 минут. Более вежливая, более человечная программа сразу бы сообщила, что у вас на счету “около 500$” а затем проинформировала бы вас, что даст более точный ответ через несколько минут. Тогда выбор будет за вами – стоит ли тратить время на дополнительную точность.

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

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

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

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

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

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

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

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

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

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

Вежливая программа отзывчива.

У меня на компьютере обычно установлено разрешение экрана 1024х768. Когда я провожу презентации, мне необходимо временно сменить разрешение на 800х600 чтобы оно соответствовало низкому разрешению моего видео-проектора. Многие из запущенных программ, включая Windows 95, реагируют на смену разрешения изменением размера, формы и положения на экране своих окон. Однако когда я меняю разрешение обратно, окна не возвращаются к своим размерам. Информация об этом легко доступна, однако программа не заботится о моих очевидных нуждах.

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

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

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

Вежливая программа хорошо информирована. Когда я ищу информацию в Интернет через поисковую машину, я не могу быть уверен, что не наткнусь на неработающую ссылку. Я выбираю нужную мне ссылку и получаю противное сообщение об ошибке “404 Link Not Found”. Разве поисковая машина не может периодически проверять каждую ссылку? Если ссылка неверна, ее можно удалить из списка, и мне не придется тратить время на ожидание ее загрузки.

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

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

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

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

Вежливая программа не задает лишних вопросов. Невежливая программа задает множество раздражающих вопросов. Когда выбор предлагают насильственно – это тяжелое испытание.

Выбирать можно разными способами. Возьмем, к примеру, разглядывание витрин магазинов. Мы обычно смотрим на витрины праздно, обдумывая, выбирая, или игнорируя товары, которые нам предлагают. С другой стороны, иногда нам насильственно предлагают выбор, как например на таможне: “У вас есть что-нибудь нуждающееся в декларации?”. Если нас поймают, последствия могут оказаться значительными. Но мы не знаем, что последует за этим вопросом. Будут нас обыскивать или нет? Если мы знаем, что обыска не избежать, мы никогда не будем лгать. А если мы знаем, что никакого обыска не будет, нас будет одолевать искушение провезти лишнюю пачку Мальборо.

Вежливая программа является подстраиваемой.

Когда система ручной обработки информации переносится на компьютеры, что-нибудь всегда теряется. Чаще всего система компьютеризируется для увеличения объемов обрабатываемой информации, а не для изменения свой функциональности. Однако системам работающим вручную присуща гибкость – свойство, которое на так просто выделить среди остальных. Хотя автоматизированная система ввода заказов может обработать в миллион раз больше заказов, чем простой служащий, служащий всегда может подстроить работу системы. В автоматизированной системе эта возможность исчезает. Нет практически никакой возможности изменить работу той или иной функции. Я называю эту способность человека действовать вне существующей схемы обработки информации до того, как все необходимы реквизиты будут доступны подстраиваемостью. Отсутствие это качества – одна из главных причин нечеловечности компьютерных систем. Это прямое следствие модели воплощения. Программисты не видят никакого резона в том, чтобы создавать промежуточные состояния, потому что в компьютере они не нужны. Но пользователь должен иметь возможность слегка “подправить” систему.

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

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

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

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

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

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

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

Дайте программе память

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проверка на пользователях

Половина процесса разработки - это анализ и создание; вторая половина - получение обратной связи, и применение полученной информации.

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

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

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

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