Вы находитесь на странице: 1из 63

КОНСПЕКТ ЛЕКЦИЙ

ЛЕКЦИЯ 1. ПОНЯТИЕ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА

1.1. Виды пользовательских интерфейсов информационных


систем
Интерфейс – совокупность технических, программных и методических
(протоколов, правил, соглашений) средств сопряжения в вычислительной
системе пользователей с устройствами и программами, а также устройств с
другими устройствами и программами [12].
Интерфейс – в широком смысле слова, это способ (стандарт)
взаимодействия между объектами. Интерфейс в техническом смысле слова
задаёт параметры, процедуры и характеристики взаимодействия объектов.
Интерфейсы различают по таким характеристикам, как структура
связей, способ подключения и передачи данных, принципы управления и
синхронизации [1]:
1. Внутримашинный интерфейс – система связи и средств
сопряжения узлов и блоков ЭВМ между собой. Внутримашинный интерфейс
представляет собой совокупность электрических линий связи (проводов),
схем сопряжения с компонентами компьютера, протоколов (алгоритмов)
передачи и преобразования сигналов.
Различают два варианта организации внутри машинного интерфейса:
– многосвязный интерфейс, при котором каждый блок ПК связан с
другими блоками своими локальными проводами;
– односвязный интерфейс, в результате которого все блоки ПК связаны
друг с другом через общую или системную шину.
2. Внешний интерфейс – система связи системного блока с
периферийными устройствами ЭВМ или с другими ЭВМ. Здесь можно
выделить также несколько типов внешнего интерфейса:
– интерфейс периферийных устройств, подключаемых с помощью шин
ввода-вывода (PCI, AGP, USB, IEEE 1384 и др.);
– сетевой интерфейс, типа одноранговой сети или сети клиент-сервер с
топологиями типа звезда, кольцевая или шинная.
3. Интерфейс «человек – машина» или пользовательский интерфейс.
Машинная часть интерфейса – часть интерфейса, реализованная в
машине (аппаратно-программной ее части) с использованием возможностей
вычислительной техники.
Человеческая часть интерфейса – это часть интерфейса, реализуемая
человеком с учетом его возможностей, слабостей, привычек, способности к
обучению и других факторов.
В дальнейшем будем рассматривать только интерфейс пользователя.
Существует несколько определений пользовательского интерфейса
информационной системы.
Пользовательский интерфейс (ПИ) – система правил и  средств,
регламентирующая и  обеспечивающая взаимодействие программы
с пользовате-лем [1].
Пользовательский интерфейс – это совокупность информационной
модели проблемной области, средств и способов взаимодействия
пользователя с информационной моделью, а также компонентов,
обеспечивающих формирование информационной модели в процессе работы
программной системы [2].
Под информационной моделью понимается условное представление
проблемной области, формируемое с помощью компьютерных (визуальных и
звуковых) объектов, отражающих состав и взаимодействие реальных
компонентов проблемной области.
Средства и способы взаимодействия с информационной моделью
определяются составом аппаратного и программного обеспечения,
имеющегося в распоряжении пользователя, и от характера решаемой задачи.
Пользовательский интерфейс – это совокупность программных и
аппаратных средств, обеспечивающих взаимодействие пользователя с
компьютером [3]. Основу такого взаимодействия составляют диалоги. Под
диалогом в данном случае понимают регламентированный обмен
информацией между человеком и компьютером, осуществляемый в реальном
масштабе времени и направленный на совместное решение конкретной
задачи. Каждый диалог состоит из отдельных процессов ввода/вывода,
которые физически обеспечивают связь пользователя и компьютера. Обмен
информацией осуществляется передачей сообщения.
Как было указано выше, интерфейс – это, прежде всего набор правил,
которые можно объединить по схожести способов взаимодействия человека
с компьютером.
Различают три вида интерфейсов пользователя: командный, WIMP- и
SILK-интерфейсы [1].
1. Командный интерфейс – взаимодействие человека с компьютером,
осуществляется путем подачи компьютеру команд, которые он выполняет и
выдает результат пользователю. Командный интерфейс может быть
реализован в виде пакетной технологии и технологии командной строки. В
настоящее время пакетная технология практически не используется, а
технологию командной строки можно встретить в виде резервного способа
общения человека с компьютером.
Пакетная технология. Исторически этот вид технологии появился
первым на электромеханических вычислительных машинах К. Цюзе, Г.
Айкина, а затем на электронных вычислительных машинах Эккерта и
Моучли, на отечественных ЭВМ Лебедева, Брусенцова, на ЭВМ IBM-360 и т.
д. Идея его проста и состоит в том, что на вход компьютера подается
последовательность программ, набитых, например, на перфокартах, и
последовательность символов, определяющих порядок выполнения этих
программ. Человек здесь имеет малое влияние на работу машины. Он может
лишь приостановить работу машины, сменить программу и снова запустить
ЭВМ.
Технология командной строки. При этой технологии в качестве способа
ввода информации оператором в ЭВМ служит клавиатура, а компьютер
выводит информацию человеку с помощью алфавитно-цифрового дисплея
(монитора). Комбинацию монитор – клавиатура стали называть терминалом
или консолью. Команды набираются в командной строке, представляющей
собой символ приглашения и мигающий курсор, при этом набранные
символы можно стирать и редактировать. По нажатию клавиши «Enter»
(«Ввод») ЭВМ принимает команду и начинает ее выполнять. После перехода
в начало следующей строки компьютер выдает на монитор результаты своей
работы. Затем процесс повторяется. Наиболее распространенным командный
интерфейс был в операционной системе MS-DOS (рис. 1.1).

Рис. 1.1. Интерфейс операционной системы MS-DOS


2. WIMP-интерфейс (window – окно, image – образ, menu – меню,
pointer – указатель). Характерной чертой этого интерфейса является то, что
диалог пользователя с компьютером ведется не с помощью командной
строки, а с помощью окон, графических образов меню, курсора и других
элементов. Хотя в этом интерфейсе подаются команды машине, но это
делается через графические образы.
Идея графического интерфейса зародилась в середине 70-х гг. в
исследовательском центре фирмы Xerox Palo Alto Research Center (PARC).
Предпосылкой графического интерфейса явилось уменьшение времени
реакции компьютера на команду, увеличение объема оперативной памяти, а
также развитие элементной базы, технических характеристик ЭВМ и в
частности мониторов.
Появились алфавитно-цифровые дисплеи на компьютерах, причем на
этих дисплеях уже имелись такие эффекты, как «мерцание» символов,
инверсия цвета (смена начертания белых символов на черном фоне
обратным, то есть черных символов на белом фоне), подчеркивание
символов. Эти эффекты распространились не на весь экран, а только на один
или более символов. Следующим шагом явилось создание цветного дисплея,
позволяющего выводить вместе с этими эффектами, символы в 16 цветах на
фоне с палитрой (то есть цветовым набором) из 8 цветов. Появление
графических дисплеев с возможностью вывода любых графических
изображений в виде множества точек на экране различного цвета, фантазии в
использовании экрана привели к тому, что графический интерфейс стал
неотъемлемой частью всех компьютеров.
При этом первая система с графическим интерфейсом 8010 Star
Information System группы PARC появилась за четыре месяца до выхода в
свет первого компьютера фирмы IBM в 1981 г.
Первоначально визуальный интерфейс использовался только в
программах. Постепенно он стал переходить и на операционные системы,
используемые сначала на компьютерах Apple Macintosh, а затем и на IBM-
совместимых компьютерах.
WIMP-интерфейс был реализован в виде двух уровней:
– простой графический интерфейс;
– полный WIMP-интерфейс.
На первом этапе простой графический интерфейс очень походил на
технологию командной строки. Отличия от технологии командной строки
заключались в следующем:
– при отображении символов допускалось выделение части символов
цветом, инверсным изображением, подчеркиванием и мерцанием, что
способствовало повышению выразительности изображения;
– в зависимости от конкретной реализации графического интерфейса
курсор может представляться не только мерцающим прямоугольником, но и
некоторой областью, охватывающей несколько символов и даже часть
экрана, при этом выделенная область отличается от других, невыделенных
частей (обычно цветом);
– нажатие клавиши Enter не всегда приводит к выполнению команды и
переходу к следующей строке. Реакция на нажатие любой клавиши во
многом зависит от того, в какой части экрана находился курсор;
– кроме часто используемых клавиш управления курсором, стали
использоваться манипуляторы типа мыши, трекбола и т. п., которые
позволяли быстро выделять нужную область экрана и перемещать курсор.
Таким образом, можно определить следующие отличительные
особенности этого интерфейса:
– выделение областей экрана;
– переопределение клавиш клавиатуры в зависимости от контекста;
– использование манипуляторов и серых клавиш клавиатуры для
управления курсором;
– широкое использование цветных мониторов.
Появление этого типа интерфейса совпадает с широким
распространением операционной системы MS-DOS. Именно она внедрила
этот интерфейс в массы, благодаря чему 80-е гг. ХХ в. прошли под знаком
совершенствования этого типа интерфейса, улучшения характеристик
отображения символов и других параметров монитора.
Типичный пример использования этого вида интерфейса – файловая
оболочка Norton Commander (рис. 1.2).
Рис. 1.2. Интерфейс файловой оболочки Norton Commander
Постепенно проходил процесс унификации в использовании клавиатуры
и мыши прикладными программами. Слияние этих двух тенденций привело
к созданию такого пользовательского интерфейса, с помощью которого при
минимальных затратах времени и средств на переучивание персонала можно
работать с любыми программными приложениями.
Вторым этапом в развитии графического интерфейса стал полный
WIMP-интерфейс, который характеризуется следующими особенностями:
– вся работа с программами, файлами и документами происходит в
окнах – определенных очерченных рамкой частях экрана;
– программы, файлы, документы, устройства и другие объекты
представляются в виде значков (иконок), которые при открытии
превращаются в окна;
– все действия с объектами осуществляются с помощью меню, которое
становится основным элементом управления;
– манипулятор выступает в качестве главного средства управления.
Следует отметить, что WIMP-интерфейс требует для своей реализации
повышенного требования к производительности компьютера, объему его
памяти, качественного растрового цветного дисплея и программного
обеспечения, ориентированного на этот вид интерфейса. В настоящее время
WIMP-интерфейс стал стандартом де-факто.
Ярким примером программ с графическим интерфейсом является
операционная система Microsoft Windows (рис. 1.3).

Рис. 1.3. Интерфейс операционноя системы Microsoft Windows XP


