Windows с маленькой буквы w

Аlan Cooper

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

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

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

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

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

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

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

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

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

Если мы собираемся идти купаться, вам покажется странным, если я предложу вам переодеться в комнате, полной народу. Приличие и скромность – вот две причины, по которым для переодевания вы пойдете в отдельную комнату. Если отдельная комната действительно необходима, не предоставлять ее было бы неуместно.

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

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

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

Когда пользователь закончил создание рисунка, он достиг своей начальной цели. В этом месте его цели меняются. Его новая цель – сохранить ее и показать кому-то другому. Нужды в карандашах и резинках больше нет. Нужды в готовых картинках тоже нет. Художник бы в этом месте открепил лист от стола, перешел в другую комнату, покрыл его фиксирующим раствором, свернул и положил в тубус (mailing tube). Он неслучайно оставляет свои инструменты для рисования на столе – он не хочет, чтобы на них попал фиксатор, или краска случайно испортила картину. Тубусы используются редко, поэтому они хранятся в шкафу. В программном эквиваленте этого процесса, пользователь временно оставляет программу рисования вместе со всеми инструментами, находит подходящее место на диске, чтобы сохранить изображение, после чего, возможно, посылает его по электронной почте.

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

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

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

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

Каждое новое окно увеличивает необходимость лишних манипуляций с окнами. Если же программа используется ежедневно, это может перерасти в серьезную проблему. Если в вашей программе дюжина окон, потому что вы честно верите в то, что каждое из них приближает пользователя к нескольким различным целям, то вы должны разбить ее на несколько маленьких программ, и пусть каждая служит для достижения своей цели. У программы не может быть больше двух-трех целей, а значит, у неё не должно быть больше двух или трех окон.

Один программист на Visual Basic однажды с гордостью заявил мне, что его программу было особенно тяжело разрабатывать, потому что в ней содержится 57 форм. Ни одну программу с 57 формами нельзя использовать эффективно! Каждая форма может быть превосходной сама по себе, но все вместе это просто слишком много.

Вернуться к списку статей