Вращение объектов; движение, вращение, наезд камеры

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

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

 

Связывание объектов

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

Связывание объектов 475

Если вы применяете средства управления проектами или построения организационных диаграмм, вы, несомненно, знакомы с этой идио' мой. Например, чтобы соединить одно задание с другим на сетевой диа' грамме (называемой также PERT'схемой1) в программе управления проектом, вы щелкаете и протягиваете между ними стрелку. В этом случае направление стрелки имеет значение: задание, на котором была нажата кнопки мыши, является источником, а задание, на котором кнопка мыши отпущена, – приемником.

Когда пользователь связывает два объекта, процесс сопровождается визуальной обратной связью в виде резиновой нити: стрелка образует линию, которая протягивается от точки щелчка до текущего положе' ния курсора мыши. Линия анимирована, один ее конец следует за ука' зателем мыши, а второй закреплен в точке щелчка. Когда курсор про' ходит над кандидатами для связывания, курсорная подсказка должна сообщать о том, что объекты можно соединить. Когда пользователь от' пускает кнопку мыши над корректной целью, программа проводит стрелку от одного объекта к другому. В некоторых программах объек' ты при этом дополнительно связываются логически. Как и в случае пе' ретаскивания объектов с одного места на другое, крайне важно обеспе' чить удобную функцию отмены – скажем, привязать эту функцию к клавише <Esc> или аккордному щелчку.

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

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

 

1 PERT, Program Evaluation and Review Technique (буквально: техника оцен' ки и анализа программ) – вид диаграмм, используемых для составления плана проекта, оценки времени его выполнения и пересмотра. – Примеч. ред.

Поведение окон

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

 

PARC и Alto

Все современные графические пользовательские интерфейсы унасле' довали свой внешний вид от Xerox Alto – экспериментальной компью' терной системы для настольных компьютеров, разработанной в сере' дине 1970'х годов в исследовательском центре компании Xerox в Пало Альто (PARC – Palo Alto Research Center), ныне PARC, Inc. Компью' тер Alto, созданный в PARC, был первым компьютером с графическим интерфейсом. Его создали для того, чтобы исследовать возможности применения компьютеров в качестве настольных бизнес'систем. Alto был спроектирован как сетевая офисная система, позволяющая созда' вать документы, редактировать и просматривать их в режиме WYSI' WYG (what you see is what you get – «что видите, то и получаете»), хра' нить, искать, передавать между рабочими станциями в электронном виде и печатать. Мир персональных компьютеров получил в подарок от системы Alto множество важных нововведений, которые ныне яв' ляются общепринятыми: мышь, прямоугольное окно, полоса прокрут' ки, кнопка, метафора «рабочего стола», объектно'ориентированное программирование, раскрывающиеся меню, стандарт локальной сети Ethernet и лазерная печать.

PARC и Alto 477

Трудно переоценить влияние лаборатории PARC на всю компьютер' ную индустрию и на то, как мы работаем с компьютерами сегодня. Как глава Apple Computer Стив Джобс, так и основатель Microsoft Билл Гейтс видели систему Alto в лаборатории PARC и получили незабывае' мые впечатления.

Компания Xerox предприняла самостоятельную попытку превратить в коммерческий продукт сначала Alto, а затем и последовавшую за ней компьютерную систему Star. Однако обе системы оказались дорогими, сложными, мучительно медленными и потерпели поражение. У мно' гих специалистов возникло чувство, что руководству корпорации Xe' rox, занимавшейся в то время главным образом копировальной техни' кой, не хватает дальновидности и находчивости для организации эф' фективной рекламы и продаж «безбумажных офисов». Когда стало по' нятно, что Xerox упустила эту сказочную возможность, в PARC началась утечка мозгов, изрядно обогатившая другие компьютерные компании, в частности Apple и Microsoft.

Стив Джобс с беженцами из PARC сразу же попытались создать копию Alto/Star в системе Lisa. Им это удалось во многих отношениях, вклю' чая даже неспособность Star отвечать требованиям реального мира. Lisa была замечательной, простой в использовании, восхитительной, слиш' ком дорогой (9995 долларов в 1983 году) и ужасно медленной. Несмот' ря на коммерческий провал эта система разбудила воображение многих людей в маленькой, но уже процветающей отрасли микрокомпьютеров.

В то же время Билл Гейтс был сильно впечатлен не столько привлека' тельной «графичностью» Alto/Star, сколько объектно'ориентирован' ной моделью представления и коммуникационной моделью. Этот стиль мышления нашел свое отражение в программном обеспечении, выпущенном компанией Microsoft в начале 1980'х, в первую очередь – в электронной таблице Multiplan (предшественнице Excel).

Стива Джобса не смутил провал компьютера Lisa. Он был убежден в своевременности идеи о полностью графическом персональном ком' пьютере, родившейся в PARC. Укрепив свою группу беженцев из PARC квалифицированными и энергичными сотрудниками из различ' ных подразделений Apple, он начал секретные разработки коммерче' ски жизнеспособного варианта Alto. Результатом этих усилий стал ле' гендарный Macintosh – машина, оказавшая глубочайшее влияние на наши технологии, дизайн и культуру. Mac единолично продемонстри' ровал всей компьютерной индустрии важность дизайна и эстетики. Он не только поднял планку дружелюбности программ к пользователю, но и открыл мир компьютеров целому слою профессионалов из раз' личных областей, преодолев зацикленность компьютерной индустрии на технологических безделушках.

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

 

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

 

Принципы PARC

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

Визуальные метафоры

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

Отказ от режимов

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

Так, например, старые программы требовали от пользователя пере' ключения в особый режим для ввода данных, а затем переключения в другой режим для их печати. Такие поведенческие состояния и назы' ваются режимами, и они способны очень сильно запутывать и раздра' жать пользователей. Ларри Теслер (Larry Tesler), бывший исследова' тель в PARC и ведущий научный сотрудник в Apple, стал одним из пер' вых сторонников отказа от режимов в программном обеспечении. На фотографии в одном влиятельном журнале он был запечатлен в футбол' ке с дерзкой надписью «Don’t mode me in» (Не режимьте меня). Над' пись на номерном знаке его машины гласила «NOMODES» (БЕЗ РЕ' ЖИМОВ). При работе с командной строкой режимы и в самом деле от' вратительны. Однако в мире графических пользовательских интер' фейсов, где царит порядок «объект – глагол», режимы не являются безоговорочно вредными, хотя плохо спроектированные режимы мо' гут чрезвычайно раздражать. К несчастью, принцип «не режимьте ме' ня» стал уже неотъемлемой частью языка проектировщиков.

Принципы PARC 479

Например, одной из программ для компьютеров Macintosh, оказав' ших большое влияние на индустрию, было приложение MacPaint, в интерфейсе которого режимы применялись весьма интенсивно. Эта программа давала пользователю возможность рисовать на экране пик' сел за пикселом. Пользователь выбирал инструмент из палитры, со' державшей около десятка инструментов, и затем рисовал этим инстру' ментом на экране. Выбор инструмента – это вход в режим, поскольку поведение программы определяется свойствами выбранного инстру' мента. В каждом режиме программа ведет себя строго определенным образом.

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

Перекрывающиеся окна

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

Существуют серьезные причины отображать данные внутри прямо' угольных рамок. Возможно, наименее существенная из этих причин – соответствие технологии производства дисплеев: ЭЛТ' и ЖК'дисплеям легче работать с прямоугольниками, чем с другими формами. Гораздо более важно то, что люди по большей части пользуются прямоуголь' ным форматом для вывода данных: текст размещают на прямоуголь' ных страницах со времен Гутенберга, и многие другие формы выраже' ния, такие как фотография, кино или видео, тоже соответствуют пря' моугольным сеткам. Прямоугольные графики и диаграммы являются самыми легкими для восприятия. Видимо, в прямоугольниках есть не' что, соответствующее человеческому разуму. Кроме того, прямоуголь' ники позволяют довольно эффективно использовать пространство.

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

 

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

Сама концепция перекрывающихся окон хороша, но ее исполнение в реальном мире непрактично. Метафора перекрывающихся листов бумаги перестает работать, как только на экране появляются три или более программ и документов, – она попросту не масштабируется. Есть у этой идиомы и другие проблемы. Если пользователь промахнет' ся мышью на пару пикселов, нужная ему программа может исчезнуть, уступив место другой. Пользовательское тестирование, проведенное компанией Microsoft, показало, что типичный пользователь может не' сколько раз запустить один и тот же текстовой редактор, ошибочно по' лагая, что он каким'то образом умудрился «потерять» программу и должен начать все сначала. Именно проблемы такого рода побудили Microsoft ввести в систему панель задач, а компанию Apple – приду' мать инструмент Expose, ставший привлекательным и удобным сред' ством для слежения за открытыми окнами (хотя отсутствие его инте' грации с приложениями, свернутыми в Dock, представляет собой ре' альную проблему).

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

 

Microsoft и окна плиткой

Следуя традиции обращать внимание на самые заметные аспекты но' вого графического пользовательского интерфейса лаборатории PARC, Билл Гейтс дал своему неряшливому, собранному впопыхах ответу на успех системы Macintosh название«Windows» (Окна).

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

Полноэкранные приложения 481

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

 

Полноэкранные приложения

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

Microsoft стойко выдержала двойной судебный процесс против Apple – нарушение контракта и нарушение патентных соглашений, – чтобы иметь возможность добавить технологию перекрывающихся окон в Windows 2.0. Похоже, что в пылу сражений была забыта главная проблема: как облегчить навигацию пользователя между приложе' ниями? Множество окон, разделяющих маленький экран – перекры' вающихся либо уложенных плиткой, – не очень удачное решение в об' щем случае (хотя и бывает полезным в определенных ситуациях). Мы быстро движемся в мир полноэкранных программ. Каждое приложе' ние занимает весь экран, когда оно активно. Инструменты вроде пане' ли задач отнимают минимум пикселов у активных приложений, что' бы обеспечить наглядный способ переключения между задачами. (За' бавно, но похожая концепция использовалась на заре существования Macintosh в специальной программе Switcher, которая применялась для переключения между несколькими полноэкранными приложе' ниями.) Такое решение гораздо лучше сберегает пикселы, не так силь' но путает пользователей и лучше подходит для тех случаев, когда при' ложение используется продолжительное время. В операционных сис' темах Mac OS X, Windows XP или Vista у пользователей есть выбор: разворачивать приложения на весь экран или работать в режиме пере' крывающихся окон.

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

 

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

 

Многопанельные приложения

Оказывается, все же существует идиома, привносящая в монопольные полноэкранные приложения лучшее из плиточного расположения окон, – это идиома многопанельных окон. Многопанельные окна со' стоят из независимых представлений, или панелей, соседствующих внутри одного окна. Смежные панели разделяются с помощью закреп' ленных или подвижных разделителей. (Мы обсудим разделители бо' лее подробно в главе 21.) Классическим примером многопанельного приложения является Microsoft Outlook, в котором для показа на од' ном экране списка почтовых ящиков, содержимого выбранного ящика и выбранного письма используются различные панели (рис. 20.1).

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

Смежные панели нашли применение и в Интернете в форме так назы' ваемых фреймов, однако вследствие неудачной изначальной реализа' ции и войны стандартов между гигантами Netscape и Microsoft фрей' мы так и остались сложными и неуклюжими. Хочется верить, что с развитием веб'технологий и распространением высокоинтерактив' ных веб'приложений концепция, стоящая за фреймами, снова найдет применение в броузерах (сами'то броузеры уже используют панели). Существующие сегодня в Интернете клиентские технологии (AJAX и Flash) уже позволяют в определенной степени реализовать поведе' ние с применением панелей.

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

 

 

 

Рис. 20.1. Microsoft Outlook 2007 – классический пример многопанельного приложения. Крайняя левая панель содержит перечень почтовых ящиков, а также позволяет переключаться между почтой и календарем; в верхней

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

Microsoft Excel, который использует стопки панелей для организации своих «листов», позволяя обращаться к нескольким связанным между собой таблицам посредством перевернутых вкладок в нижней части экрана.

 

Проектирование окон

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

Лишние комнаты

Если мы представим наше приложение в виде дома, то каждое окно – это отдельная комната. Сам дом будет представлен главным окном программы, а каждая комната – это окно документа, диалоговое окно или панель. Мы не пристраиваем к нашему дому комнату, если у нее

 

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

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

 

Диалоговое окно – это еще одна комната; не ходите в ком- нату без веской причины.

 

 

К примеру, чтобы изменить яркость и контраст фотографии в Adobe Photoshop, нужно открыть меню Image (Изображение), выбрать подме' ню Adjustments (Коррекция), а затем выполнить команду Brightness/Con− trast (Яркость/Контрастность). Откроется диалоговое окно, где можно выполнить коррекцию (рис. 20.2). Подобная последовательность дей'

 

Рис. 20.2. Одна из многих «комнат» Adobe Photoshop: Brightness/Contrast (Яркость/Контрастность). Мы настолько привыкли к необходимости вызывать диалоговое окно, чтобы выполнить простую функцию, что уже не замечаем этого. Однако такой подход заставляет пользователя делать лишнюю работу; к тому же диалоговое окно перекрывает собой самый важный объект на экране – собственно изображение

ствий настолько распространена, что мы даже не замечаем ее, – и все же это несомненно плохое решение.

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

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

Ситуация значительно улучшилась в программе Adobe Lightroom. При' ложение разделено на представления, или «комнаты». Каждая «ком' ната» имеет специфическое назначение: Library (Библиотека), Develop (Проявка), Slideshow (Слайд'шоу), Print (Печать) и Web (Веб). В комнате Develop управление яркостью и контрастом представлено в панели справа от главного окна наряду со всеми прочими инструментами кор' рекции изображений, какие только можно себе вообразить (рис. 20.3).

 

Встраивайте функции в то окно, где они применяются.

 

 

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

 

 

 

Рис. 20.3. Adobe Lightroom – существенный шаг вперед в сравнении с Photo- shop. Принципиально важные инструменты сгруппированы по назначению

и представлены прямо в главном окне, рядом с редактируемым изображением

Жизненно важные комнаты

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

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

 

ревести пользователя для выполнения этой функции в отдельную

«комнату» – либо окно, либо диалоговое окно.

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

Например, Corel Painter размещает инструменты художника на спе' циальной панели и позволяет перемещать их так, чтобы самые нуж' ные находились в максимальной доступности. Панели и палитры можно скрывать, но по умолчанию они включены и являются частью главного окна рисования. Их можно располагать где угодно в преде' лах окна. Если вы создадите тонкую угольную кисть конкретного красного оттенка, которую вам нужно будет многократно использо' вать, просто «оторвите» ее от палитры и поместите где угодно в рабо' чей области – прямо как на настоящем мольберте. Этот способ выбора инструментов имитирует действия художника в реальном мире.

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

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

 

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

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

Замусоривание окнами

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

Решение многих пользовательских задач требует выполнения после' довательности действий. Если для каждого действия открывается от' дельное диалоговое окно, то экран вскоре визуально перегружается, а навигация усложняется. Программа CompuServe Navigator (рис. 20.4) служит иллюстрацией именно такой ситуации.

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

 

Полезность любой идиомы взаимодействия зависит от кон- текста.

 

 

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

 

 

Рис. 20.4. Версия 1.0 программы CompuServe Navigator серьезно страдала от мусорных окон. Обычная загрузка электронной почты требовала открытия трех окон. Для прочтения сохраненного письма нужно было открыть еще три. Просмотр почты является целостной деятельностью – и вся эта деятель- ность должна происходить в одном интегрированном окне. Однако худшее еще впереди: пользователям приходилось закрывать каждое из этих окон по от- дельности – в порядке, противоположном тому, в котором они были открыты

полнен в форме самостоятельного окна либо отдельного диалогового окна, поскольку это проще, нежели пытаться аккуратно согласовать их по факту создания. Перед нами во всей красе предстает классиче' ская модель реализации. Этот пример присутствовал уже в первом из' дании нашей книги, вышедшей в 1995 году; нам очень хотелось бы сказать, что положение дел с тех пор заметно улучшилось. Однако до' статочно лишь бросить взгляд на современный интерфейс America On' line, чтобы понять: с тех пор мало что изменилось. Компания AO