3. SILK-интерфейс (speech – речь, image – образ, language – язык,
knowledge – знание). Этот интерфейс наиболее приближен к обычной
человеческой форме общения. В его рамках идет обычный разговор человека
и компьютера. При этом компьютер находит для себя команды, анализируя
человеческую речь и определяя в ней ключевые фразы. Результаты
выполнения команд он также преобразует в понятную человеку форму. Этот
вид интерфейса требует больших технических затрат, поэтому находится в
стадии разработки и совершенствования и используется в основном для
военных целей.
SILK– интерфейс для общения человека с машиной использует:
– речевую технологию;
– биометрическую технологию (мимический интерфейс);
– семантический (общественный) интерфейс.
Речевая технология появилась в середине 90-х гг. после появления
недорогих звуковых карт и широкого распространения технологий
распознавания речи. При этой технологии команды подаются голосом путем
произнесения специальных стандартных слов (команд), которые должны
выговариваться четко, в одном темпе с обязательными паузами между
словами. Учитывая, что алгоритмы распознавания речи недостаточно
развиты, требуется индивидуальная предварительная настройка
компьютерной системы на конкретного пользователя. Простейшая
реализация SILK-интерфейса в настоящее время используется в смартфонах
для реализации голосового вызова абонента.
Биометрическая технология («мимический интерфейс») возникла в
конце 90-х гг. и в настоящее время находится в стадии разработки. Для
управления компьютером используется выражение лица, направление
взгляда, размер зрачка и другие признаки человека. Для идентификации
пользователя используется рисунок радужной оболочки его глаз, отпечатки
пальцев и другая уникальная информация, которая считывается с цифровой
камеры, а затем с помощью программы распознавания образов из этого
изображения выделяются команды.
Семантический (общественный) интерфейс возник еще в конце 70-х гг.
ХХ в., с развитием искусственного интеллекта. Его трудно назвать
самостоятельным видом интерфейса, так как он включает в себя и интерфейс
командной строки, и графический, и речевой, и мимический интерфейсы.
Основной его особенностью является отсутствие команд при общении с
компьютером. Запрос формируется на естественном языке в виде связанного
текста и образов. В настоящее время используется для военных целей.
Существуют процедурно-ориентированный и объектно-
ориентированный интерфейсы (рис. 1.4) [4].
Процедурно-ориентированные интерфейсы используют традиционную
модель взаимодействия с пользователем, основанную на понятиях
«процедура» и «операция». В рамках этой модели программное обеспечение
предоставляет пользователю возможность выполнения некоторых действий,
для которых пользователь определяет соответствующие данные и следствием
выполнения которых является получение желаемых результатов.
Рис. 1.4. Типы интерфейсов

Различают процедурно-ориентированные интерфейсы трех типов:


«примитивные», меню и со свободной навигацией.
Примитивным называют интерфейс, который организует
взаимодействие с пользователем в консольном режиме. Обычно такой
интерфейс реализует конкретный сценарий работы программного
обеспечения, например: ввод данных – решение задачи – вывод результата
(см. рис. 1.1).
Единственное отклонение от последовательного процесса, которое
обеспечивается данным интерфейсом, заключается в организации цикла для
обработки нескольких наборов данных. Подобные интерфейсы в настоящее
время используют только в процессе обучения программированию или в тех
случаях, когда вся программа реализует одну функцию, например, в
некоторых системных утилитах.
Интерфейс-меню в отличие от примитивного интерфейса позволяет
пользователю выбирать необходимые операции из специального списка,
выводимого ему программой (рис. 1.5). Эти интерфейсы предполагают
реализацию множества сценариев работы, последовательность действий в
которых определяется пользователем.
Различают одноуровневые и иерархические меню. Первые используют
для сравнительно простого управления вычислительным процессом, когда
вариантов немного (не более 5–7), и они включают операции одного типа,
например, создать, открыть, закрыть и т. п. Вторые – при большом
количестве вариантов или их очевидных различиях, например операции с
файлами и операции с данными, хранящимися в этих файлах.
Рис. 1.5. Меню программы BIOS Setup

Интерфейс-меню предполагает, что программа находится либо в


состоянии «Уровень меню», либо в состоянии «Выполнение операции». В
состоянии «Уровень меню» осуществляется вывод меню соответствующего
уровня и выбор нужного пункта меню, а в состоянии «Выполнение
операции» реализуется сценарий выбранной операции. В порядке
исключения иногда пользователю предоставляется возможность завершения
операции независимо от стадии выполнения сценария и/или программы,
например, по нажатию клавиши Esc.
Древовидная организация меню предполагает строго ограниченную
навигацию: либо переходы «вверх» к корню дерева, либо «вниз» по
выбранной ветви (рис. 1.6).
При этом возможны два варианта организации меню:
– каждое окно меню занимает весь экран;
– на экране одновременно присутствует несколько разноуровневых
меню (Windows).
Каждому уровню иерархического меню соответствует свое
определенное окно, содержащее пункты данного уровня. При этом возможны
два варианта реализации меню: каждое окно меню занимает весь экран или
на экране одновременно присутствуют несколько меню разных уровней. Во
втором случае окна меню появляются при выборе пунктов соответствующего
верхнего уровня – «выпадающие» меню.
В условиях ограниченной навигации, независимо от варианта
реализации, поиск пункта более чем двухуровневого меню оказывается
довольно сложной задачей. Поэтому интерфейсы-меню в настоящее время
используют редко и только для сравнительно простого программного
обеспечения или в разработках, которые должны быть выполнены по
структурной технологии и без использования специальных библиотек.

Рис. 1.6. Подраздел «Power» меню программы Phoenix Award BIOS

Интерфейсы со свободной навигацией (графический интерфейс) также


называют интерфейсами WYSIWYG (What You See Is What You Get – что
видишь, то и получишь), поддерживают концепцию интерактивного
взаимодействия с ПО, визуальную обратную связь с пользователем и
возможность прямого манипулирования объектом (кнопки, индикаторы,
строки состояния) и информацией на экране. Кроме того, интерфейсы данного
типа поддерживают концепцию совместимости программ, позволяя
перемещать между ними информацию.
Интерфейсы данного типа ориентированы на использование экрана в
графическом режиме с высокой разрешающей способностью.
В отличие от интерфейса-меню, интерфейс со свободной навигацией
обеспечивает возможность осуществления любых допустимых в конкретном
состоянии операций, доступ к которым возможен через различные
интерфейсные компоненты («горячие» клавиши и т. д.).
Так, окна программ, реализующих интерфейс Windows, обычно
содержат (рис. 1.7):
 меню различных типов: ниспадающее, кнопочное и контекстное;
 разного рода компоненты ввода данных.
Причем выбор следующей операции в меню осуществляется как
мышью, так и с помощью клавиатуры.

Рис. 1.7. Интерфейс программы MS Word 2007

Существенной особенностью интерфейсов данного типа является


способность изменяться в процессе взаимодействия с пользователем,
предлагая выбор только тех операций, которые имеют смысл в конкретной
ситуации (рис. 1.8).
Объектно-ориентированные интерфейсы используют несколько иную
модель взаимодействия с пользователем, ориентированную на
манипулирование объектами предметной области. В рамках этой модели
пользователю предоставляется возможность напрямую взаимодействовать с
каждым объектом и инициировать выполнение операций, в процессе которых
взаимодействуют несколько объектов.

Рис. 1.8. Интерфейс программы «КОМПАС-3D»

Задача пользователя формулируется как целенаправленное изменение


некоторого объекта, имеющего внутреннюю структуру, определенное
содержание и внешнее символьное или графическое представление. Объект
при этом понимается в широком смысле слова, например модель реальной
системы или процесса, база данных, текст и т. п. Пользователю
предоставляется возможность создавать объекты, изменять их параметры и
связи с другими объектами, а также инициировать взаимодействие этих
объектов.
Элементы интерфейсов данного типа включены в пользовательский
интерфейс Windows, например, пользователь может «взять» файл и
«переместить» его в другую папку (drag and drop). Таким образом, он
инициирует выполнение операции перемещения файла.
Объектно-ориентированные интерфейсы пока представлены только
интерфейсом прямого манипулирования. Этот тип интерфейса предполагает,
что взаимодействие пользователя с программным обеспечением
осуществляется посредством выбора и перемещения пиктограмм,
соответствующих объектам предметной области.
В табл. 1.1 перечислены основные отличия пользовательских
интерфейсов процедурного и объектно-ориентированного типов [1].

Таблица 1.1
Отличительные особенности пользовательских интерфейсов

Процедурно-ориентированные Объектно-ориентированные
пользовательские интерфейсы пользовательские интерфейсы

Обеспечивают пользователей Обеспечивают пользователям


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

Человеко-ориентированный интерфейс – интерфейс, учитывающий


особенности человеческой психологии, физические ограничения и его
сознания во время работы. В англоязычной литературе для описания такого
подхода используется термин User-Centered Design – UCD («Разработка,
ориентированная на пользователя») [5]. Эта технология, кроме всего прочего,
предполагает как можно более раннее проектирование интерфейса с
последующим его развитием в процессе разработки самого программного
продукта.
Основное достоинство хорошего интерфейса пользователя заключается
в том, что пользователь всегда чувствует, что он управляет программным
обеспечением, а не программное обеспечение управляет им.
К факторам, которые обязательно необходимо помнить при разработке
человеко-ориентированного интерфейса, относится способность человека
отвлекаться, неточность его движений, восприятие информации, физическое
напряжение во время работы – факторы, критичные для систем,
используемых определенной категорией пользователей, например людей с
ослабленным зрением, нарушением восприятия цвета и т. д.
Пользователь не может одновременно обрабатывать несколько задач –
внимание может быть сосредоточено только над выполнением одной задачи.
Возможности человеческой памяти (кратковременной и долговременной)
существенно влияют на качество взаимодействия пользователя с системой
(табл. 1.2).
Свойства, а точнее ограничения кратковременной памяти (КВП)
являются очень важными факторами при разработке интерфейса. Дело в том,
что вся обработка поступающей информации производится в КВП, поэтому
пользователь должен заметить и выделить только нужную для себя. Как
правило, для опытного пользователя оценка полезности не представляет
проблем, неопытные же почти всегда обращают внимание на наиболее
заметные детали. Таким образом, самое важное в интерфейсе должно быть
наиболее заметным.

Таблица 1.2
Слабые и сильные стороны людей и компьютеров
Сильные стороны Слабые стороны
Краткосрочная память с малой
Распознавание образов.
емкостью.
Переключение внимания.
Быстрая потеря данных из
Бесконечная емкость
Люди краткосрочной памяти.
долговременной памяти.
Медленная обработка данных.
Богатая, многокодовая
Ошибки.
долговременная память.
Затрудненный доступ к
Способность к обучению.
долговременной памяти.
Простое сравнение с эталоном.
Память с большой емкостью. Ограниченные способности
Долговременная память. к обучению.
Компьютеры Высокая скорость обработки. Ограниченная емкость
Обработка без ошибок. долгосрочной памяти.
Безотказный доступ к памяти. Ограниченная интеграция
данных.
Пользователи работают с системой отнюдь не всё время, в течение
которого они находятся за компьютером. Дело в том, что пользователи
постоянно отвлекаются на множество мелочей, например: листок бумаги на
столе перекрывает другой, нужный; мимо кто-то проходит и т. д. Каждый
раз, когда пользователь прерывает свою деятельность и начинает думать о
том, что ему делать дальше, он отвлекается тоже.
Каждое такое отвлечение занимает определенное время и сбивает фокус
внимания, т. е. обработку текущего действия. После каждого такого
отвлечения пользователь должен либо вспоминать текущую задачу, либо
заново ставить её перед собой. У человека есть только один фокус внимания,
так что при любом отвлечении новые стимулы заменяют содержимое
кратковременной памяти и предыдущий фокус внимания теряется. Таким
образом, для возвращения к работе пользователю необходимо заново
поместить в свою память нужную информацию:
– на каком шаге он остановился;
– какие команды и параметры он уже дал системе;
– что именно он должен сделать на текущем шаге;
– куда было обращено его внимание на момент отвлечения.
Предоставлять пользователю всю эту информацию лучше всего
визуально, что позволит при разработке интерфейса максимально облегчать
возвращение пользователей к работе и спроектировать интерфейс так, чтобы
они возможно меньше о нем думали.
Несмотря на то, что интерфейсы непрерывно совершенствовались в
течение двух десятилетий, опубликованы руководства по их созданию и
созданы средства их разработки. Проблема совершенствования интерфейсов
с учетом более глубоких познаний менталитета и психологии пользователя
является все еще актуальной.
Тем более что проблема разработки однопользовательских интерфейсов
еще не решена, а если индивидуальное взаимодействие с некоторой системой
не проходит для пользователя легко и комфортно, то в результате этот
недостаток будет негативно отражаться на качестве работы всей системы,
независимо от того насколько она хороша в других своих проявлениях.
ЛЕКЦИЯ 2. СПОСОБЫ ВЗАИМОДЕЙСТВИЯ ПОЛЬЗОВАТЕЛЯ С
СИСТЕМОЙ

