Видимость состояния системы (правило обратной связи)

Видимость состояния системы (правило обратной связи)

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

Информированность пользователя

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

Средства обеспечения обратной связи

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

Информация, при рассмотрении данного вопроса, делится на типы в зависимости от ее назначения и степени важности. Например, сообщения о критических ошибках, приводящих к невозможности продолжения работы, обычно выводятся в отдельном диалоговом окне. При этом работа приложения останавливается до тех пор, пока пользователь не закроет окно с информацией об ошибке (так называемое модальное окно), а сообщения о незначительных ошибках — в статусной строке окна приложения без остановки его работы. Характерен пример браузера Microsoft Explorer: если открыть запрашиваемую Web-страницу в данный момент невозможно (например, отсутствует соединение с Интернетом), то на экране появляется модальное окно с сообщением о критической ошибке. Если же страница была успешно загружена, но при этом возникли незначительные ошибки, то соответствующее сообщение отображается в строке состояния программы.

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

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

Помимо текстовых сообщений, выводящихся в окне программы, для организации обратной связи могут быть использованы и другие средства. Самое популярное из них — звук. Звуковое оповещение может быть полезным в самых различных ситуациях'. Наиболее часто звук помогает тогда, когда появление на экране модальных окон нежелательно, а сообщения в статусной строке могут быть lie замечены (например, если главное окно программы, как таковое, отсутствует). Это является типичным, например, для утилит, периодически проверяющих e-mail-ящики на наличие свежей почты. Другое полезное применение звука — оповещение пользователя, находящегося не за компьютером, а где-то поблизости. Также звуковое сопровождение окажет помощь пользователям с ограниченными возможностями (например, с плохим зрением).

Важно помнить, что звуковое оповещение не должно быть основным средством организации обратной связи. Звук должен лишь дополнять текстовые сообщения. Иначе пользователь может пропустить сообщение — ведь на компьютере может отсутствовать звуковая карта или звук может быть отключен. Таким образом, исчезнет единственное средство организации обратной связи, и работа с программой станет очень неудобной или вообще невозможной. Интересно, что эта особенность интерфейса специально используется некоторыми shareware-авторами для стимуляции пользователей оплачивать регистрации. Например, в незарегистрированной версии программы получения сообщений по сетиVypress Auvis (http: //www.vypress.com) оповещение о приходящих сообщениях с помощью всплывающих окон отключено — до регистрации можно пользоваться только звуковым оповещением. Как следствие, работа с программой становится очень некомфортной, т. к. основная область ее применения — локальные офисные сети, где количество компьютеров, не оснащенных звуковыми картами, довольно велико.

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

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

Время оповещения

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

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

Предупреждение ошибок

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

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

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

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

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

Описание ошибки

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

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

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

Замечание

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

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

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

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

Описание решения проблемы

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

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

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

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

Справка и документация

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

Видимость состояния системы (правило обратной связи)

12 Следующая ⇒