31. Реализация диалогов в графическом пользовательском интерфейсе

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

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

Меню. Меню проектируют на основе графов диалогов разрабатываемого программного обеспечения. При этом, если число операций не превышает 5, то обычно используют кнопки. Если число операций не более 9-10, то - одноуровневое меню. И, наконец, если число реализуемых операций более 10, то используют «ниспадающее» двухуровневое иерархическое меню.

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

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

Количество уровней иерархического меню не должно превышать 2-3, так как при большем числе уровней требуемую операцию будет сложно искать. Причем желательно, чтобы число операций в окне меню не превышало 7-8, по той же причине.

Если число операций превышает 70-80, то возникает проблема, как построить наглядное меню с таким большим числом операций. Интересное решение было предложено разработчиками Microsoft Word. Они реализовали адаптивное иерархическое меню, где содержимое окна меню второго уровня постоянно меняется, отображая только те операции, которые использует пользователь

Если пользователь не находит нужной операции, то через несколько секунд или при нажатии специальной кнопки Word демонстрирует окно меню полностью.

Пример 8.4. Разработать основное меню системы решения комбинаторно-оптимизационных задач.

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

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

Вариант 1. Стандартизованный вариант меню для данной системы представлен на рис. 8.16. Пункт Файл объединяет все операции с информационными блоками обоих типов: проектами и данными

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

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

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

Для просмотра результатов необходимо открыть уже выполненные проекты. Их можно распечатать и/или удалить.

Вариант 2. «Нестандартный» вариант, основанный на интуитивной модели пользователя, т. е. концептуальной модели предметной области (см. рис. 6.9), представлен на рис. 8.17. В этом меню два типа блоков данных управляются операциями, отнесенными к разным группам «Задание» и «Данные». В результате удается частично разгрузить первый пункт меню, но необходимо дублировать операции с блоками данных (создание, открытие, закрытие и т. п.). Чтобы еще сократить количество пунктов в первой и во второй группах, можно использовать адаптивный вариант.

Панель инструментов. На панель инструментов помещают пиктограммы часто используемых операций. Если множество таких операций существенно зависит от специфики выполняемых с разрабатываемым программным обеспечением работ, то целесообразно обеспечить пользователю возможность формирования панелей инструментов по собственному усмотрению. В качестве примера можно посмотреть, как реализована операция настройки (Сервис\Настройка) Microsoft Word.

Контекстные меню. Контекстные меню включают операции, вероятность обращения к которым из данной зоны окна приложения с точки зрения разработчика максимальна

В процессе тестирования «удобства использования» (см. § 9.6) содержание контекстного меню может уточняться. Так же, как и в случае основного меню, нежелательно, если число операций этого меню превышает 6-8. Причем, чтобы облегчить пользователю поиск нужной операции целесообразно операции контекстного меню горизонтальными линиями делить на группы.

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

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

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

Пример 8.5. Реализовать диалог Новое задание системы решения комбинаторно-оптимизационных задач.

Граф диалога представлен на рис. 8.12. Этот управляемый системой диалог допускает возвраты на предыдущие шаги. Соответственно для него последовательность действий определена не жестко. В данном случае можно предложить два варианта реализации диалога: с использованием одной формы и с использованием последовательности диалоговых окон.

Вариант 1. Реализация диалога с использованием формы предполагает, что все шаги выполняются в одном окне. Следовательно, необходимо организовать выбор типа задачи, ввод/выбор данных, выбор алгоритма

После выполнения задания необходимо также предусмотреть возможность его сохранения, сохранения с другим именем и закрытия (рис. 8.18). Результаты целесообразно демонстрировать в отдельном окне, которое будет открываться при нажатии кнопки Показать результаты, так как у каждого типа задачи свои результаты.

Вариант 2. Последовательность диалоговых окон реализует последовательный или древовидный сценарий. Поэтому преобразуем сценарий диалога (см. рис. 8.13), к последовательному с возможностью возврата на один шаг (рис. 8.19).

Первое окно реализует выбор типа задачи (рис. 8.20, а). Результат выбора фиксируется в специальном документе - Протоколе. Второе - определение способа задания данных (рис. 8.20, б), третье - непосредственно задание данных в зависимости от выбранного способа (рисунок отсутствует, так как формы определения данных зависят от задачи и их целесообразно проекти­ровать отдельно для каждой задачи вместе с формами вывода результатов). Четвертое - выбор алгоритма (рис. 8.20, в). Пятое - инициацию выполнения (рис. 8.20, г). Шестое - демонстрирует результат (рисунок отсутствует). Седьмое - определяет, что следует сделать с результатом (рис. 8.20, д). Все диалоги строятся по максимально схожей схеме, что упрощает пользователю ориентацию в них.

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

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

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