Пользовательский интерфейс представляет собой совокупность


программных и аппаратных средств, обеспечивающих взаимодействие
пользователя с компьютером.
Взаимодействие между пользователем и интерактивной системой
рассматривается как последовательность действий пользователя (входы) и
ответных реакций системы (выходы) с целью достижения установленных
целей [13].
На теоретическом уровне интерфейс имеет три основных компонента
[1]:
– способ общения машины с пользователем;
– способ общения пользователя с машиной;
– способ представления пользовательского интерфейса.
Способ общения машины с пользователем определяется прикладной
программной системой. Приложение управляет доступом к информации,
обработкой информации, представлением информации в виде, понятном для
пользователя.
Способ общения пользователя с машиной предполагает, что
пользователь должен распознать информацию, которую представляет
компьютер, понять (проанализировать) ее, и переходить к ответу. Ответ
реализуется через интерактивную технологию, элементами которой могут
быть такие действия, как выбор объекта при помощи клавиши или мыши.
Третью часть интерфейса составляет комплекс представлений
пользователя о приложении в целом, что называется пользовательской
моделью интерфейса.
Разработан ряд моделей взаимодействия графического
пользовательского интерфейса [2]:
1. Концептуальная модель может быть детализирована введением пяти
уровней взаимодействия пользователей с информационными системами:
физического; концептуального; лингвистического; визуального;
функционального.
Физический уровень определяет состав технических средств и
общетехнические требования к ним, например, расположение клавиш на
клавиатуре, характеристики устройств автоматического ввода информации,
характеристики мониторов. Физический уровень взаимодействия
соответствует нижнему уровню интерфейса пользователя в концептуальной
модели информационной системы (ИС).
Концептуальный уровень определяет способ отображения состояния
среды, с которой взаимодействует пользователь. Он базируется на некотором
представлении объектов среды через объекты интерфейса, связываемые
между собой в программной среде.
Лингвистический уровень определяет все, что связано с обработкой
текстовой информации: сообщения программной среды, ввод текстовых
команд пользователя, редактирование текста и т. д. Возможности интерфейса
в использовании различных языков, а также то, как он реализует свои
языковые возможности – все это относится к лингвистическому уровню
взаимодействия.
Визуальный уровень конкретизирует отображение концептуальных
объектов. Способ отображения концептуальных объектов, их взаимное
расположение, возможности пользователя в управлении этим отображением,
удобство восприятия и т. п. – все это относится к визуальным аспектам.
Концептуальный, лингвистический и визуальный уровни относятся
к двум уровням программных средств среды (уровню операционных систем
и уровню программных средств общего назначения).
Функциональный уровень рассматривает взаимодействие пользователя
с системой при решении прикладных задач, то есть типы воздействия
пользователя на систему через функции пользовательского интерфейса и
способы представления результатов в ответ на эти воздействия.
Функциональный уровень относится к верхнему уровню концептуальной
модели, на котором представлены прикладные программы ИС.
2. Модель, реализующая графические пользовательские интерфейсы,
представляет собой многоуровневую совокупность компонентов, в которой
верхний уровень занимают прикладные программы, а нижние уровни –
операционная система и процессор (рис. 1.9).
Рис. 1.9. Взаимодействие различных классов программного обеспечения
с аппаратурой и пользователем

Модель начинается с компонентов связи с прикладными программами,


содержащими множество точек, через которые пользователь контактирует
с системой и элементами, такими как меню и иконки. Основные уровни
модели не предназначены для выполнения функциональных или
программных операций. Они используются только для выбора графических
интерфейсов.
Объектная модель отражает реакции и взаимодействие приложений
с внешней средой и между собой. Она определяет характер реализуемых
прикладных функций, их использование, управление и построение объектов.
Прикладные программные интерфейсы (API) выполняют программно-
языковые функции для связи пользовательских приложений с графическим
интерфейсом. Программист может специфицировать функции (окна, меню,
процессы отображения, иконки), которые необходимы для соответствующих
прикладных программ. API включает средства, используемые
разработчиками программ при создании графических интерфейсов для
конкретных приложений.
Ядро графического пользовательского интерфейса сосредоточивает
экранные функции и элементы (например в системе Microsoft Windows в
ядре содержится только часть функций графического интерфейса).
Оконная система выделяется в некоторых случаях для повышения
гибкости развития всего графического интерфейса. Так, например, Х
Windows первоначально создавалась только как оконная система, а не весь
графический пользовательский интерфейс. Однако системы функционально
быстро развиваются, и оконные системы сливаются с ядром графического
интерфейса.
Модели изображения формируются для различных пользовательских
интерфейсов с помощью графических средств, в том числе Х Windows.
Реализации представленной многоуровневой модели графических
пользовательских интерфейсов весьма разнообразны и, в той или иной
степени, ориентированы на аппаратные и операционные платформы.
Однако общие тенденции состоят в стремлении обеспечить их, по
возможности, широкую мобильность между платформами с учетом
применения международных стандартов и некоторых стандартов де-факто.
При этом важнейшей задачей остается сохранение всей совокупности
функций, доступных пользователю, унификация технологии и процедур его
взаимодействия с приложениями при любых платформах.
3. Модель отражает общий методологический подход к реализации
интерфейсов пользователя и выбору объектов стандартизации. Все
компоненты пользовательского интерфейса должны поддерживаться
операционными системами как ПК пользователей, так и серверов. Эта
модель интерфейсов пользователя подразумевает разделение
функциональных компонентов приложений на клиентские и серверные части
независимо от какой-либо определенной архитектуры среды распределенной
обработки данных.
На практическом уровне взаимодействие пользователя с системой
осуществляется через обмен действиями и реакциями на эти действия между
компьютером и пользователем.
Обмен информацией между пользователем и компьютером по всем
формальным признакам соответствует понятию «диалог». Под диалогом в
данном случае понимают регламентированный обмен информацией между
человеком и компьютером, осуществляемый в реальном масштабе времени и
направленный на совместное решение конкретной задачи – обмен
информацией и координация действий.
Каждый диалог состоит из отдельных процессов ввода-вывода, которые
физически обеспечивают связь пользователя и компьютера (рис. 1.10).
Обмен информацией осуществляется передачей сообщений и
управляющих сигналов. Сообщение – это порция информации, участвующая
в диалоговом обмене. Различают следующие виды сообщений:
– входные сообщения, которые генерируются человеком с помощью
средств ввода: клавиатуры, манипуляторов, например мыши и т. п.;
– выходные сообщения, которые генерируются компьютером в виде
текстов, звуковых сигналов и/или изображений и выводятся пользователю на
экран монитора или другие устройства вывода информации (см. рис. 1.10).

Рис. 1.10. Организация взаимодействия компьютера и пользователя

Следует помнить, что при формировании информационного сообщения


необходимо использовать единую терминологию.
В основном пользователь генерирует сообщения следующих типов [2]:
– запрос информации;
– запрос помощи;
– запрос операции или функции;
– ввод или изменение информации, выбор поля кадра и т. д.
В ответ на сообщения пользователь получает:
– подсказки или справки;
– информационные сообщения, не требующие ответа;
– приказы, требующие действий;
– сообщения об ошибках, нуждающиеся в ответных действиях,
изменение формата кадра и т. д.
Выбор структуры диалога определяет тип разрабатываемого
пользовательского интерфейса.
Рассмотрим четыре варианта структуры диалога. Каждая из структур
имеет свои особенности и наиболее удобна для определенного класса задач
[3]:
1. Диалог на основе командного языка – очень часто используется в
операционных системах и является исторически первой из реализованных
структур диалога.
При такой организации диалога программная система не выводит
ничего, кроме постоянной подсказки (приглашения на ввод команды),
которая означает готовность системы к работе (см. рис. 1.1).
Каждую команду вводят с новой строки и обычно заканчивают
нажатием клавиши «ввод». Ответственность за правильность задаваемых
команд ложится на пользователя. Система информирует о невозможности
выполнения неверной команды, не поясняя, как правило, причин (рис. 1.11).

Рис. 1.11. Командная строка MS Windows с перечнем команд

Диалог на базе команд удобен для ввода управляющих сообщений,


однако он обеспечивает более широкие возможности выбора в любой точке
диалога и не требует иерархической организации обслуживающих его
программ.
Структура на базе командного языка не отличается хорошей
поддержкой пользователя и пригодна в основном для подготовленных
специалистов. Перед использованием такой системы необходимо пройти
курс обучения и в дальнейшем изучать особенности работы по
документации, а не на практике. Более того, поскольку системе неизвестно,
что намеревается делать пользователь, трудно предложить какую-либо
реальную помощь в процессе работы, кроме выдачи справок достаточно
общего характера.
Поскольку данная структура предполагает большой объем
запоминаемого материала (см. рис. 11), имена команд следует выбирать так,
чтобы они несли смысловую нагрузку и легко запоминались. Разработчик
должен стремиться избегать излишней функциональности, происходящей от
желания создать собственную команду для каждой функции, выполняемой
системой, то есть не стоит создавать множество разнообразных команд с
часто перекрывающимися функциями.
Диалог должен управлять данными. В интерфейсах на основе языков
команд это обычно достигается с помощью составных командных строк, где
ключевое слово для обозначения команды (что делать) предшествует списку
параметров (входным данным). Параметры в списке можно задавать в одной
из двух форм – в позиционной или ключевой. В первом случае назначение
параметра определяется по его месту в командной строке. В случае
ключевых параметров каждое значение предваряется определенным
идентификатором, который определяет его назначение (рис. 1.12).

Рис. 1.12. Список всех ключей консоли chkdsk


