|
Программирование >> Проектирование баз данных
Навигация Удобство при перемещении по экранным формам и доступе к функциям, обеспечиваемое системой, может быть решающим фактором ее успеха. Если пользователям приходится проходить мучительный путь, чтобы попасть из одной экранной формы в другую, вводить данные несколько раз или при переходе из одного диалогового окна в другое запоминать код либо элемент информации, то главным их впечатлением от такой системы будет ее неповоротливость. Вопросы навигации особенно важны при создании приложения, ориентированного на использование ГПИ. ГПИ предоставляет очень много элементов управления, при помощи которых можно выполнять навигацию. Важно создать набор обязательных стандартов, обеспечивающих определенный уровень согласованности. Вот некоторые элементы управления, которые можно использовать для навигации: меню; линейки пиктограмм или кнопок; пиктограммы; пиктограммы внутри окон; непиктофаммные кнопки в окнах; диалоговые окна с вкладками (где щелчок на вкладке открывает другую панель окна); горячие клавиши. Как мы говорили, пользователи не должны запоминать или повторно вводить информацию. Это приводит нас к понятиям навигации с контекстом и без контекста. Навигация без контекста - это навигация, при которой вы переходите из одной экранной формы в другую, совершенно не связанную с первой. Например, вы обрабатываете транзакцию, но хотите быстро просмотреть очередь на печать и проверить, не печатается ли еще ваше задание. Навигация с контекстом подразумевает переход из одной экранной формы в форму, связанную с первой. Типичный пример - следование по связи в базе данных, в частности переход к элементам заказа из экранной формы заказов. Вряд ли можно ожидать, что пользователь захочет запоминать, какой заказ он смотрит, и вводить его вновь. В качестве примера рассмотрим систему обработки заявлений о выплате страхового возмещения. Пользователю, работающему с заявлением, при определении обоснованности требования может понадобиться много разных экранных форм. В частности, интерес могут представлять общие сведения о полисах, исключающие положения, предыстория, данные о владельце полиса и др. Гибкая система навигации даст возможность пользователям вызывать эти экранные формы по порядку в контексте заявления, над которым они работают. Тем не менее, иногда контекст может быть офаничивающим фактором. Допустим, работу пользователя прерывает запрос по телефону и он хочет ознакомиться с другим полисом (принадлежащим тому, кто звонит). Естественно, навигация с контекстом уже не помогает, а становится поме-j хой. Пользователь хотел бы отложить куда-нибудь текущее заявление! поработать над другим заявлением (которое становится контекстом), а потол вызвать отложенное заявление в контекст и продолжить над ним работу того места, где работа над ним была прервана. Чтобы правильно организовать перемещение между окнами приложения] необходимо иметь полное представление о методах работы пользователей! особенно о документообороте. Мы настоятельно рекомендуем вам протес-[ тировать (отмакетировать) все интерфейсы между различными средствами] чтобы обеспечить их техническую реализуемость, оценить производитель-] ность и рещить вопросы с лицензированием ПО. Если вы вызываете одно средство из другого, то столкнетесь со следующей проблемой: каждое из нта потребует соединения с Oracle. Даже если это не превышает лицензионные лимиты, возможен значительный расход оперативной памяти на сервере БД] Необходимо также решить вопросы безопасности навигационной под-[ системы. Механизм навигации должен обладать информацией о существую-] щих привилегиях в плане безопасности и быть способен воспрепятствоват нарушению прав доступа. Кроме того, по возможности следует избегат экспортирования пользовательских имен и паролей. Другими словами, рис- кованно запускать другую программу путем динамического создания файла скрипта с командой запуска, содержащей имя и пароль пользователя. Оперативная справочная система в наши дни хорошее программное обеспечение, особенно настольные продукты, как правило, поставляется с мощной оперативной справочной системой. Сейчас очень распространена практика, когда ПО распространяется без документации (или с документацией только в машинно-читаемой форме), а пользователи почти всецело полагаются на оперативную сгфавоч-ную систему. Правда, пользователям приходится привыкать к поиску информации в такой системе, но если средства поиска достаточно мощные, то все равно она лучше, чем руководство. Справочная подсистема должна быть хорошо спроектированной, логичной и простой в использовании. В большинстве случаев она также должна быть контекстно-зависимой, т.е. доступной из любой точки приложения и по умолчанию выдавать справку о той части приложения, из которой ее вызвали. При проектировании оперативной справочной системы приложения необходимо учитывать следующее: Находясь в какой-либо экранной форме и нажимая для вызова справка клавишу либо щелкая на кнопке, пользователь рассчитывает, что поя- вится окно контекстно-зависимой справки с информацией о поле, котором находится курсор. Это так называемая справка на уровне полей.\ В некоторых системах есть только справка на уровне экранных форм. которой контекстом является вся экранная форма, а не поля. Независимо от вида справки справочный текст должен предоставлять пользователю необходимую информацию об экранной форме. В этом тексте должны содержаться деловое или функциональное описания назначения данной экранной формы и каждого поля. Кроме того, в тексте должны быть гипертекстовые ссылки на родственные темы. Для сложных систем и приложений необходимо рассмотреть возможность разработки учебников, знакомящих с основами использования системы, поскольку не все работающие пользователи будут иметь хорошую подготовку. Во многих случаях содержание этих учебников в боль-щей степени касается порядка работы предприятия, чем принципов функционирования приложения. Существует еще одна популярная форма справки - карточки-подсказки, рассчитанные на неопытного пользователя. Эти карточки появляются в верхней части экрана и описывают действия, которые должен выполнить пользователь для достижения желаемых результатов. Например, можно создать набор карточек-подсказок для процедуры ввода заказа. Должна существовать взаимосвязь между ошибками и справкой. Большинство ошибок (за исвслючением системных) возникает в результате неправильных действий пользователя. Проинформировав пользователя о том, что он ввел номер заказа в неправильном формате, интегрированное приложение пойдет дальше и даст справку о том, как составляются номера заказов. Контекстно-зависимая справка предполагает, чтобы справочный текст имел хотя бы некоторые свойства гипертекста. Гипертекст позволяет осуществлять доступ к родственным темам внутри справочной подсистемы. Это хороший способ получения информации о системе. Приложение вызывает справочную систему, передавая контекст, в котором требуется справка. В простой системе на базе файлов контекст может строиться на заголовках разделов внутри справочного текста. Справочная система должна быть знакома пользователям. Если бы мы писали эту главу два-три года назад, то почти наверняка включили бы в нее советы по проектированию таблиц справочного текста, но мир изменился и мы уже не считаем, что справочные системы нужно реализовывать на уровне проекта. Они должны быть похожи на справочные системы, с которыми пользователь работает в других приложениях. Самый лучший путь - использовать родное для клиентской платформы справочное средство, даже несмотря на то, что при этом приходится распространять справочные файлы минимум до уровня файлового сервера в пределах предприятия. Например, на клиентах с Microsoft Wmdows следует использовать Microsoft Help. Если вы используете стандартную справочную систему, то сможете работать с мощными и простыми в эксплуатации средствами создания справок, которые помогут вам разработать справочные файлы профессионального уровня.
|
© 2006 - 2024 pmbk.ru. Генерация страницы: 0
При копировании материалов приветствуются ссылки. |