Современный графический пользовательский интерфейс был изобретен в середине 70-х в исследовательском центре Xerox PARC (Palo Alto Research Center). В том виде, как его создали разработчики фирмы Xerox, интерфейс состоял из многих элементов — окон, кнопок, мышей, пиктограмм, визуальных метафор и раскрывающихся меню. Все вместе они сформировали незыблемую основу для последующих разработок в области проектирования интерфейсов, поскольку этот ансамбль доказал свое превосходство на практике.
Первой коммерчески удачной реализацией пользовательского интерфейса PARC стал компьютер Apple Macintosh с его метафорой рабочего стола: корзина для мусора, перекрывающиеся листы бумаги (окна) и папки с файлами. Успех пришел к Macintosh не благодаря этим метафорам, а по ряду других причин, в число которых входило внимательное отношение к дизайну и деталям. Вот те удачные решения проектировщиков, которые работали на успех системы:
- Весьма ограниченный, но гибкий лексикон пользовательского взаимодействия с приложениями, основанный на очень простом наборе операций с мышью.
- Возможность сложных непосредственных манипуляций с информационно насыщенными объектами на экране.
- Использование высокого разрешения с квадратными пикселами, которое позволило приблизить экранное изображение к распечатке на бумаге, особенно в связи с появлением нового продукта фирмы Apple - лазерного принтера.
Метафоры позволили структурировать эти важные интерфейсные решения и явились удачным маркетинговым ходом, но никак не главной причиной успеха. В действительности первые годы были для Macintosh довольно трудными, поскольку пользователям требовалось время, чтобы привыкнуть к новому, визуальному способу общения с компьютером. Производители программного обеспечения тоже поначалу побаивались разрабатывать программы для такого радикально иного окружения (фирма Microsoft была исключением).
Впрочем, люди в конце концов сдались: ведь эта система могла делать то, что другим системам было не под силу, - представлять информацию на экране методом WYSIWYG (what you see is what you get - «что видишь, то и получишь»). Сочетание наглядных интерфейсов с высококачественной печатью (на принтерах LaserWriter) создало совершенно новый рынок, на котором Apple с Macintosh доминировала много лет. Метафора в успехе Macintosh была несущественным фактором.
Из всех заблуждений, порожденных центром Xerox PARC, миф о глобальной метафоре является самым печальным и разрушительным.
Сообщения об ошибках
Как указывает крупнейший авторитет в области юзабилити Дональд Норман, пользователи часто винят себя в ошибках, которые допустили проектировщики продукта. Если вы не получаете жалоб от пользователей, это еще не означает, что они радуются, когда получают сообщения об ошибках.
Диагностические сообщения, выдаваемые системой и обработка ошибок – область особого внимания разработчика. Сообщения об ошибках неизбежно прерывают работу модальными диалоговыми окнами.
Модальное окно – это всплывающее окно, отображающее или запрашивающее информацию. Модальные окна могут содержать информацию, дополняющую информацию основного окна.. Модальное окно поддерживает действия, которые пользователь обязательно должен выполнить перед закрытием окна. Модальное окно требует, чтобы пользователь закончил нужное действие перед возвратом в точку, из которой оно было вызвано (например, сохранение результатов редактирования в файле и продолжение редактирования).
Модальное окно бывает прикладным или системным. Прикладное окно позволяет пользователю работать с окнами, которые управляются другими программами, не закрывая данного заблокированного окна. Системное модальное диалоговое окно останавливает выполнение программ во всех окнах, до тех пор, пока оно не будет закрыто. Отображая модальные диалоговые окна, следует иметь в виду, что не рекомендуется делать их размеры слишком большими. Умеренные размеры предоставляют достаточно места для размещения диалога, и в то же время окна не занимают слишком большую долю экрана.
Как правило, ошибки возникают из-за некорректного ввода данных пользователем. Условно ошибки можно разделить на 3 класса:
1. Система выходит из строя. Здесь явный просчет разработчика, который не обеспечил входной контроль и устойчивость программы к различным наборам исходных данных. В результате система выполняет некорректные операции.
2. Система обнаруживает невозможность дальнейшей обработки полученных ею данных и просит пользователя скорректировать их. Вводится синтаксически верная, но логически противоречивая информация. Требования пользователя неосуществимы.
3. Система выполняет задачу, но результат отличается от того, который ожидал пользователь, например, работа со старыми версиями файлов.
Сообщения об ошибках обладают следующими недостатками: раздражение пользователя, внушение ему чувства вины, отвлечение его от работы и, как правило, отсутствие каких-либо инструкций о том, что делать в сложившейся ситуации и еще хуже – принятие решения в ситуации, совершенно незнакомой для пользователя. Сообщение об ошибке должно отвечать на три вопроса:
1. В чем заключается ошибка?
2. Как исправить проблему сейчас?
3. Как сделать так, чтобы ошибка не повторилась?
Текст сообщения должен быть изложен в терминах пользователя быть по возможности коротким. Сообщение должно точно объяснять в чем заключается ошибка и какие действия надо предпринять, чтобы ее устранить, а не ограничиваться общими фразами вида: "Вы ошиблись", "Ошибка" или кодами ошибок "Ошибка 27". Важно, чтобы сообщение об ошибке появлялось близко к тому месту, где был фокус внимания пользователя, само сообщение не должно закрывать место ошибки или ошибочные данные должны включаться в текст сообщения об ошибке. Появление диагностического сообщения в другом месте раздваивает фокус внимания и создает психологический дискомфорт. По этой причине в Windows, например, после запуска процесса песочные часы появляются там, где находился курсор.
Диалоговое окно с сообщением об ошибке должно быть вежливым, информативным, действенным. Никогда не забывайте, что сообщение об ошибке свидетельствует о неспособности программы выполнить свою работу и отвлекает пользователя от выполнения его работы. Сообщение об ошибке должно быть исключительно вежливым.
Окно с сообщением об ошибке должно всесторонне охарактеризовать проблему. Иными словами, столкнувшись с проблемой, программа должна предоставить пользователю информацию, которая необходима для принятия решения по устранению этой проблемы. Следует четко описать проблему, возможные варианты решения, действия, которые предпримет программа по умолчанию, и сообщить, утрачены ли данные, и если да, то какие именно.
Однако было бы неправильно со стороны программы полностью переложить проблему на плечи пользователя и умыть после этого руки. Она обязана предложить как минимум одно решение здесь же, в диалоговом окне. Окно должно содержать кнопки, позволяющие справиться с проблемой тем или иным способом. Если, скажем, недоступен принтер, диалоговое окно должно предложить возможность подключить другой принтер или отложить печать.
Чтобы избавиться от сообщения об ошибке, мы должны снизить вероятность совершения этой ошибки пользователем. Сделать так, чтобы пользователь не мог ошибиться, – лучший способ избавиться от сообщений об ошибках. С помощью ограничивающих элементов ввода, таких как счетчики и раскрывающиеся списки, можно лишить пользователей возможности вводить ошибочные числа. Вместо того чтобы заставлять пользователя вводить информацию с клавиатуры, предоставьте ему список, из которого он будет выбирать.
Другой превосходный способ избавиться от сообщений об ошибках – сделать программу достаточно сообразительной, чтобы она не требовала лишнего. Многие сообщения об ошибках имеют такой вид: «Неправильный ввод. Пользователь должен ввести ХХХХ». Если программа знает, что именно должен ввести пользователь, почему бы ей не ввести это самой, перестав трепаться попусту? Вместо того чтобы требовать от пользователя ввести имя файла и давать ему возможность ошибиться, заставьте программу запомнить, с какими файлами он работал раньше, и выведите их список. Еще один пример: сделайте так, чтобы программа получала дату от системных часов, а не требовала ее пользователя.
Одной из проблем сообщений об ошибках является то, что они уведомляют о неприятностях по факту. Они говорят: «Случилось нечто плохое, и все, что вы можете сделать, – признать катастрофу». Полезность таких сообщений сомнительна. И все эти диалоговые окна снабжены кнопкой ОК, требующей от пользователя стать соучастником преступления.
Чтобы сделать ошибки невозможными, разработчик может пойти двумя путями. Либо лишить пользователя возможности выполнить некорректную операцию в данном режиме, либо отключить ресурс, использование которого может привести к ошибке. Например, при работе с защищенным от записи диском заблокировать возможность писать на этот диск либо защищенные диски вообще не показывать пользователю, что делает ошибку невозможной.
Уведомление сообщает пользователю о действии, предпринятом программой, а подтверждение, кроме того, дает пользователю полномочия отменить это действие.
Идея уведомлений – в том, чтобы информировать пользователя. Это замечательная цель, но нельзя достигать ее ценой разрушения плавного потока взаимодействия.
Диалоговые окна с уведомлениями столь распространены потому, что их легко создавать. Уведомления обычно нарушают один из базовых принципов проектирования: диалоговое окно – это еще одна комната; не ходите в комнату без веской причины (глава 20). Даже если пользователя необходимо проинформировать о предпринятом программой действии, зачем для этого ходить в другую комнату?
Сообщения, подтверждающие какие-либо действия системы, требуются для того, чтобы пользователь мог еще раз убедиться в том, что система выполнила или будет выполнять требуемое действие. Хотя такие сообщения существенны, использовать их следует не очень часто.
 |