Позиционные параметры уменьшают объем вводимой информации, но
их существенным недостатком является то, что вводимые значения должны
указываться в строго определенном порядке, нарушение которого плохо
диагностируется системой и может повлечь серьезные последствия. Задание
позиционных параметров осложняется, если их список достаточно велик.
Этот недостаток стремятся компенсировать, разрешая опускать
неизменяемые параметры, вводя два разделителя друг за другом.
Ключевые параметры уменьшают нагрузку на память пользователя в
том отношении, что отпадает необходимость в запоминании порядка их
следования, кроме того, можно опускать необязательные параметры. В этом
случае пользователю необходимо запомнить множество ключевых слов, а
разработчику – подобрать для них соответствующие имена. Этот подход
также требует большего времени работы системы, чтобы распознать
ключевые слова, заданные в произвольном порядке.
Многие командные языки поддерживают макросы, которые расширяют
функциональные возможности диалога без увеличения количества команд.
Макрос содержит несколько отдельных командных строк. При обращении
к нему в процессе диалога отдельные строки команд макроса выполняются
одна за другой, как если бы они вводились с клавиатуры. Это существенно
сокращает диалоговые сеансы, содержание часто повторяющихся
последовательностей команд, которые, собственно, и оформляются в виде
макросов.
Структура на основе языка команд по своим возможностям самая
быстрая и гибкая из всех структур диалога. Большинство пользовательских
интерфейсов на базе «естественного» языка реализуется с помощью языков
команд с очень большим набором ключевых слов.
Однако эта структура не обеспечивает пользователя поддержкой,
поэтому даже подготовленные пользователи считают, что очень сложно
использовать все заложенные в ней возможности. Большинство же
пользователей хорошо знакомы только с весьма ограниченным набором
средств, с которыми они работают регулярно.
2. Диалог типа «Вопрос – ответ» (Question & Answer) – это наиболее
известная структура диалога, использующая аналогию с обычным интервью.
Система выступает в роли интервьюера и получает информацию от
пользователя в виде ответов на вопросы. Все диалоги, управляемые
компьютером, в той или иной степени состоят из вопросов, на которые
пользователь отвечает. Однако в данной структуре этот процесс выражен
явно.
В каждой точке диалога система выводит один вопрос, на который
пользователь дает один ответ. В зависимости от полученного ответа система
может решить, какой следующий вопрос задавать. Данная структура диалога
предоставляет естественный механизм ввода, как управляющих сообщений
(команд), так и данных. Никаких ограничений на диапазон или тип входных
данных, которые могут обрабатываться, не накладывается.
С появлением графического интерфейса структура «вопрос – ответ»
несколько устарела, но у нее имеются определенные достоинства. Эта
структура может удовлетворить требования различных пользователей и
типов данных. В частности, она особенно уместна при реализации диалога с
множеством «ответвлений», т. е. в тех случаях, когда на каждый вопрос
предусматривается большое число ответов, каждый из которых влияет на то,
какой вопрос будет задан следующим. По этой причине данная структура
диалога часто используется в экспертных системах.
3. Диалог на основе меню является наиболее популярным вариантом
организации запросов на ввод данных во время диалога, управляемого
компьютером.
Существует несколько основных форматов представления меню на
экране:
– список объектов, выбираемых прямым указанием, либо указанием
номера;
– меню в виде блока данных;
– меню в виде строки данных;
– меню в виде пиктограмм.
Меню в виде строки данных может появляться вверху или внизу экрана
и часто остается в этой позиции на протяжении всего диалога (рис. 1.13).
Таким образом, посредством меню удобно отображать возможные варианты
данных для ввода, доступных в любое время работы с системой. Если в
системе имеется достаточно большое разнообразие вариантов действий,
организуется иерархическая структура из соответствующих меню.
Дополнительные меню в виде блоков данных «всплывают» на экране в
позиции, определяемой текущим положением указателя, либо «выпадают»
непосредственно из строки меню верхнего уровня. Эти меню исчезают после
выбора варианта.
Меню в виде пиктограмм представляет собой множество объектов
выбора, разбросанных по всему экрану, при этом объекты выбора содержат
графическое представление вариантов работы (рис. 1.14).
Пользователь диалогового меню может выбрать нужный пункт, вводя
текстовую строку, которая идентифицирует этот пункт, указывая на него
непосредственно или просматривая список и выбирая из него. Система
может выводить пункты меню последовательно, при этом пользователь
выбирает нужный ему пункт нажатием клавиши.
Рис. 1.13. Форматы представления меню

Рис. 1.14. Меню в виде пиктограмм

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


сообщений, так и данных. Структура меню зависит от его размера и
организации, от способа выбора пунктов меню и реальной потребности
пользователя в поддержке со стороны меню.
Структура типа меню является наиболее естественным механизмом для
работы с устройствами указания и выбора: меню представляет собой
изображение тех объектов, которые выбираются пользователем.
4. Диалог на основе экранных форм предполагает обработку на каждом
шаге диалога единственного ответа, хотя и допускает обработку на одном
шаге диалога нескольких ответов.
На практике формы используются в основном там, где учет какой-либо
деятельности требует ввода достаточно стандартного набора данных.
Человек, заполняющий форму, может выбирать последовательность ответов,
временно пропускать некоторый вопрос, возвращаться назад для уточнения
или редактирования предыдущего ответа. Он работает с формой до тех пор,
пока не заполнит ее полностью и не передаст системе (рис. 1.15).
Программная система может проверять каждый ответ непосредственно
после ввода или выждать и вывести список ошибок только после заполнения
формы целиком. В некоторых системах информация, вводимая
пользователем, становится доступной только после нажатия клавиши «ввод»
по окончании заполнения формы.
Рис. 1.15. Форма регистрации почтового ящика на сайте Mail.ru

Если встретилась какая-либо ошибка, то выводится форма с


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

Рис. 1.16. Оповещение об ошибке при заполнении формы

Часто все необходимые единицы ввода невозможно отобразить


одновременно в пределах одного экрана (или окна), тогда их необходимо
разделить на группы, которые отображаются на последовательности экранов
(окон). Важно, чтобы это разбиение сохраняло логические связи и не
приводило к разделению связанных частей документа.
Структура диалога на основе экранной формы обеспечивает высокий
уровень поддержки пользователя: для каждого вопроса формы могут быть
предусмотрены сообщения об ошибках и справочная информация.
Эта структура позволяет повысить скорость ввода данных по сравнению
со структурой типа «вопрос – ответ» и манипулировать более широким
диапазоном входных данных, нежели меню; кроме того, с ней могут работать
пользователи любой квалификации. Поскольку эта структура имеет
последовательную, а не древовидную организацию, она в меньшей степени
подходит для работы в режиме выбора вариантов. Еще одной областью
применения экранных форм является задание параметров запросов в базах
данных.
Таким образом, выбор структуры диалога будет определять состав
разрабатываемого пользовательского интерфейса в соответствии с его
основными параметрами.

Состав пользовательского интерфейса информационных


систем

Пользовательский интерфейс (ПИ) часто понимают только как внешний


вид программы. Однако пользователь воспринимает через него всю
программу в целом. ПИ объединяет в себе все элементы и компоненты
программы, которые способны оказывать влияние на взаимодействие
пользователя с программным обеспечением (ПО) [6]:
 набор задач пользователя, которые он решает при помощи системы;
 элементы управления системой;
 навигацию между блоками системы;
 визуальный (и не только) дизайн экранов программы;
 средства отображения информации, отображаемая информация и
форматы;
 устройства и технологии ввода данных;
 диалоги, взаимодействие и транзакции между пользователем и
компьютером;
 обратную связь с пользователем;
 поддержку принятия решений в конкретной предметной области;
 порядок использования программы и документацию на нее.
Управляющая составляющая интерфейса приложения является
реализацией выбранного типа пользовательского интерфейса, его синтаксиса,
дизайна и манипуляционных свойств посредством различных управляющих
компонентов.
Графический пользовательский интерфейс определяется конечным
словарем графических управляющих элементов (ГУЭ). Каждый ГУЭ
обладает стандартизированными свойствами описанного вида,
составляющими его регламент. Нарушение регламента ГУЭ рассматривается
как ошибка проектирования пользовательского интерфейса.
Управление – общий термин для компонентов графического интерфейса,
которые служат для замещения объектов, являющихся знакомыми
пользователям (рис. 1.17).

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

Кнопки используются для выбора опции или вызова события (например,


запуск подпрограммы) (рис. 1.18). Кнопкой называется элемент управления,
всё взаимодействие пользователя с которым ограничивается одним
действием – нажатием.
Нажатие на такую кнопку запускает какое-либо явное действие, поэтому
правильнее называть такие кнопки «кнопками прямого действия».
Рис. 1.18. Примеры оформления кнопок
Переключатели подобны кнопкам выбора, в которых пользователь
выбирает значение из фиксированного списка, но в данном случае,
пользователь может выбрать более одного значения из списка.
Переключатели подразделяются на чекбоксы (check box), радиокнопки (radio
button) и комбобоксы (combo box) (рис. 1.19).

Рис. 1.19. Примеры переключателей: радиокнопки, чекбоксы и комбобоксы


Чекбоксы и радиокнопки являются кнопками отложенного действия, т.
е. их нажатие не инициирует какое-либо немедленное действие. С их
помощью пользователи вводят параметры, которые скажутся после, когда
действие будет запущено иными элементами управления.
Главное различие заключается в том, что группа чекбоксов даёт
возможность пользователям выбрать любую комбинацию параметров,
радиокнопки же позволяют выбрать только один параметр. Это сближает эти
элементы со списками множественного и единственного выбора
соответственно.
Комбобоксами (combo box) называются гибриды списка с полем ввода:
пользователь может выбрать существующий элемент, либо ввести свой.
Счетчик (spin button) используется для создания числового значения.
Нажимая на одну из двух кнопок счетчика, можно либо увеличивать, либо
уменьшать текущее значение в другом элементе управления, обычно в
текстовом поле (рис. 1.20).
Ползунки дают пользователям возможность выбрать значение, стоящее
в хорошо ранжирующемся ряду, когда:
– значений в ряду много;
– нужно передать пользователям ранжируемость значений.

Рис. 1.20. Пример использования ползунка в интерфейсе

Слайдеры – обычно это элементы полосы прокрутки, они могут быть


помещены в горизонтальную или вертикальную линейку на экране (рис.
1.21).
Метки и текстовые блоки используются для текстовой информации.
Текстовые блоки позволяют пользователю вводить текстовые данные в поля,
метки – нередактируемые поля, используемые только для отображения
текста, типа подсказок, команд пользователя и т. д. (см. рис. 1.17).
Списки – специализированные средства управления, которые
отображают раскрывающиеся списки значений (часто с присоединенными
слайдерами, чтобы перемещаться вверх или вниз по списку) и позволяют
пользователю выбирать значение из списка или вводить другое значение в
присоединенное текстовое поле. Списки – удобный и компактный элемент
интерфейса, который занимает минимум места на экране и в то же время
несет большую информационную нагрузку (рис. 1.22).

Рис. 1.21. Пример использования вертикального слайдера


Рис.1. 22. Разновидности списков
Списки бывают пролистываемыми и раскрывающимися, причем
пролистываемые могут обеспечивать как единственный, так и
множественный выбор, раскрывающиеся же работают исключительно как
радиокнопки. Самым простым и распространенным вариантом списка
является раскрывающийся список.
Раскрывающиеся списки обладают одним существенным достоинством.
Оно заключается в том, что малая высота списка позволяет с большой
легкостью визуально отображать команды, собираемые из составляющих.
Более сложным вариантом списка является пролистываемый список.
Пролистываемые списки могут позволять пользователям совершать как
единственный, так и множественный выбор.
Список единственного выбора является промежуточным вариантом
между группой радиокнопок и раскрывающимся списком. Он меньше
группы радиокнопок с аналогичным числом элементов, но больше
раскрывающегося списка.
Вместе с командными кнопками, чекбоксами и радиокнопками, поля
ввода являются основой любого интерфейса (рис. 1.23).

Рис. 1.23. Использование поля ввода


Необходимый элемент информационной системы – меню, позволяющее
пользователю выполнять задачи внутри приложения и управлять процессом
решения.
Меню – набор опций, отображаемых на экране, где пользователи могут
выбирать и выполнять действия, тем самым, производя изменения в
состоянии интерфейса. Достоинство меню в том, что пользователи не
должны помнить название элемента или действия, которое они хотят
выполнить, а должны только распознать его среди пунктов меню. Таким
образом, меню может использовать даже неопытный пользователь. Однако
проект меню должен быть тщательно продуман – чтобы меню было
эффективным, названия пунктов меню должны быть очевидными.
Меню может занимать много экранного места, но есть решение для этой
проблемы – использование всплывающего или ниспадающего меню. При
нажатии на иконку, строку меню или другой объект вызывается
всплывающее или ниспадающее меню.
Существуют несколько различных разновидностей меню, но основной
интерес представляют только два из них. Первая разновидность делит меню
на два типа:
– статические меню, т. е. меню, постоянно присутствующие на экране.
Характерным примером такого типа меню является панель инструментов
(рис. 1.24);
– динамические меню, в которых пользователь должен вызвать меню,
чтобы выбрать какой-либо элемент. Примером является обычное контекстное
меню (рис. 1.25).

Рис. 1.24. Пример оформления статического меню


