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

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

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

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

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

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

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

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

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

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

Необходимые комнаты

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

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

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

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

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

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

Загрязнение окнами

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

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

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

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

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

Автор: Аlan Cooper