Проблемы немодальных диалоговых окон

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

Чаще всего путаница возникает потому, что с поведением модальных диалоговых окон пользователи знакомы очень хорошо. Модальное окно

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

Более совершенные немодальные диалоговые окна: два решения

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

Паллиативный подход

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

Визуально выделяйте различия между модальными и не- модальными диалоговыми окнами.

Если для создания немодального диалогового окна программист ис' пользует стандартные средства интерфейса прикладного программи' рования (API) Windows, в результате получится окно, которое визу' ально не отличается от модального. Мы должны сломать эту привыч' ку. Проектировщик обязан обеспечить четкие визуальные отличия не' модальных диалоговых окон – окрасить фон в другой цвет, сделать визуально отличными элементы управления или использовать другой цвет заголовка либо пиктограммы. Неважно, какой метод вы выбере' те, – важно, чтобы вы неукоснительно его придерживались.

Второй принцип гласит, что мы должны установить правильные и не' противоречивые соглашения по оформлению терминальных команд. Порой возникает ощущение, что каждый производитель, а то и каж' дый программист использует свою собственную методику для каждого диалогового окна. Эту какофонию подходов трудно оправдать. Некото' рые окна предлагают кнопку Закрыть, другие – Применить, третьи – Гото− во, Отклонить, Принять, Да и даже OK. Разнообразие вариантов бесконеч' но. Существуют и такие, которые вообще обходятся без подобных кно' пок и полагаются только на кнопку закрытия, расположенную в пра' вом верхнем углу окна. Завершение немодального диалогового окна должно быть простой, легкой в освоении, непротиворечивой, пусть не везде одинаковой, но по меньшей мере узнаваемой в большинстве про' грамм идиомой.

Используйте единообразные терминальные команды внутри немодальных диалоговых окон.

Одна из самых больших неприятностей заключается в изменении над' писей на терминальных кнопках, например изменение надписи Отмена на Применить или Закрыть в зависимости от того, предпринимал ли поль' зователь какие'либо действия в немодальном диалоговом окне. Такое динамическое изменение надписей в лучшем случае дезориентирует и трудно поддается интерпретации, в худшем – пугает своей непонят' ностью. Эти надписи никогда не должны изменяться. Если пользова' тель не выбрал ничего внутри диалогового окна, но все же нажимает на кнопку OK, диалоговое окно должно считать, что пользователь ве' лел «закрыть окно и не предпринимать никаких действий», посколь' ку по сути именно это пользователь и сделал. Модальные диалоговые окна предоставляют нам возможность явным образом отменить произ' веденные действия – с помощью кнопки Отмена. В немодальных диало' говых окнах обычно не удается использовать эту прямую идиому и приходится прибегать к функции отмены – так что изменение под' писей с целью предупредить пользователей еще больше запутывает си' туацию.

Не допускайте динамического изменения надписей на тер- минальных кнопках.

Когнитивная сила модальных диалоговых окон состоит в жесткой од' нозначности кнопок OK и Отмена. В них кнопка OK означает: «Принять мой ввод и закрыть окно». Проблема в том, что для немодальных диа' логовых окон не существует эквивалентного действия. Элементы управления в немодальном диалоговом окне постоянно активны, и эк' вивалентное понятие очень сложно сформулировать. Пользователь не связывает произведенные изменения с нажатием на кнопку Выполнить,

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

Единственная непротиворечивая терминальная команда для немо' дальных диалоговых окон – кнопка Закрыть. Любое немодальное диа' логовое окно должно иметь кнопку Закрыть на одном и том же месте – например в правом нижнем углу. Это правило должно неукоснительно соблюдаться от окна к окну: кнопка должна находиться на одном и том же месте и иметь одну и ту же надпись. Эту кнопку нельзя деак' тивировать. Более того, если кнопка Закрыть приводит к выполнению какой'либо функции в дополнение к закрытию окна, вы по сути созда' ли модальное диалоговое окно, которое должно следовать правилам построения модальных диалоговых окон.

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

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

Эволюционный подход

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

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

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

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

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

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

По мере того как число палитр растет, возникает потребность создать для них стандартный ареал обитания. Adobe Fireworks MX и прочие приложения, изначально созданные компанией Macromedia, одними из первых реализовали более удачную парковочную инфраструктуру, минимизирующую интерфейсные налоги на управление объектами на экране (рис. 24.1). Последние версии Photoshop подхватили данную идиому.

Последним шагом в эволюции этой новой немодальной командной идиомы стало появление панели задач(task bar), или боковой панели(sidebar), то есть панели окна приложения, предназначенной для орга' низации доступа к функциям, которые раньше были доступны посред' ством диалоговых окон. Созданное Autodesk приложение 3ds Max ста' ло одним из первых потребителей этой идиомы, позволив регулиро' вать параметры объектов немодально – через боковую панель. Среди

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

популярных приложений, применяющих боковые панели, – Провод' ник Microsoft Windows и Internet Explorer, где применяются так на' зываемые Explorer Bars, броузер Mozilla Firefox (Slide Bar), приложе' ния iLife от Apple (Inspectors), а также Microsoft Office (Task Pane). Пожалуй, наиболее искренне приняла идиому боковых панелей Adobe Lightroom – практически вся функциональность этого приложения доступна немодально через боковые панели (рис. 24.2).

Боковые панели в качестве идиомы обладают большим потенциалом – они фигурируют во многих решениях компании Cooper, и их примене' ние отнюдь не ограничивается боковыми сторонами экрана. Часто применяемый шаблон – специальная область свойств под панелью до' кумента или рабочей областью. Она дает немодальный доступ к функ' циям изменения свойств выбранного объекта, минимизируя путаницу и интерфейсные налоги на управление экраном (рис. 24.3). Эту идио'

Рис. 24.2. Боковые панели в Adobe Lightroom заменяют десятки диалоговых окон. Этот подход похож на вариант с палитрами, представленный

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

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

Рис. 24.3. Это решение создано компанией Cooper для системы управления отношениями с клиентами (CRM – customer relationship management). Когда пользователь выбирает объект в рабочей области (верхняя часть экрана, слева), свойства объекта отображаются внизу. Тем самым пользователь сохраняет контекст и избавлен от интерфейсных налогов, связанных

с управлением экраном