Рис. 1.25. Пример оформления динамического меню
Вторая разновидность также делит меню на два типа:
– меню, разворачивающееся в пространстве (например, обычное
раскрывающееся меню). Всякий раз, когда пользователь выбирает элемент
нижнего уровня, верхние элементы остаются видимыми;
– меню, разворачивающееся во времени. При использовании таких меню
элементы верхнего уровня по тем или иным причинам исчезают с экрана.
В процессе проектирования системы меню приложения необходимо
принять наилучший способ отображения меню, чтобы оно было понятно и
удобно в использовании. Обычно команды меню упорядочены некоторым
иерархическим способом. Основная проблема состоит в том, чтобы
правильно распределить различные пункты меню по различным уровням и
правильно их сгруппировать. Имеются четыре варианта для организации
меню [4]:
 алфавитный;
 категорийный;
 в соответствии с нормальными соглашениями;
 в соответствии с частотой использования.
Поскольку разработка интерфейса заключается в основном в том,
чтобы правильно помещать правильные элементы управления в
правильные окна или экраны, окна требуют такой же тщательной
разработки, как элементы управления.
Окно – это специальная область физического экрана, используемая для
представления и взаимодействия с объектами, информацией об объектах, или
для выполнения действий, применяемых к объекту.
Окно обладает строкой заголовка, набором операций перемещения,
изменения размера, набором меню и областью для отображения информации
об объектах, строки статуса, панели инструментов и полосы прокрутки.
Обычно окно представляет собой прямоугольник.
Окно отображает информацию только на определенную часть или
область всего устройства отображения. Частичное использование устройства
отображения позволяет просматривать несколько окон для одновременного
взаимодействия с несколькими объектами или управляющими диалогами.
Определение окна подразумевает использование графики или
визуализации вместо текстовой информации для указания доступного объема
информации.
Структура окна или экрана является самым существенным фактором,
влияющим на качество интерфейса. Производительность, например
пользователей порой можно повысить вдвое, просто изменив расположение
элементов управления, не меняя сами эти элементы.
Окно должно хорошо сканироваться взглядом, т. е. его основные части
должны быть сразу видны и заметны. Как правило, такие проблемы
появляются в больших окнах, дающих доступ ко многим функциям. Обычно
интерфейсные элементы в таких окнах организованы в блоки, при этом
обычно используется один из двух приёмов: рамки группировки и пустоты.
Окно должно читаться как текст, что повышает скорость его восприятия
пользователем. При этом один элемент управления должен однозначно
преобразовываться в единый фрагмент предложения, а единая группа
элементов – в целое предложение. Проверить читаемость окна просто: окно
нужно прочитать, и тогда становится понятно, какие нужны подписи к
элементам, как они должны быть расположены и тому подобное. При этом
чаще всего используемые элементы должны быть расположены в левой
верхней части экрана, реже используемые – в правой нижней части (чтение –
сначала левый верхний угол, затем вправо, затем на следующую «строку» и
т. д.).
Различают несколько типов окон (см. рис. 1.7, 1.19):
– главные окна программы;
– окна документа;
– режимные диалоговые окна;
– безрежимные диалоговые окна;
– палитры;
– окна браузера, так как используемая в Интернете технология
существенно отличается от технологии разработки ПО.
Другими словами, окно является средством просмотра и редактирования
информации, а также отображения содержимого и свойств объектов. Окна
могут использоваться также для вывода на экран значений параметров,
результатов выполнения команд, наборов инструментов и сообщений,
информирующих пользователя о конкретной ситуации.
Формы – основной элемент графического интерфейса. Назначение форм
– удобный ввод и просмотр данных, состояния, сообщений информационной
системы (см. рис. 1.15).
Основные принципы проектирования форм [3]:
 форма проектируется для более удобного, более понятного и
скорейшего достижения решения поставленной задачи; если форма
переносится с бумажного носителя, то передвижение по смежным полям не
должно вызывать затруднений у пользователя;
 размещение информационных единиц на пространстве формы должно
соответствовать логике ее будущего использования: это зависит от
необходимой последовательности доступа к информационным единицам,
частотой их использования, а также от относительной важности элементов;
 важно использовать незаполненное пространство, чтобы создать
равновесие и симметрию среди информационных элементов формы, для
фиксации внимания пользователя в нужном направлении;
 логические группы элементов необходимо отделять пробелами,
строками, цветовыми или другими визуальными средствами;
 взаимозависимые или связанные элементы должны отображаться в
одной форме.
Навигация обеспечивает пользователю способность перемещаться
между различными экранами, информационными единицами и
подпрограммами в автоматизированной системе. В полноценной системе
пользователь всегда может получить информацию о состоянии системы,
процессе выполнения или активной подпрограмме.
Существует ряд навигационных средств и приемов, которые помогают
пользователю ориентироваться в системе:
– использование заголовков страниц для каждого экрана;
– использование номеров страниц; номеров строк и столбцов;
– отображение текущего имени файла вверху экрана.
Тип системы навигации зависит от принятого стиля интерфейса. Для
интерфейсов языка команд очень мало способов обеспечения полноценной
навигации. В интерфейсах с меню можно использовать иерархически
структурированное меню.
Показатель правильности пользовательского интерфейса определяется
по нормативным документам (стандартам), содержащим явное или неявное
описание на уровне пиктограмм и способов манипуляции ими.
Правильность управляющих средств пользовательского интерфейса
конкретного приложения – это соответствие управляющих средств
синтаксису интерфейсов соответствующего типа.

ЛЕКЦИЯ 3. СТАНДАРТИЗАЦИЯ ИНТЕРФЕЙСОВ


ИНФОРМАЦИОННЫХ СИСТЕМ

Ведущие специалисты в области человеко-машинных компьютерных


систем уже к середине 70-х гг. XX в. осознали необходимость формирования
единых подходов к реализации пользовательского интерфейса. Результаты
этих исследований заставили вспомнить об эргономике рабочего места.
Американский Национальный институт стандартов (ANSI) имеет по
данному направлению специальную консультативную группу – Комитет по
стандартам интерфейса «человек-компьютер» (The Human-Computer Interface
Standard Committee). Существуют подобные организации не только в США,
но и в других странах; более того, имеются также международные
исследовательские группы, работающие в этом направлении, например
Международный консультативный комитет по телеграфии и телефонии
(International Telegraph and Telephone Consultation Committee), изучающий
особенности интерактивных элементов интерфейса [3].
Многими из этих организаций или рабочих групп, в свое время, были
подготовлены проекты документов по стандартизации пользовательских
интерфейсов, содержащие принципы их проектирования и реализации. Так, в
1986 г. было опубликовано «Руководство по разработке программного
пользовательского интерфейса», содержащее 944 принципа, касающихся
ввода и отображения данных, поддержки пользователя, защиты данных и т.
д. Однако ни один из этих проектов не получил статуса официального
документа, поскольку все они имели общий недостаток: в них не
учитывались технологические возможности инструментальных средств,
имевшихся в распоряжении разработчиков программного обеспечения.
Ситуация коренным образом изменилась в 1987 г., когда корпорация
IBM объявила о намерении создать единую среду разработки приложений
(Systems Application Architecture – SAA) [5].
Данный проект предусматривал не только разработку единых
принципов создания приложений, но и реализацию этих принципов на
основе соответствующей технологической базы.
Целями проекта являлись:
– повышение производительности труда программистов и конечных
пользователей;
– облегчение эксплуатации и сопровождения программного
обеспечения;
– повышение эффективности распределенной обработки информации;
– увеличение отдачи инвестиций в разработку информационных систем.
Проект SAA содержал четыре компонента:
– Соглашения по интерфейсу пользователя (Common User Access –
CUA);
– Соглашения по программному интерфейсу (Common Programming
Inter-face – CPI);
– Соглашения по разработке приложений (Common Applications – СА);
– Соглашения по коммуникациям (Common Communications Support –
CCS).
В качестве технологической базы для реализации соглашений по
пользовательскому интерфейсу было предложено конкретное
инструментальное средство – Programming Toolkit для операционной
системы OS/2. При его создании был учтен накопленный к тому времени
опыт разработки интерфейсов, а также последние достижения в данной
области, в первую очередь – появление графических интерфейсов.
Исследованиями и практической реализацией графических интерфейсов
в то время уже занимались такие фирмы, как Xerox, Apple, Digital Research и
Microsoft. В результате их деятельности были определены основные
концепции построения графических пользовательских интерфейсов:
– использование единой рабочей среды пользователя в виде так
называемого «Рабочего стола»;
– объектно-ориентированный подход к описанию заданий
пользователей;
– использование графических окон в качестве основной формы
отображения данных;
– применение средств неклавиатурного ввода, основанного на выборе и
указании с помощью манипулятора «мышь».
В силу различных причин фирма IBM при реализации проекта SAA
наиболее тесно сотрудничала с фирмой Microsoft. Хотя впоследствии пути
двух гигантов компьютерного бизнеса несколько разошлись, основные
положения проекта SAA успешно развиваются и в настоящее время:
корпорацией IBM – применительно к OS/2, а фирмой Microsoft – в рамках
семейства ОС Windows.
Особенностью пользовательского интерфейса как архитектурного
компонента среды ИС является необходимость высокой согласованности
всех функциональных элементов интерфейса. В связи с этим организации по
стандартизации и промышленные консорциумы разрабатывают
спецификации пользовательского интерфейса в виде гармонизированных
профилей на основе базовых стандартов.
Для построения профилей интерфейсов пользователя должны
использоваться базовые стандарты, относящиеся к следующим классам
объектов стандартизации [1]:
– типовые формы документов и процедуры работы с ними;
– элементы взаимодействия пользователя с алфавитно-цифровым
интерфейсом;
– элементы взаимодействия пользователя с графическим интерфейсом;
– структура распределенных приложений в части средств,
поддерживающих интерфейсы пользователя.
Типовые формы документов и процедуры работы с ними,
рассматриваемые как объекты стандартизации, относятся к функциональному
уровню взаимодействия пользователей с информационными системами.
Объектами стандартизации, соответствующими процедурам из этого перечня,
являются элементы интерфейса пользователя, определяющие возможность
начала соответствующей операции, ее ход и результат. В этих документах
должны быть описаны:
– соответствие между элементами интерфейсов пользователя
(экранными формами) и типовыми процедурами;
– последовательность допустимых операций и переходы между
экранными формами;
– форма идентификации ошибочных действий и/или ситуаций;
– формы входных и выходных документов.
Большинство приложений, использующих алфавитно-цифровой
интерфейс, предоставляют либо вариант интерфейса, разработанного
специально в составе приложения, либо интерфейс, который может быть
сконструирован при помощи средства разработки этого приложения.
Деятельность в области разработки пользовательских интерфейсов
информационных систем возглавляется и координируется подкомитетом
ISO/TC159/SC4 «Эргономика взаимодействия «человек – система»» (прил. А)
[16].
В табл. 1.3 приведена часть стандартов ISO на графический
пользовательский интерфейс WIMP [1].
Таблица 1.3
Типы
Документ ISO управляющих средств,
ГУЭ
Визуальное
ISO 9241-12:1998 Эргономические требования,
представление
связанные с использованием видеотерминалов
информации: окна,
для учрежденческих работ.
поля, списки, метки,
Часть 12. Представление информации таблицы
ISO 9241-14:1997 Эргономические требования,
связанные с использованием видеотерминалов
Меню
для учрежденческих работ.
Часть 14. Диалоги типа выбора меню
ISO 9241-16:1999 Эргономические требования,
связанные с использованием видеотерминалов
Прямые манипуляции
для учрежденческих работ.
Часть 16. Диалоги простых манипуляций

ISO/IEC 11581-(1999-2000) Информационные


