Диалоговые окна уведомлений: сообщение об очевидном

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

Уведомления обычно нарушают один из базовых принципов проекти' рования: диалоговое окно – это еще одна комната; не ходите в комна-

Диалоговые окна уведомлений: сообщение об очевидном603

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

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

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

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

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

Рис. 25.4. Типичное диалоговое окно с уведомлением. Оно является ненужным, неуместным и прерывает поток взаимодействия из-за ерунды.

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

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

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

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

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

Синхронизация завершена

Рис. 25.5. Это окно из AirSet Desktop Sync излишне угодливо. Мы попросили выполнить синхронизацию – и наша работа тут же прервана вот этим чрезвычайно важным сообщением. Да, прекрасно, что программе удалось- таки справиться со своей работой, но зачем нас-то отвлекать?Видимо для того, чтобы у нас была возможность признать ее заслуги

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