Лрввктироваииа пс1Л*.зовнтоль(жого и терфе1Ю8

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

В большинстве систем есть формы, соответствующие основным сущностям этой системы: например, формы Customers (Покупатели). /га/нс/5(Продукты) и Saks Orders (Счета-фактуры). Вам нужно определить, каким образом пользователи будут выбирать ную им запись из набора. Я рекомендую разработать единые правила выбора записей и перехода loii записи к другой, использовать их во всех формах и без крайней необходимости не нарушать.

По умолчанию в свя:шнных формах Access и Visual Basic выбира ется первая запись из нижележащего набора. Форма также содержит кнопки, позволяющие перемещаться от одной записи набора к другой. Однако но разным причинам вам может понадобиться отказаться от этих стандартных свойств интерфейса. Например, чтобы в форме отображалась всего одна и были предусмотрены механизмы, позволяющие выбрать записи, которые следует отобразить. Таким механизмом может быть отдельная форма для поиска записи или комбинированное окно, позволяющее выбрать нужную запись. На рис. 12-3 показан пример, заимствованный из стандартной базы данных Access Developer Solutions и иллюстрирующий этот подход. В нем возможность выбрать нужную запись реализована при комбинированного окна Edit Products.

Uniii, III ъ\ал Г

л i

Рис. 12-3. Пользователи могут выбрать тись о клиенте

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

ЧАСТЬ 3

ГЛАВА 1 рфейс ка ад яодмаеатеяей и системой

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

механизм во всех формах системы. Согласитесь, неудобно работать с

системой, где перемещение между записями в форме Customers (Покупатели) реализовано при помоши стандартных кнопок; в форме Sales Order (Счет-фактура) для выбора нужной записи требуется щелкнуть кнопку Find Order (Найти заказ): а в форме Products (Товары) - данные представлены в табличном виде.

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

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

щаются в строки, представлены в виде табличном виде, а адрес и телефон в виде списка - это непоследовательно.

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

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

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

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

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

Итоги

В этой главе мы познакомились с основными ипами, лежащими в основе проектирования пользовательского интерфейса. Мы начали обзор методов проектирования с рассказа о моделЯ)с пользовательского интерфейса: ментальной модели пользователя (представлений

пользователя о системе и о том, как она работает), модели реализации

(того, что реально происходит в системе) и декларируемой модели

(того, что система сообщает пользователю о происходящем процессе).

Затем были рассмотрены различные уровни подготовки нользова-телей: пользователь, опытный пользователь и эксперт.

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

Заключительная часть главы была посвящена принципам, лежащим в основе проектирования пользовательского интерфейса: ответственности пользователя за его действия, уменьшение объема информации, которую пользователь должен запоминать; согласованность

интерфейса.

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