технологии. Системные интерфейсы пользователя
Пиктограммы
и символы. Символы и функции пиктограммы.
Часть 6. Действующие пиктограммы
ISO 9241-143:2012 Эргономика взаимодействия
человек – система. Формы
Часть 143. Формы
ISO 14915-2:2003 Эргономика программного
обеспечения для мультимедийного
Навигация
интерфейса пользователя.
Часть 2. Навигация и контроль мультимедиа
Несмотря на широкое распространение графического интерфейса, он не
является единственно возможным или необходимым вариантом организации
взаимодействия пользователя с приложением. Поэтому и в проектах
документов по стандартизации интерфейса рассматривается целый ряд
вопросов, относящихся к общей методике проектирования и реализации
пользовательского интерфейса (прил. Б) [13].
В настоящее время, однако, не существует подобного рода
спецификации, которая охватывала бы все аспекты пользовательского
интерфейса. Традиционно такие профили описывают либо структуру
графического оконного интерфейса в целом, либо архитектуру построения
распределенных приложений.

КОНТРОЛЬНЫЕ ВОПРОСЫ

1. Что такое интерфейс? Классификация интерфейсов систем.


2. Определение термина «пользовательский интерфейс».
3. Интерфейс командной строки.
4. Интерфейсы командной строки и пользовательская модель.
5. Интерфейсы меню. Полноэкранные меню. Панели меню и палитры.
6. Интерфейсы меню и пользовательская модель.
7. Графический пользовательский интерфейс (ГПИ).
8. Основные свойства графических пользовательских интерфейсов.
9. Процедурно-ориентированные и объектно-ориентированные
интерфейсы.
10. Человеко-ориентированные интерфейсы.
11. Психология пользователей. Опыт и ожидания пользователя.
12. Восприятие и внимание человека.
13. Способы взаимодействия пользователя с информационной системой.
14. Виды диалога информационной системы.
15. Составные элементы интерфейса информационной системы.
16. Виды и назначение управляющих элементов графического и
интерфейса.
17. Меню, его разновидности.
18. Стандарты и руководящие принципы при проектировании
интерфейса.
19. Развитие существующих руководящих принципов проектирования
интерфейса.
20. Руководящие принципы по разработке интерфейса на макро– и
микроуровне.
21. Разработка интерфейсов для использования во всем мире.
22. Руководящие принципы и инструментарий разработки программного
обеспечения.
ЛЕКЦИЯ 4. ПРОЕКТИРОВАНИЕ ПОЛЬЗОВАТЕЛЬСКИХ
ИНТЕРФЕЙСОВ

Основные принципы создания интерфейсов

К основным принципам проектирования пользовательского интерфейса


относится [3]:
1. Естественность (интуитивность). Естественный – это такой
интерфейс, который не вынуждает пользователя существенно изменять
привычные для него способы решения задачи. Это означает, что сообщения и
результаты, выдаваемые приложением, не должны требовать
дополнительных пояснений. Целесообразно также сохранить систему
обозначений и терминологию, используемые в данной предметной области.
Использование знакомых пользователю понятий и образов (метафор)
обеспечивает интуитивно понятный интерфейс при выполнении его заданий
(рис. 2.1).

Рис. 2.1. Пример использования метафоры в интерфейсе программы

Метафоры являются элементом, связывающим образы реального мира


с теми действиями и объектами, которыми приходится манипулировать
пользователю при его работе на компьютере. Пользователи запоминают
действие, связанное со знакомым объектом, более легко, чем они запомнили
бы имя команды, связанное с этим действием.
Метафора разрабатывается, как правило, в процессе концептуального
дизайна интерфейса, который включает три основные задачи:
 разработку системы интерфейсных элементов, своего рода алфавита
взаимодействия, изучив который пользователь сможет легко выполнять
необходимые действия;
 выбор способа изображения как отдельных элементов, так и их групп;
 выбор общего изобразительного стиля, легко узнаваемого и приятного
для глаз.
2. Согласованность интерфейса позволяет пользователям переносить
имеющиеся знания на новые задания, осваивать новые аспекты быстрее, и
благодаря этому фокусировать внимание на решаемой задаче, а не тратить
время на уяснение различий в использовании тех или иных элементов
управления, команд и т. д. Обеспечивая преемственность полученных ранее
знаний и навыков, согласованность делает интерфейс узнаваемым и
предсказуемым.
Согласованность важна для всех аспектов интерфейса, включая имена
команд, визуальное представление информации и поведение интерактивных
элементов. Для реализации свойства согласованности в создаваемом
программном обеспечении необходимо учитывать его различные аспекты:
– согласованность в пределах продукта. Одна и та же команда должна
выполнять одни и те же функции, где бы она ни встретилась, причем одним и
тем же образом;
– согласованность в пределах рабочей среды. Поддерживая
согласованность с интерфейсом, предоставляемым операционной системой,
приложение может опираться на знания и навыки пользователя, которые он
получил ранее при работе с другими приложениями;
– согласованность в использовании метафор. Если поведение
некоторого программного объекта выходит за рамки того, что обычно
подразумевается под соответствующей ему метафорой, у пользователя могут
возникнуть трудности при работе с таким объектом.
3. Дружественность интерфейса. Пользователи обычно изучают
особенности работы с новым программным продуктом методом проб и
ошибок. Эффективный интерфейс должен принимать во внимание такой
подход. На каждом этапе работы он должен разрешать только
соответствующий набор действий и предупреждать пользователей о тех
ситуациях, где они могут повредить системе или данным; также у
пользователя должна быть возможность отменить или исправить
выполненные действия.
Даже при наличии хорошо спроектированного интерфейса пользователи
могут делать те или иные ошибки. Эти ошибки могут быть как
«физического» типа (случайный выбор неправильной команды или данных),
так и «логического» (принятие неправильного решения на выбор команды
или данных). Эффективный интерфейс должен позволять предотвращать
ситуации, которые, вероятно закончатся ошибками. Он также должен уметь
адаптироваться к потенциальным ошибкам пользователя и облегчать ему
процесс устранения последствий таких ошибок.
4. Принцип «обратной связи». Всегда необходимо обеспечивать
обратную связь для действий пользователя. Каждое действие пользователя
должно получать визуальное, а иногда и звуковое подтверждение того, что
программное обеспечение восприняло введенную команду. При этом вид
реакции, по возможности, должен учитывать природу выполненного
действия.
Обратная связь эффективна в том случае, если она реализуется
своевременно, т. е. как можно ближе к точке последнего взаимодействия
пользователя с системой. Когда компьютер обрабатывает поступившее
задание, полезно предоставить пользователю информацию относительно
состояния процесса, а также возможность прервать этот процесс в случае
необходимости.
5. Простота интерфейса. Интерфейс должен быть простым. При этом
понимается обеспечение легкости в его изучении и использовании. Кроме
того, он должен предоставлять доступ ко всему перечню функциональных
возможностей, предусмотренных данным приложением. Реализация доступа
к широким функциональным возможностям и обеспечение простоты работы
противоречат друг другу. Разработка эффективного интерфейса призвана
сбалансировать эти цели.
Один из возможных путей поддержания простоты – представление на
экране информации, минимально необходимой для выполнения
пользователем очередного шага задания. Многословные командные имена
или сообщения, непродуманные или избыточные фразы затрудняют
пользователю извлечение существенной информации.
Другой путь к созданию простого, но эффективного интерфейса –
размещение и представление элементов на экране с учетом их смыслового
значения и логической взаимосвязи. Это позволяет использовать в процессе
работы ассоциативное мышление пользователя.
Можно помочь пользователям управлять сложностью отображаемой
информации, используя последовательное раскрытие (диалоговых окон,
разделов меню и т. д.). Последовательное раскрытие предполагает такую
организацию информации, при которой в каждый момент времени на экране
находится только та ее часть, которая необходима для выполнения
очередного шага. Сокращая объем информации, представленной
пользователю, уменьшают объем информации, подлежащей обработке.
Примером такой организации является иерархическое (каскадное) меню,
каждый уровень которого отображает только те пункты, которые
соответствуют одному, выбранному пользователем, пункту более высокого
уровня.
6. Гибкость интерфейса – это его способность учитывать уровень
подготовки и производительность труда пользователя. Гибкость
предполагает возможность изменения структуры диалога и/или входных
данных. Концепция гибкого (адаптивного) интерфейса в настоящее время
является одной из важных областей исследования взаимодействия человека и
ЭВМ. Основная проблема состоит не в том, как организовать изменения в
диалоге, а в том, какие признаки нужно использовать для определения
необходимости внесения изменений и их сути.
7. Эстетическая привлекательность. Проектирование визуальных
компонентов является важнейшей составной частью разработки
программного интерфейса. Корректное визуальное представление
используемых объектов обеспечивает передачу весьма важной
дополнительной информации о поведении и взаимодействии различных
объектов. В то же время следует помнить, что каждый визуальный элемент,
который появляется на экране, потенциально требует внимания
пользователя, которое не безгранично. Следует формировать на экране среду,
которая не только содействовала бы пониманию пользователем
представленной информации, но и позволяла бы сосредоточиться на
наиболее важных ее аспектах.
Наибольших успехов в проектировании пользовательского интерфейса,
обладающего перечисленными свойствами, к настоящему времени добились
разработчики компьютерных игр.
Качество интерфейса сложно оценить количественными
характеристиками, однако более или менее объективную его оценку можно
получить на основе приведенных ниже частных показателей.
1. Время – необходимо определенному пользователю для достижения
заданного уровня знаний и навыков по работе с приложением (например,
непрофессиональный пользователь должен освоить команды работы с
файлами не более чем за 4 ч).
2. Сохранение полученных рабочих навыков по истечении некоторого
времени (например, после недельного перерыва пользователь должен
выполнить определенную последовательность операций за заданное время).
3. Скорость решения задачи с помощью данного приложения; при этом
должно оцениваться не быстродействие системы и не скорость ввода данных
с клавиатуры, а время, необходимое для достижения цели решаемой задачи.
Исходя из этого, критерий оценки по данному показателю может быть
сформулирован так: пользователь должен обработать за час не менее 20
документов с ошибкой не более 1%.
4. Субъективная удовлетворенность пользователя при работе с
системой (которая количественно может быть выражена в процентах или
оценкой по
n-балльной шкале).
Обобщая изложенное, можно кратко сформулировать те основные
правила, соблюдение которых способствует проектированию эффективного
пользовательского интерфейса:
– интерфейс пользователя необходимо проектировать и разрабатывать
как отдельный компонент создаваемого приложения;
– необходимо учитывать возможности и особенности аппаратно-
программных средств, на базе которых реализуется интерфейс;
– целесообразно учитывать особенности и традиции той предметной
области, к которой относится создаваемое приложение;
– процесс разработки интерфейса должен носить итерационный
характер, его обязательным элементом должно быть согласование
полученных результатов с потенциальным пользователем;
– средства и методы реализации интерфейса должны обеспечивать
возможность его адаптации к потребностям и характеристикам пользователя.

Этапы проектирования пользовательского интерфейса


При проектировании пользовательского интерфейса исходным решени-
ем является выбор базовых стандартов типов управляющих средств интер-
фейса, который должен учитывать специфику соответствующей предметной
области.
Проектирование пользовательского интерфейса может осуществляться как
отдельно, так и совместно с остальным процессом разработки продукта.
Однако сейчас больше внимания уделяется элементам интерфейса и
объектам, воспринимаемым и используемым пользователями, а не
функциональности программы.
Во многих проектах собственно разработка пользовательского интерфейса
и программирование продукта ведутся параллельно, особенно на ранних
стадиях. На более поздних этапах учитываются требования пользовательского
интерфейса и обратной связи, выявляемые в результате тестирования на
удобство применения.
Процесс состоит из трех основных этапов и имеет итерационный
характер [3]:
 первоначальное проектирование пользовательского интерфейса;
 прототипирование пользовательского интерфейса;
 тестирование качества созданного пользовательского интерфейса.