Когда приложение не чувствует уверенности в своих действиях, оно нередко просит у пользователя одобрения и выдает диалоговое окно, подобное показанному на рис. Deductor
Иногда такое подтверждение предлагается пользователю потому, что программа сомневается в его действиях. В других случаях программа чувствует себя недостаточно компетентной для принятия решения и предлагает пользователю сделать выбор. Окна подтверждений всегда появляются по инициативе программы и никогда – по инициативе пользователя. Это означает, что они часто не связаны с целями пользователя и являются отражением модели реализации.
Демонстрация модели реализации перед пользователями – верный способ создать неприятный и некачественный продукт. Это означает, что диалоговые окна подтверждений неуместны. Они возникают в коде программы тогда, когда программист заходит в тупик. Обычно это случается, если программе требуется принять решительные меры, а программист чувствует, что не может взять на себя ответственность за них. Иногда эти решительные меры связаны с каким-то условием, которое распознала программа, но чаще они определяются действиями пользователя. Как правило, диалоговое окно подтверждения появляется тогда, когда исполняемая команда либо необратима, либо может привести к нежелательным последствиям.
Подтверждения перекладывают ответственность на плечи пользователя. Пользователь доверил приложению работу – и оно должно не просто выполнить ее, но выполнить как следует. Правильное решение – сделать действие легко обратимым и обеспечить достаточно понятную немодальную обратную связь, чтобы неприятности не заставали пользователя врасплох.
В заключение можно привести слова крупнейшего на сегодняшний день американского специалиста по интерфейсам Алана Купера: «Без сомнения, все эти решения потребуют от программистов большей работы. Это нисколько меня не волнует. Я не хочу, чтобы программисты больше работали, но, выбирая из сложности работы программистов и сложности работы пользователей, я немедленно заставляю программистов работать. Работа программиста - удовлетворить пользователя, а не наоборот ».