Архитектура

пользовательского

интерфейса

ГЛАВА

При проектировании пользовательского интерфейса следует в самом начале принять решение об общей структуре интерфейса системы - другими словами, об архитектуре пользовательского интерфейса. В этой главе мы рассмотрим несколько стандартных архитектур, полное описание которых содержится в руководства he Windows Interface Guidelines for Software Design* ( Руководство no разработке интерфейса для Все эти варианты стандартных архитектур реализованы в распространенных программных продуктах.

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

работают пользователи, это существенно облегчает их работу.

Поддержка рабочих процессов

Выбор архитектуры интерфейса должен быть обусловлен рабочими

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

Вот пример одной из наиболее распространенных ошибок разработчиков. Увидев на диаграмме сущности - связи сущность Customers (Покупатели), они создают форму с тем же названием, предназначенную для ввода и редактирования записей о пользователях.

ЧАСТЬ 3 а пользовательского интерфейса

Затем создается форма Orders (Заказы) зуюшая данные из таблицы Customers, доступной из этой формы только для чтения. Чтобы сделать систему дружественной пользователю*, разработчики предоставляют пользователю возможность выбрать фамилию покупателя из списка. Затем пользователь должен ввести информацию в остальные поля формы, основываясь на данных таблицы Customers. То что получается, напоминает форму из базы данных .Northwind (рис. 13-1).

Рис. 13-1. Форма Orders из базы данн1х Northwind

Эта форма сама но себе не плоха и не хороша, но с точки зрения поддержки рабочих процессов она не оптимальна. Подумайте о гом, что делает пользователь, который [шздит информацию в бланк заказа. Он открывает форму Orders, только чтобы убедиться, что покупатель, информацию о котором он будет вводить, еще не зарегистрирован в системе. Затем ему нужно закрыть эту форму, чтобы открыть какую-то другую и ввести данные о новом покупателе, и только потом он сможет ввести информацию о заказе. Если форма Orders еще не закрыта, пользователю понадобится обновить список Customers (Покупатели), нажав клавиши 5111Л+Р9(или какое-либо другое сочетание), чтобы в этом списке отображались данные о новом покупателе. Неудобно.

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

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

ГЛАВА 1 льзозательскйго интерфейса

вынужден прерывать выполнение одной данных о

заказе) и выполнять другие (обновление списка покупате-

лей). Значительно лучше позволить пользователю сначала завершить выполнение одной а потом уже к Напри-

мер, так: если введет имя покупателя, отсутствующее в

списке, все поля формы остаются незаполненными; если же такое имя уже есть в списке, в полях отображается ин-

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

Если форма Orders позволяет ввести всю информацию, которую

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

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

зами список вопросов, которые он должен задать покупателю,

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