Данный алгоритм может использоваться как при разработке объектно-
ориентированных пользовательских интерфейсов, так и при проектировании
традиционных проблемно-ориентированных интерфейсов или графических
пользовательских интерфейсов. Этот процесс не зависит от аппаратной и
программной платформ, операционной системы и применяемого
инструментария.
При первоначальном проектировании пользовательского интерфейса
системы закладываются основные концепции информационной системы,
влияющие абсолютно на все показатели качества её интерфейса, т. е. чем
больше внимания будет уделено проектированию, тем выше будет общее
качество.
Процесс проектирование состоит из следующих этапов [6]:
1. Определение необходимой функциональности системы;
2. Создание пользовательских сценариев;
3. Проектирование общей структуры интерфейса;
4. Создание глоссария.
5. Сборка и начальная проверка полной схемы интерфейса системы.
Каждый последующий этап в такой системе зависит от результатов
предыдущих этапов. Соответственно, пропуск какого-либо этапа (за
исключением, разве что, создания глоссария) негативно влияет на результаты
всех последующих этапов.
1. Определение необходимой функциональности системы –
осуществляется двумя основными способами: анализ целей и анализ
действий пользователей. В процессе определения функциональности
желательно использовать оба способа.
Анализ целей пользователей предполагает простое соображение,
гласящее, что людям не нужны инструменты сами по себе, нужны лишь
результаты их работы. Результатом этого процесса является список целей.
Анализ стоящих перед пользователем задач – это определение того,
чего хотят пользователи и каким образом они собираются решать свои
задачи.
Независимо от метода анализа задач необходимо ответить на следу-
ющие вопросы [5]:
1. Какие задачи решают пользователи?
2. Какие задачи являются наиболее важными?
3. Какие шаги предпринимаются для решения задач?
4. Какие цели преследуют пользователи при решении тех или иных
задач?
5. Какой информацией необходимо располагать для выполнения задач?
6. Какой инструментарий (компьютеры и т. д.) используется для
решения задач?
7. Каков ожидаемый итог от решения задачи?
8. Каким образом пользователи выполняют свою работу (вручную, на
компьютере, по телефону и т. д.)?
9. Каким образом они взаимодействуют с другими лицами при решении
задач?
10. Каким образом задачи учитываются в общем бизнес-процессе?
11. Как часто пользователям приходится решать задачи?
12. Каким образом компьютер или другая компьютерная техника
помогает пользователям в решении задач?
Анализ и сбор требований, предъявляемых пользователями, отвечают на
вопрос: «Какую пользу, с точки зрения пользователя, принесет
предлагаемый им продукт или интерфейс?». Практически во всех проектах
программного обеспечения учитываются требования пользователей, что
помогает определить особенности проекта и структуру пользовательского
интерфейса. Ключевыми в данном контексте являются следующие вопросы:
1. Какие основные технологии требуются пользователям?
2. Сколько пользователи и менеджеры готовы заплатить за продукт?
3. Кто устанавливает продукт?
4. Кто будет сопровождать продукт, когда он будет установлен?
Анализ среды пользователя отвечает на вопрос: «Где пользователи ре-
шают стоящие перед ними задачи?», т. е. необходимо определить
характеристики среды, которые могут оказывать влияние на выполнение
пользователями своей работы:
 физической стороны рабочей среды (освещение, шум, рабочее
пространство, температура, наличие компьютеров, телефонов, количество
персонала и т. д.);
 место работы пользователя и степень его мобильности (офис,
квартира, стационарно, с передвижениями и т. д.);
 вопросов эргономики, условий труда (задействуются ли зрение, слух,
работа ведется стоя/сидя, на клавиатуре и т. д.);
 особых запросов (уровень подготовки, физическое состояние,
интерес к познавательному процессу, особенности речи и возможные
недостатки).
Анализ соответствия требований стоящим перед пользователями
задачам – это проверка на их реалистичность. Если требования
пользователей не соразмерны выполняемым задачам, необходимо
предложить оптимальный вариант. При этом нужно проверить, не
превышают ли возможности продукта действительные потребности клиента.
Проанализировав задачи, стоящие перед пользователями, и их
требования, можно понять, какие элементы интерфейса потребуются и как их
расположить.
После того, как истинные цели пользователей установлены, необходимо
выбрать конкретный способ реализации функции, для чего используется
второй метод.
Анализ действий пользователей предполагает, что достижение всех
целей требует от пользователей совершения определенных действий.
Указанные сведения можно получить, анализируя информацию,
поступающую от пользователей. С этой целью производят опрос целевой
аудитории и формируют профили пользователей [3].
Профилями называют описания главных категорий пользователей. Одна
из таких категорий может быть принята за основной профиль. Следует
отметить, что набор характеристик, подробно описывающий пользователя,
зависит от предметной области и контекста решаемых им задач. Поэтому
работа по определению целей, задач пользователей, а также работа по
формированию их профилей ведется параллельно.
Наиболее общий шаблон профиля содержит в себе следующие разделы
[6]:
 социальные характеристики;
 навыки и умения работы с компьютером;
 мотивационно-целевая среда;
 рабочая среда;
 особенности взаимодействия с компьютером (специфические
требования пользователей, необходимые информационные технологии и др.).
Профили пользователей могут по необходимости расширяться за счет
добавления других (значимых с точки зрения проектировщика) характеристик
пользователей. Пример формирования профилей пользователей
информационной системы фирмы по изготовлению и поставке товаров
представлен в табл. 2.1
Таблица 2.1
Примерные профили категорий пользователей
Представители
Менеджер
Пользователи обслуживающего
по направлению товара
персонала
Социальные Мужчины, женщины Женщины
характеристики Взрослые Взрослые
Русскоязычные Русскоязычные
Средний уровень владения Низкий уровень владения
компьютером компьютером
Мотивационно– Прямая производственная Производственная
целевая среда необходимость, удобство. необходимость. Престиж.
Мотивация к обучению Мотивация к обучению низкая
высокая.
Навыки Должны иметь Прошли предварительное
и умения значительный опыт работы обучение по работе с
с программой. программой
Окончание табл. 2.1
Представители
Менеджер
Пользователи обслуживающего
по направлению товара
персонала
Требования Возможность использования Возможность использования
к программному программного обеспечения программы одновременно с
обеспечению системы в локальной сети. телефонным общением с
информационной клиентом.
Отсутствие жестких
системы Время реакции программного
ограничений по времени.
обеспечения системы,
Обеспечение текущей
допустимое для ожидания
информацией по
клиента.
содержанию заказов.
Обеспечение текущей Обеспечение текущей
информацией по товарам. информацией по содержанию
заказов.
Возможность проводить
Обеспечение текущей
обобщение информации
по заказам информацией по товарам.
Возможность формирования
новых заказов
Задачи Просмотр / фильтрация Просмотр данных по товарам.
пользователя информации по заказам /
клиентам / товарам. Создание / поиск / модификация
Сортировка информации по заказа.
заказам / клиентам / товарам. Сохранение / печать заказа.
Агрегирование информации Формирование счета по заказу
по заказам / клиентам /
товарам
Рабочая среда Стандартизированные ПК, Стандартизированные ПК,
локальная сеть специализированное
телефонное обслуживание

После выделения одного или нескольких основных профилей


пользователей и после определения целей и задач, стоящих перед ними,
переходят к следующему этапу проектирования.
2. Составление пользовательских сценариев начинается с присвоения
каждому профилю условного имени, затем формулируются сценарии.
Пользовательский сценарий – это словесное описание взаимодействия
пользователя с системой без конкретизации самого процесса, но включающее
возможно большее количество целей пользователя. Каждую из них
пользователь может решать несколькими способами, следовательно, должно
быть сформировано несколько сценариев. Количество сценариев может быть
произвольным, главное, что они должны включать все типы задач, стоящих
перед системой. Чем больше будет сценариев, тем ниже вероятность того, что
некоторые ключевые объекты и операции будут пропущены при
проектировании интерфейса системы.
Один из пользовательских сценариев взаимодействия с программой для
работы с электронной почтой будет выглядеть следующим образом:
запустить почтовую программу, скачать новую почту, получив почту,
прочитать все сообщения, затем часть их удалить, а на одно сообщение
ответить, после чего закрыть почтовую программу.
Исходя из задач каждого профиля пользователей, можно сформировать
перечень функций необходимых в приложении, а также определить тип
диалога, реализуемого в интерфейсе (табл. 2.2) [3].
Наряду с указанными критериями выбора в таблице, в нее могут быть
включены и другие, например: наличие инструментальных средств
разработки интерфейса, характер пользователя, ограничения по имеющимся
ресурсам и т. д.
Таблица 2.2
Выбор диалога
Тип диалога
Выбор
Заполнение
Критерии пользо- Вопрос- Язык
Меню экранных
вателя ответ команд
форм
Цель:
Запрос + + + +
Вычисления + + + +
Сложный выбор + +
Ввод данных + +
Ввод данных (большой
+ + + +
объем)
Тип пользователя:
Программист + +
Непрограммист + +
Имеет опыт работы + + * *
Нет опыта работы + +
Время обучения:
Очень малое + +
Менее 1 дня + + ** **
Более 1 дня + +
Результат оценки
* – использование этого типа диалога данной категорией пользователей требует
наличия системы помощи;
** – использование средств системы возможно только в ограниченном объеме.
Выбор наиболее подходящей структуры диалога на основе табл. 2.2
выполняется следующим образом:
1. Закрываются графы «Тип диалога»;
2. В графе «Выбор пользователя» выбираются критерии, относящиеся
к проектируемым задачам;
3. Для каждого типа диалога подсчитать число случаев, когда выбраны
соответствующие пункты и в графе «выбор пользователя», и в графе «тип
диалога»;
4. Подсчитать число совпадений для каждого типа диалога.
Основная ценность таблицы состоит в том, что ее можно использовать
как исходный вариант выбора типа диалога, либо как средство
окончательной проверки соответствия выбранного типа диалога
рассматриваемым критериям.
Если предполагается, что одни пункты более важны чем другие, можно
брать их с разными весовыми коэффициентами. Можно также указать, какие
пункты должны рассматриваться как выполняемые безусловно. Типы
диалога, не соответствующие хотя бы одному из таких пунктов, должны
отвергаться, сколько бы очков они ни набрали по остальным пунктам.
3. Проектирование общей структуры заключается в выделении
отдельных функциональных блоков и определении, как именно эти блоки
связываются между собой [6].
В информационной системе функция представляется функциональным
блоком с соответствующей экранной формой (формами). Как правило,
несколько связанных по назначению или области применения функций
объединяются в один функциональный блок программы. В случае
проектирования сайта функциональным блоком будет считаться группа
функций или фрагментов информационного наполнения (рис. 2.2). Таким
образом, на этом этапе устанавливается необходимое число экранных форм.

Рис. 2.2. Типичная структура сайта и программы

Если сайты обычно разветвлены, т. е. функции размещаются на


отдельных экранах, то программы имеют только один изменяющийся экран,
в котором и размещаются почти все функции.
Проектирование общей структуры интерфейса состоит из двух
параллельно происходящих процессов: выделения независимых блоков и
определения связи между ними.
При выделении независимых блоков следует избегать размещения в
одном блоке трех функций, поскольку каждый блок в результирующей
системе будет заключен в отдельный экран или группу управляющих
элементов.
Результатом этой работы должен быть список блоков с необходимыми
пояснениями (табл. 2.3).
Таблица 2.3
Определение связи между блоками интерфейса
Основной экран Навигация между функциями системы
Функция 1… Переход в форму 1….
…… ……
Функция N Переход в форму N…..

Существует три основных вида смысловой связи между блоками:


