ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 20.11.2019
Просмотров: 9502
Скачиваний: 184

В
основе
данного
интерфейса
лежит
понятие
«
проект
».
Для
каждого
проекта
определяют
решаемую
задачу
,
к
проекту
присоединяют
данные
(
новые
или
выбранные
из
уже
существующих
)
и
выбирают
алгоритм
решения
задачи
.
При
выполнении
проекта
результаты
заносятся
в
протокол
проекта
.
Полученный
протокол
можно
сохранить
или
просто
закрыть
без
сохранения
.
При
необхо
-
димости
сохраненный
протокол
можно
удалить
.
Новые
данные
можно
создавать
отдельно
от
проекта
,
но
при
этом
необходимо
указать
задачу
.
Можно
модифицировать
данные
,
в
том
числе
и
изменить
тип
решаемой
задачи
,
и
сохранить
данные
с
новым
идентификатором
.
Уже
сохраненные
данные
можно
удалить
.
Для
просмотра
результатов
необходимо
открыть
уже
выполненные
проекты
.
Их
можно
распечатать
и
/
или
удалить
.
Вариант
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).

Интерфейс
,
полученный
в
результате
реализации
диалогов
,
проверяют
на
полноту
,
а
затем
предлагают
пользователю
для
тестирования
удобства
применения
.
При
наличии
сомнений
можно
предложить
несколько
вариантов
.
После
одобрения
интерфейса
его
реализуют
,
кодируя
соответствующие
процедуры
.
8.7.
Пользовательские
интерфейсы
прямого
манипулирования
и
их
проектирование
Возможность
прямого
манипулирования
,
предусмотренная
в
WIMP
интерфейсах
,
позволяет
разрабатывать
для
приложений
объектно
-
ориентированные
интерфейсы
прямого
манипулирования
.
Интерфейсы
данного
типа
на
внешнем
уровне
используют
директивную
форму
диалога
:
ввод
команды
осуществляется
при
выполнении
определенных
действий
с
пиктограммой
объекта
мышью
.
Основными
элементами
этих
интерфейсов
являются
:
метафоры
,
объекты
,
представления
объектов
и
технология
Drag and Drop («
перетащил
и
бросил
»).
Метафоры
.
Метафора
-
мысленный
перенос
свойств
или
признаков
одного
объекта
на
другой
,
чем
-
то
аналогичный
первому
.
Использование
метафор
в
интерфейсах
предполагает
активизацию
имеющегося
у
пользователя
опыта
(
ментальных
моделей
выполнения
аналогичных
действий
в
повседневной
жизни
или
на
рабочем
месте
).
Интерфейс
прямого
манипулирования
должен
обеспечивать
пользователю
среду
,
содержащую
знакомые
ему
элементы
,
с
которыми
пользователь
не
раз
встречался
в
профессиональной
деятельности
или
в
быту
,
и
предоставлять
ему
возможность
манипулирования
отдельными
объектами
.
Наличие
метафор
упрощает
для
пользователя
процесс
освоения
интерфейса
.
Например
,
метафора
«
Выбрасывание
мусора
»,
которую
использует
Windows
для
удаления
файлов
,
облегчает
пользователю
усвоение
этой
операции
.
Использовать
метафоры
надо
очень
аккуратно
,
так
как
при
этом
смысл
придается
всем
элементам
интерфейса
,
например
,
похожие
элементы
должны
вести
себя
похожим
образом
,
а
элементы
,
выделенные
одним
цветом
,
должны
находиться
в
определенной
связи
друг
с
другом
.
Семантическое
несоответствие
между
элементами
интерфейса
,
тем
,
что
от
них
ожидают
,
и
тем
,
что
они
на
самом
деле
выполняют
,
раздражает
и
дезориентирует
пользователей
.