– логическая связь – определяет взаимодействие между фрагментами
системы с точки зрения разработчика (суперпользователя). Следует помнить,
что полученные связи очень существенно влияют на навигацию в пределах
системы (особенно, когда система многооконная). Чтобы не перегружать
интерфейс, стоит избегать как отдельных блоков, так и блоков, связанных с
большим количеством других. На практике установлено, что наиболее
оптимальное число связей для одного блока равняется трем;
– связь по представлению пользователей – тип связи между блоками,
основанный не только на точке зрения разработчика, но и на точке зрения
представлениях профилей пользователей. Этот тип связи обусловлен тем, что
самый распространенный способ поиска по классификации признаков,
работает только тогда, когда пользователи согласны с принципами этой
классификации;
– процессуальная связь – это жестко определенная последовательность
выполнения функций между соответствующими функциональными блоками.
В этом случае их экранные формы вызываются последовательно одна из
другой. Такие случаи имеют место не всегда, поэтому навигационные связи
формируются либо исходя из логики обработки данных, с которыми работает
приложение, либо основываясь на представлениях пользователей.
Навигационные связи между отдельными функциональными блоками
отображаются на схеме навигационной системы. Возможности навигации в
приложении передаются через различные навигационные элементы.
Результатом этого этапа проектирования интерфейса программы
является общая схема (рис. 2.3).
Рис. 2.3. Пример общей схемы сайта

4. Создание глоссария. В процессе проектирования интерфейса


необходимо зафиксировать все используемые в системе понятия. Для этого
нужно просмотреть все созданные экраны (формы) и выписать из них все
уникальные понятия (например, текст с кнопок, названия элементов меню и
окон, названия режимов и т. д.). После этого к получившемуся списку нужно
добавить определения всех концепций системы (например, книга или
изображение).
Далее получившийся список понятий дорабатывается и улучшается
следующим образом:
– уменьшается длина всех получившихся элементов;
– показывается получившийся список любому потенциальному
пользователю системы и спрашивается, как он понимает каждый элемент.
Если текст какого-то элемента воспринимается неправильно, его нужно
заменить;
– проверяется, чтобы одно и то же понятие не называлось в разных
формах или экранах по-разному;
– проверяются понятия на совпадение стиля названия функций со
стилем для выбранной платформы, т. е. если программа разрабатывается для
платформы MS Windows, то следует опираться на название понятий,
используемых в ней;
– проверяется, чтобы на всех командных кнопках текст был в форме
глаголов-инфинитивов, например, открыть, сохранить, копировать и т. д.
5. Сборка и начальная проверка полной схемы интерфейса системы
основываются на общей схеме интерфейса системы, планах отдельных
экранов (форм), созданном глоссарии. Схема, показывающая, какие
элементы системы входят в пользовательский интерфейс, представлена на
рис. 2.4.

Рис. 2.4. Общая схема интерфейса

В процессе создания полной схемы интерфейса можно увидеть


сделанные ошибки и легко исправить их. Выполнение полной схемы может
осуществляться в любом графическом редакторе.
Последней задачей проектирования интерфейса информационной
системы является его проверка внутренней логики по сценарию, т. е.
проверка схемы по сценарию. Дело в том, что всегда существует вероятность
ошибок, исправить которые лучше всего до построения прототипа
интерфейса. Хотя многие структурные ошибки нельзя найти никакими
методами, кроме длительного логического анализа, но практически все
ошибки, что находятся во время такой проверки, являются существенными.
Суть проверки схемы по пользовательским сценариям заключается в
том, чтобы описать, как все профили пользователей будут взаимодействовать
с системой по данной схеме, не пропуская ни одного элемента управления.
После чего сверяется полученный текст со схемой.
Весьма эффективным средством оценки получающегося интерфейса
является его экспертная оценка [3]. Часто оказывается, что сравнительно
дорогое тестирование показывает то, что было бы легко видно эксперту,
вооруженному соответствующим опытом и квалификацией. Хотя экспертная
оценка не может быть полноценной заменой тестирования, она обладает
одним существенным преимуществом – для её проведения не требуется
прототип. Это значит, что эксперт может быть приглашен на ранних стадиях
работы, когда польза от обнаружения ошибок максимальна.
Для проведения экспертной оценки нужно знать следующее:
– разные люди обнаруживают разные ошибки. Это значит, что метод
работает лучше, когда количество экспертов больше единицы;
– лучше привлекать несколько экспертов не одновременно, но
последовательно;
– чем больше информации о проектируемой системе будет
предоставлено эксперту, тем более сложные проблемы он сможет выявить.
На втором этапе при создании прототипа интерфейса нет
необходимости делать его возможно более похожим на конечную систему,
так как в большинстве случаев после тестирования прототип оказывается
неправильным [5]. После обнаружения каждой ошибки схема и прототип
интерфейса исправляются, и тестирование продолжается уже на новом
прототипе. Таким образом, прототип претерпевает множество исправлений и,
соответственно, создается много различных версий.
Первый прототип стоит делать максимально простым и создавать его на
бумаге (рис. 2.5). Польза начального прототипирования на бумаге
заключается, во-первых, в исключительной простоте модификации по
результатам тестирования, а во-вторых, в возможности безболезненно
выявлять представителей целевой аудитории. После обнаружения каждой
ошибки схема и прототип исправляются, а тестирование продолжается уже
на новом прототипе.
После исчерпания возможностей бумажной версии прототипа стоит
создать новую версию. Для этого точно так же рисуется интерфейс, но уже не
на бумаге, но в какой-либо презентационной программе (MS PowerPoint,
например). При этом каждый экран получает отдельный слайд, а результат
нажатия кнопок имитируется переходами между слайдами.
С этой версией прототипа можно тестировать значительно более
сложное взаимодействие человека с системой, нежели с бумажной. Однако
исправление найденных ошибок значительно более трудоемко. Фактически
для большинства систем этой версии оказывается достаточно.
В тех случаях, когда в интерфейсе появляются нестандартные элементы
или необходимо проверить реальную скорость взаимодействия пользователя
с системой, создается еще одна версия прототипа – реально выглядящая, но
лишенная каких-либо алгоритмов и соответственно не показывающая
реальных данных. Делать этот вариант можно как в средах разработки, в них
есть визуальные инструменты создания интерфейсов, так и в редакторах
изображений, что обычно быстрее (рис. 2.6).
Фактически при этом создаются фальшивые снимки экрана, на которых
и производят тестирование. Понятно, что существенно модифицировать эти
экраны затруднительно, так что лучше не увлекаться такой работой, не
получив каких-либо гарантий ее правильности.
Рис. 2.5. Бумажный прототип интерфейса сайта

Рис. 2.6. Реально-выглядящий прототип интерфейса сайта


Иногда необходимо тестировать взаимодействие пользователя не только
с интерфейсом системы, но и с обрабатываемыми системой данными.
(например, работая с графической программой, пользователь не только
нажимает на экранные кнопки, но также создает и модифицирует
изображения мышью). Область же редактирования данных зачастую вообще
не содержит каких-либо визуальных интерфейсных элементов, из чего вовсе
не следует, что интерфейса в ней нет, его, наоборот, много, но счет в нем
идет не на кнопки и переключатели, но на пиксели и миллисекунды.
Понятно, что создание прототипа в таких условиях не поможет,
поскольку прототип вообще не будет отличаться от проектируемой системы.
В таких условиях лучше всего проводить тестирование уже на реальной
системе.
Тестирование и модификация интерфейса системы осуществляется на
последнем этапе для получения подтверждения его работоспособности.
Залогом успешного тестирования является правильная постановка задачи.
Процесс тестирования осуществляется довольно просто: нескольким
пользователям, которые ни разу не видели текущего состояния системы,
дается задание, они его выполняют, после чего результаты анализируются.
Проверка посредством наблюдения за пользователем – это один из
самых простых видов тестирования. Пользователю дается задание, он его
выполняет, его действия фиксируются для дальнейшего анализа какой-либо
программой записи состояния экрана.
Чтобы пользователь не тревожился и не стеснялся, его лучше всего
оставить в одиночестве. Метод исключительно полезен для выявления
неоднозначности элементов интерфейса. Поскольку каждая неоднозначность
приводит к пользовательской ошибке, а каждая такая ошибка фиксируется,
то обнаружить их при просмотре записанного материала очень легко.
Этот тест замечательно подходит для поиска проблем интерфейса.
Кроме того, если замерять время выполнения задания (секундомером),
можно оценить производительность работы пользователей. Этот же метод
позволяет посчитать количество человеческих ошибок.
Метод «мыслим вслух» – довольно нестабильный, но порой дающий
интересные результаты (очень зависит от разговорчивости пользователя).
Соответствует проверке посредством наблюдения за пользователем, но при
этом его просят также устно комментировать свои действия. Затем
комментарии анализируются.
Метод позволяет легко определить недостатки реализации конкретных
интерфейсных идей (неудачно расположение элементов, плохая навигация).
Проверка качества восприятия – этот тест позволяет определить,
насколько легко интерфейсу обучиться. Поскольку существует разница
между понятиями видеть и смотреть, а запоминается только то, что
увидено, необходимо обладать уверенностью в том, что пользователь увидит
если не всё, то уж хотя бы всё необходимое.
Пользователю даётся для выполнения задание, связанное с каким-либо
отдельным диалоговым окном. Он выполняет. Через несколько минут
пользователя просят нарисовать (пускай даже грубо и некрасиво) только что
виденное им окно. После чего рисунок сравнивается с оригиналом.
Естественно пользователь запоминает только то, что ему кажется
актуальным в процессе работы с окном (плюс еще что-нибудь из того, что
ему показалось интересным). Это один из тех редких случаев, когда
срабатывает ограничение на объем кратковременной памяти, так что
количество запомнившихся элементов управления не может быть выше
порога. (например, пользователь, которому нужно сменить шрифт абзаца на
Arial из всего диалогового окна выбора шрифта в MS Word запоминает
только три элемента управления, хотя при этом он помнит, что помимо них
были и другие, но точно вспомнить остальные элементы он, как правило, не
может).
В самом начале работы, когда только создан прототип будущей
системы, он тестируется, после чего найденные ошибки исправляются. Затем
прототип тестируется опять. При этом опытность дизайнера проявляется
исключительно в уменьшении количества итераций. Соответственно
тестирование должно идти параллельно со всеми остальными операциями.
При этом следует отметить, что качество пользовательского интерфейса
является самостоятельной характеристикой программного продукта,
сопоставимой по значимости с такими его показателями, как надежность и
эффективность использования вычислительных ресурсов.

КОНТРОЛЬНЫЕ ВОПРОСЫ

1. Основы проектирования пользовательского интерфейса.


2. Принципы проектирования пользовательского интерфейса.
3. Этапы разработки пользовательского интерфейса. Коллективный
подход к разработке.
4. Определение профиля пользователей. Анализ стоящих перед
пользователями задач.
5. Сбор требований, предъявляемых пользователями. Анализ рабочей
среды пользователей.
6. Соответствие требований стоящим перед пользователями задачам.
7. Разработка сценария действий пользователей и задачи, стоящие перед
ними.
8. Создание пользовательских сценариев интерфейса информационной
системы. Что такое основной шаблон-профиль пользователя, какие разделы
содержит?
9. Выбор диалога для информационной системы.
10. Проектирование общей структуры интерфейса информационной
системы: выделение независимых блоков и определение связи между ними.
11. Типы связей между блоками интерфейса.
12. Проектирование отдельных блоков интерфейса информационной
системы.
13. Граф состояния меню. Определение объектов и операций.
14. Создание глоссария интерфейса информационной системы.
15. Сборка и проверка полной схемы интерфейса системы.
16. Этапы проверки схемы интерфейса информационной системы по
сценарию.
17. Метод экспертной оценки полной схемы интерфейса.
18. Построение прототипа интерфейса информационной системы.
19. Виды прототипов интерфейсов информационной системы
20. Методы тестирования и модификации прототипа интерфейса.

Вам также может понравиться