2.2. ЭТАПЫ ПРОЕКТИРОВАНИЯ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА

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

во-первых, участники диалога должны понимать язык друг друга;

во-вторых, они не должны говорить одновременно;

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

Если собеседники обсуждают вопросы, относящиеся к какой-либо специальной области, они должны придерживаться единой терминологии; если же один из них пытается что-то объяснить другому, ему следует сначала пояснить основные терми­ны и понятия.

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

Теперь давайте вспомним, чего не любят наши собеседники.

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

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

Таким образом, при проектировании пользовательского интерфейса необходи­мо определить:

Структуру диалога;

Возможный сценарий развития диалога;

Визуальные атрибуты отображаемой информации (синтаксис сообщений).

2.2.1. ВЫБОР СТРУКТУРЫ ДИАЛОГА

Выбор структуры диалога - это первый из этапов, который должен быть выпол­нен при разработке интерфейса.

Рассмотренные ниже четыре варианта структуры диалога являются разновид­ностями структуры типа «вопрос - ответ», тем не менее каждая из них имеет свои особенности и наиболее удобна для определенного класса задач.

ДИАЛОГ ТИПА «ВОПРОС - ОТВЕТ»

Структура диалога типа «вопрос-ответ» (Q&A) основана на аналогии с обыч­ным интервью. Система берет на себя роль интервьюера и получает информа­цию от пользователя в виде ответов на вопросы. Это наиболее известная струк­тура диалога; все диалоги, управляемые компьютером, в той или иной степени состоят из вопросов, на которые пользователь отвечает. Однако в структуре Q&A этот процесс выражен явно. В каждой точке диалога система выводит в качестве подсказки один вопрос, на который пользователь дает один ответ. В зависимости от полученного ответа система может решить, какой следующий вопрос задавать. Структура Q&A предоставляет естественный механизм ввода как управляющих сообщений (команд), так и данных. Никаких ограничений на диапазон или тип входных данных, которые могут обрабатываться, не на­кладывается. Существуют системы, ответы в которых даются на естественном языке, но чаще используются предложения из одного слова с ограниченной грамматикой.

Диалог в виде вопросов и ответов в достаточной степени обеспечивает поддер­жку пользователя, так как даже краткий наводящий вопрос при разумном построе­нии может быть самопоясняющим. Структура Q&A не гарантирует минимального объема ввода, оцениваемого по количеству нажатий клавиш, однако при подходя­щем подборе сокращений можно уменьшить любую избыточность. Вместе с тем, структура Q&A обладает одним существенным недостатком. Даже если ввод проис­ходит достаточно быстро, для человека, который уже знает, какие вопросы задает система и какие ответы нужно на них давать, отвечать на всю серию вопросов до­вольно утомительно.

С появлением графического интерфейса структура Q&A несколько устарела, тем не менее у нее имеются определенные достоинства. Эта структура может удовлетворить требования различных пользователей и типов данных. В частно­сти, такая структура особенно уместна при реализации диалога с множеством «ответвлений», т.е. в тех случаях, когда на каждый вопрос предусматривается большое число ответов, каждый из которых влияет на то, какой вопрос будет задан следующим. По этой причине структура Q&A часто используется в экс­пертных системах.

ДИАЛОГ НА ОСНОВЕ МЕНЮ

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

Существует несколько основных форматов представления менюна экране:

Список объектов, выбираемых прямым указанием, либо указаниемномера (или мнемонического кода);

Меню в виде блока данных;

Меню в виде строки данных;

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

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

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

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

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

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

Меню - это наиболее удобная структура диалога для неподготовленных поль­зователей; жесткая очередность открытия и иерархическая вложенность меню мо­жет вызывать раздражение профессионала, замедлять его работу. Традиционная структура меню недостаточно гибка и не в полной мере согласуется с методами адаптации диалога, такими, например, как опережающий ввод, с помощью которого можно ускорить темп работы подготовленного пользователя. Более подробно воп­росы организации и визуального представленияменю рассмотрены в разделе «Про­ектирование элементов управления».

ДИАЛОГ НА ОСНОВЕ ЭКРАННЫХ ФОРМ

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

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

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

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

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

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

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

ДИАЛОГ НА ОСНОВЕ КОМАНДНОГО ЯЗЫКА

Структура диалога на основе командного языка столь же распространена, что и структура типа меню. Она очень часто используется в операционных системах и располагается на другом конце спектра структур диалога по отношению к структуре типа меню. Исторически это первая из реализованных структур диалога.

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

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

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

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

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

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

Ключевые параметры уменьшают нагрузку на память пользователя в том отноше­нии, что отпадает необходимость в запоминании порядка их следования; кроме того, Можно опускать необязательные параметры. С другой стороны, в этом случае пользова­телю необходимо запомнить множество ключевых слов, а разработчику - подобрать для них «осмысленные» имена. Этот подход также требует большего времени работы системы, чтобы распознать ключевые слова, заданные в произвольном порядке.

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

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

Изложенное можно представить в форме так называемой «таблицы выбо­ра» (рис. 2.1).

Критерии	Выбор пользова­теля	Тип диалога
		меню	вопрос - ответ	язык команд	заполнение экранных форм
Цель: Запрос Вычисления Сложный выбор Ввод данных Ввод данных (большой объем)		+ + +	+ + + + +	+ + + + + +	+ + +
Тип пользователя: Программист Непрограммист Имеет опыт работы Нет опыта работы		+ +	+ +	+ + *	+ + *
Время обучения: очень малое Менее 1 дня Более 1 дня		+ +	+ +	** +	** +
Результат оценки

* - использование этого типа диалога данной категорией пользователей требует нали­чия системы помощи;

** - использование средств системы возможно только в ограниченном объеме.

Рис. 2.1. Вариант таблицы выбора

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

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

1. Закрыть графы «Тип диалога».

2. В графе «Выбор пользователя» пометить критерии, относящиеся к рассмат­риваемому применению.

Основная ценность таблицы состоит в том, что ее можно использовать как ис­ходный вариант выбора типа диалога, либо как средство окончательной проверки соответствия выбранного типа диалога рассматриваемым критериям.

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

2.2.2. РАЗРАБОТКА СЦЕНАРИЯ ДИАЛОГА

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

Целями разработки сценария диалога являются:

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

Выбор рациональных путей перехода из одного состояния диалога в другое (из текущего в требуемое);

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

Сложность разработки сценария определяется в основном двумя факторами:

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

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

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

использование смешанной структуры диалога (применение меню с целью «огра­ничения свободы» пользователя там, где это возможно);

применение входного контроля вводимой информации (команд и данных).

Дополнительные возможности по снижению неопределенности действий пользо­вателя предоставляет объектно-ориентированный подход к разработке интерфей­са, при котором для каждого объекта заранее устанавливается перечень свойств и допустимых операций. Наиболее эффективен такой подход при создании графи­ческого интерфейса; более подробно эти вопросы обсуждаются в разделе «Особен­ности графического интерфейса».

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

Способ описания сценария диалога зависит от степени его сложности. Суще­ствующие методы описания сценариев можно разделить на две большие группы:

неформальные и формальные методы.

Главное достоинство формальных методов состоит в том, что они позволяют автоматизировать как проектирование диалога, так и его модификацию (адапта­цию) в соответствии с характеристиками пользователя.

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

Независимо от способа описания сценария его основной структурной единицей является шаг диалога, соответствующий одному акту взаимодействия пользователя с системой. Схематично шаг диалога можно представить так, как показано на рис. 2.2.

Рис. 2.2. Шаг диалога

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

ТЕМП ВЕДЕНИЯ ДИАЛОГА

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

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

Темп ведения диалога зависит от характеристик аппаратных и программных средств ЭВМ, а такжеот специфики решаемых задач. Требование соответствия темпа ведения диалога психологическим особенностям человека выдвигает ограничения на значения этих характеристик не только «сверху», но и «снизу». Поясним это утверждение.

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

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

Требования к времени ответа зависят от того, что ожидает пользователь от рабо­ты системы, и от того, как взаимодействие с системой влияет на выполнение его заданий. Исследования показали [З], что если время ответа меньше ожидаемого, точность выбора операции из меню увеличивается с увеличением времени ответа системы. Это связано с тем, что излишне быстрый ответ системы как бы «подгоня­ет» пользователя, заставляет его суетиться в стремлении «не отставать» от более расторопного партнера по общению. Замечено, что начинающий пользователь боит­ся работать с системой, если, потратив несколько минут на ввод, он моментально получает от нее ответ с сообщением об ошибке.

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

Обычно человекможет одновременно запомнить сведения о пяти-девяти пред­метах. Считается также, что хранение данных в кратковременной памяти ограниче­но по времени: около 2 секунд для речевой информации и 30 секунд для сенсорной. Поэтому люди имеют склонность разбивать свою деятельность на этапы, соответ­ствующие порциям информации, которые они могут хранить одновременно в па­мяти. Завершение очередного этапа называется клаузой. Задержки, препятствую­щие наступлению клаузы, очень вредны и неприятны, так как содержимое кратковременной памяти требует постоянного обновления и легко стирается под влиянием внешних факторов. Зато после клаузы подобные задержки вполне при­емлемы и даже необходимы. Завершение задачи, ведущее к отдыху, называют зак­рытием. В этот момент исчезает необходимость дальнейшего хранения информа­ции и человек получает существенное психологическое облегчение. Так как пользователи интуитивно стремятся к закрытию в своей работе, следует делить диалоги на фрагменты, чтобы пользователь мог «вовремя» забывать промежуточ­ную информацию.

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

Имеющиеся результаты исследований позволили выработать следующие реко­мендации по допустимому времени ответа интерактивной системы:

0,1... 0,2 с - для подтверждения физических действий (нажатие клавиши, рабо­та со световым пером, «мышью»);

0,5... 1,0 с - для ответа на простые команды (например, от момента ввода команды, выбора альтернативы из меню до появления нового изображения на экране);

1... 2 с - при ведении связного диалога (когда пользователь воспринимает се­рию взаимосвязанных вопросов как одну порцию информации для формирования одного или нескольких ответов, задержка между следующими друг за другом воп­росами не должна превышать указанную длительность);

2... 4 с - для ответа на сложный запрос, состоящий в заполнении некоторой формы. Если задержка не влияет на другую работу пользователя, связанную с пер­вой, могут быть приемлемы задержки до 10 с;

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

МЕТОДЫ РАЗРАБОТКИ ГИБКОГО ИНТЕРФЕЙСА

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

Существуют три вида адаптации: фиксированная, полная и косметическая.

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

подробный (для начинающего пользователя);

краткий (для подготовленного пользователя).

Правило двух уровней может быть расширено до правила N уровней диалога. Однако такой подход имеет несколько недостатков:

1) не учитывается тот факт, что навыки накапливаются постепенно;

2) пользователь может хорошо знать одну часть системы и совсем не знать другую;

3) пользователь сам определяет уровень своей подготовки, что снижает объек­тивность оценки.

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

В настоящее время полная (автоматическая) адаптация практически ни водной диалоговой системе не реализована.

Косметическая адаптация призвана обеспечить гибкость диалога без учета пове­дения пользователя, но и без однозначного выбора им конкретного стиля диалога.

Такая адаптация может быть достигнута за счет применения следующих методов:

Использование умолчаний;

Использование сокращений;

Опережающий ввод ответов;

Многоуровневая помощь;

Многоязычность.

Использование умолчаний. Сущность умолчания состоит в том, что система использует некоторое изначально заданное значение какого-либо параметра, пока пользователь не изменит его. В этом случае имеют место два аспекта адаптации системы:

во-первых, начинающий пользователь имеет возможность использовать боль­шинство параметров системы по умолчанию,

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

Для удобства начинающих пользователей значения, используемые по умолча­нию, могут выводиться на экран вместе с соответствующим вопросом системы, например: «Дата регистрации документа? [текущая]».

Самый распространенный способ принятия значений по умолчанию - это нуле­вой ввод, т.е. простое нажатие клавиши «Ввод» в качестве ответа на вопрос систе­мы. Если используется командный язык, то пользователь просто пропускает пара­метр, используемый по умолчанию.

Использование сокращений предполагает, что пользователь вместо полного имени команды может вводить ее любое допустимое сокращенное обозначе­ние. На первый взгляд может показаться, что сокращенный ввод более удобен для начинающего пользователя. Но это не совсем так. Чтобы пользователь мог, не задумываясь, заменить команду корректным сокращением, он должен доста­точно хорошо представлять имеющийся набор команд, усвоить «лексику» си­стемы. Например, если в системе имеются команды Copy и Compare , то начи­нающему проще набрать полное имя, чем выбрать корректный вариант сокращения.

Одной из модификаций этого подхода является опережающий ввод символов, при котором система, «узнав» по первым символам команду, «дописывает» ее сама. Примером может служить интерфейс системы GPSS / PC , в которой при вводе на­чальных символов команды на экран выводится ее полное имя, а курсор автомати­чески перемещается в нужную позицию для ввода параметров этой команды. Разу­меется, пользователь, особенно начинающий, испытывает чувство «глубокой признательности» такой системе за «посильную помощь».

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

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

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

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

2.2.3. ВИЗУАЛЬНЫЕ АТРИБУТЫ ОТОБРАЖАЕМОЙ ИНФОРМАЦИИ

К визуальным атрибутам отображаемой информации относятся:

Взаимное расположение и размер отображаемых объектов;

Цветовая палитра;

Средства привлечения внимания пользователя. Проектирование размещения данных на экране предполагает выполнение следу­ющих действий:

1) Определение состава информации, которая должна появляться на экране;

2) Выбор формата представления этой информации;

3) Определение взаимного расположения данных (или объектов) на экране;

4) Выбор средств привлечения внимания пользователя;

5) Разработка макета размещения данныхна экране;

6) Оценка эффективности размещения информации.

Процесс проектирования повторяется до тех пор, пока разработчик и потенци­альные пользователи не будут удовлетворены.

Общие принципы расположения информации на экране должны обеспечивать для пользователя:

возможность просмотра экрана в логической последовательности;

простоту выбора нужной информации;

возможность идентификации связанных групп информации;

различимость исключительных ситуаций (сообщений об ошибках или предуп­реждений);

возможность определить, какое действие со стороны пользователя требуется (и требуется ли вообще) для продолжения выполнения задания.

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

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

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

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

оставлять пустым приблизительно половину экрана (окна);

оставлять пустую строку после каждой пятой строки таблицы;

оставлять четыре-пять пробелов между столбцами таблицы. Фрагменты текста должны располагаться на экране так, чтобы взгляд пользова­теля сам перемещался в нужном направлении. Содержимое полей должно не «при­жиматься» к краю экрана, а располагаться около его горизонтальных или верти­кальных осей. Меню, содержащее относительно небольшой объем информации, должно смещаться в левую верхнюю часть экрана. Чтобы подчеркнуть симметрию, содержимое и наименования полей, относящихся к одной группе, должны вырав­ниваться по вертикали. По возможности необходимо выравнивать все логически связанные группы данных.

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

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

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

Существуют ли объективные критерии оценки плотности заполнения экрана, сбалансированности данных и других показателей качества форматирования экра­на? Проблема заключается в том, что на любого человека, который смотрит на эк­ран, оказывает влияние содержание информации, затрудняя такую оценку. Один из возможных подходов к решению этой проблемы - отделить содержание от формы. Для этого применяются два метода - прямоугольников и выделенных точек.

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

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

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

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

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

Бежать читать книжки и гуглить статьи для вдохновения — не лучшая идея. Интерфейсы от чтения сами не проектируются и качественней не становятся. Конечно, теория — это хорошо, но, как и в любом деле, на теории «далеко не уедешь». К справочным материалам обращаться на начальном этапе тоже бессмысленно — это нужно делать с конкретными вопросами. И бесконечный перебор программ для проектирования не дает роста производительности.

Так что же делать, чтобы начать проектировать?

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

Без опыта и ответа на вопрос «С чего начать?» возникает страх. Что-то новое делать боязно, но и бесконечно сидеть без дела смысла нет. Первый блин все равно будет комом. Не бойтесь говорить о своем первом опыте. Любой интерфейс, который вы сделали, — будь он даже ужасен — все равно можно использовать.

Создаем истории

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

Чтобы понять, что мы имеем в виду под термином «история», давайте представим: Максим становится клиентом автосалона «Звезда Невы» — он купил себе новый автомобиль. При заключении договора в офисе компании сотрудники автосалона сообщают ему о существовании онлайн-системы для клиентов, где он может видеть свои платежи, оплаты по кредиту, напоминания про технический осмотр и страховку, а также новости автосалона.

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

При входе в систему Максим видит свой первый платеж в автосалоне, характеристики своего автомобиля, документы на авто, имя своего менеджера. Если его покупка попадает под действие какой-либо промоакции, то он увидит в системе оповещение об условиях акции (например, бесплатная мойка автомобиля класса «люкс» в течение августа).

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

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

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

Жгите глаголом

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

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

Дайте поиграть!

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

Базовые требования к веб интерфейсу сформулированы Якобом Нильсеном в виде , которые не теряют своей актуальности с 1990 года, когда они были впервые опубликованы. Впоследствии этот список был доработан, расширен, формализован и лег в основу

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

5 этапов создания интерфейса

В зависимости от потребностей клиента и степени готовности проекта мы можем проектировать:

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

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

Анализ

По порядку собираем, изучаем и анализируем всю нужную для создания веб интерфейса информацию:

1. Потребности бизнеса: для чего создается проект, какие бизнес-задачи он должен решать, как будет монетизироваться в дальнейшем.
2. Потребности аудитории: зачем проект аудитории, чего именно хотят пользователи, какие именно их проблемы и боли решает проект.
3. Базовые характеристики и уникальные преимущества проекта на уровне идеи: почему именно этот проект может решить задачу лучше, чем конкуренты, что для этого нужно.
4. Точки соприкосновения: в каком месте интересы аудитории и бизнеса пересекаются - ищем драйверы для создания оптимальных пользовательских сценариев.

Что именно мы изучаем:

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

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

Представление

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

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

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

Прототипирование

Непосредственное создание прототипа интерфейса веб-сайта, его отрисовка в Axure, графическом редакторе или любой другой программе. На этом этапе идеи и решения уже нужно

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

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

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

Хорошая новость: если найти и исправить недочеты на этом этапе, то их не придется исправлять в готовом продукте, что стоит на порядок дороже.

Дизайн и разработка

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

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

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

Аналитика

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

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

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

Итоговые выводы

• Базовые принципы проектирования интерфейсов описаны в эвристиках Нильсена и в стандарте ISO 9241-110.
• Проектирование осуществляется на трех уровнях: логика, функционал, графическое представление.
• В процессе можно выделить 5 этапов: предпроектный анализ, представление, прототипирование, дизайн и разработка, аналитика.
• Тестирование и проверка идей, теорий и решений - непрерывный процесс и начинается с того самого момента, когда у нас появляются первые скетчи и наброски прототипов.
• Готовый интерфейс тестируется как с привлечением респондентов, так и средствами веб-аналитики на реальных пользователях - по итогам тестов формируется техзадание для его последующей доработки.

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

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

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

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

Можно выделить 3 принципа разработки пользовательского интерфейса:

Контроль пользователем интерфейса;

Уменьшение загрузки памяти пользователя;

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

Правила:

Необходимо дать контроль пользователю . Опытные проектировщики позволяют пользователям решать некоторые задачи по-своему собственному решению. Но : необходимо наличие у пользователей необходимых навыков. Если задача решается не пользователем, то он должен иметь возможность контролировать процесс. Принципы, которые дают пользователю контроль над системой: 1) необходимо благоразумно использовать режим. 2) предоставить возможность пользователю выбрать: работать с мышью или клавиатурой, или с тем и другим вместе. 3) необходимо позволить пользователю сфокусировать внимание (прерываемость). 4) полезность: демонстрировать пользователю поясняющие советы и тексты. 5) немедленная обратная связь и обратные действия. 6) необходимо дать возможность пользователю свободно ориентироваться в интерфейсе. 7) интерфейс должен приспосабливаться к пользователям с разными уровнями навыков. 8) пользовательский интерфейс должен быть понятным (прозрачным), т.е. при хорошем интерфейсе пользователь его не воспринимает, а ощущает себя как бы внутри компьютера и может свободно манипулировать объектами.

Уменьшить нагрузку на память пользователя. Принципы: 1) не следует кратковременную память. Не следует вынуждать пользователей запоминать и выполнять то, что может сделать и компьютер. 2) необходимо полагаться на распознавание, а не на повторение. Необходимо предусматривать списки и меню, содержащие объекты или документы, которые можно выбрать. Не заставлять пользователей вводить информацию вручную без поддержки системы. 3) необходимо обеспечить визуальные подсказки. Пользователи должны знать, где они находятся, что делают, и что они могут сделать в дальнейшем. Когда пользователи находятся в каком-либо режиме, они должны быть информированы об этом посредствам соответствующих индикаторов. 4) необходимо предусмотреть функцию отмены последнего действия, его повтора и функции установки по умолчанию. Нужно использовать способность компьютера сохранять и отыскивать информацию о выборе пользователя и свойствах системы. Необходимо предусмотреть многоуровневые системы отмены и повтора команд. 5) необходимо реализовывать прямой доступ к элементам интерфейса с помощью клавиатуры. Как только пользователь хорошо освоит программный продукт, он начинает испытывать потребности в ускорителях. Однако, при их реализации нужно следовать стандартам. 6) необходимо использовать синтаксис действий с объектами: объектно-ориентированный синтаксис позволяет пользователю понять взаимосвязь между объектами и действиями в программном продукте. Объектно-ориентированный синтаксис был описан разработчиками Palo Alta Research Center (PARC). Xerex. 7) следует использовать метафоры реального мира.Метафоры позволяют переносить свои знания пользователям из реального мира в мир компьютеров. Если обнаружится, что метафора не отвечает своему назначению во всем интерфейсе, необходимо выбрать новую метафору. Если же метафора выбрана, то следует неукоснительно следовать ей во всем интерфейсе. 8) Нужно объяснять понятия и действия. Пользователи не должны сомневаться по поводу программного перехода. Не нужно показывать все функции, а только те, в которых есть потребность. Необходимо обеспечить легкий доступ к наиболее часто используемым функциям и действиям. Редко используемые функции следует скрыть и позволить пользователю вызывать их по мере необходимости. Для неподготовленных пользователей необходимо использовать режим «Мастер». 9) необходимо увеличить визуальную ясность. необходимо использовать принципы визуального проектирования для облегчения восприятия информации.

Последовательность пользовательского интерфейса. Пользователи могут переносить свои знания и навыки из одной программы в другую программу – это преимущества. Принципы создания совместимого интерфейса: 1) проектирование последовательного интерфейса. пользователь должен иметь опорные точки при перемещении в интерфейсе. Это заголовки окон, навигационные карты, древовидная структура. Кроме того, пользователь должен иметь возможность завершить поставленную задачу без изменения среды работы или переключение между стилями ввода данных. 2) общая совместимость всех программ. Совместимость реализуется на трех уровнях: подача информации; поведение программы; техника взаимодействия. Совместимость в подаче информации - пользователь может воспринимать информацию похожую в логическом, визуальном, физическом виде во всей программе. Совместимость в поведении – одни и те же объекты имеют одно и тоже поведение. совместимость в технике взаимодействия – способы работы с мышью и клавиатурой должны быть одинаковы во всех программах. 3) сохранение результатов взаимодействия – при выполнении одних и тех же действий должны получать одни и те же результаты. 4) эстетическая привлекательность и цельность. 5) поощрение изучения.

Интерфейсы.

Типы интерфейсов:

Графический пользовательский интерфейс: Graphical User Interface (GUI);

Web User Interface (WUI).

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

Существует 2 подхода к построению GUI:

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

Пользовательский интерфейс, ориентированный на приложение (функционально-ориентированный интерфейс).

WUI: взаимодействие с программой осуществляется через интернет по протоколу HTTP, т.е. ПО генерирует Web-страницу, которую пользователь просматривает и которую генерирует Web-браузер.

Другие типы интерфейсов:

Интерфейсы командной строки: ввод пользователь осуществляет с помощью клавиатуры, но система вывод осуществляет на экране компьютера (печатает текст).

Тактильные интерфейсы: реализуются через тактильную обратную связь. Широко применяются в компьютерных симуляторах.

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

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

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

Интерфейс жестов: это GUI, ввод в котором осуществляется в форме жестов руками или же с помощью мыши.

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

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

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

Текстовые ПИ. Отличаются от интерфейсов командной строки тем, что вводят текст, но применяют другие формы ввода.

Интерфейсы на базе естественных языков. Ввод осуществляется на естественном языке (поисковые системы).

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

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

История интерфейсов : первыми появились пакетные интерфейсы (1945-1968 гг.), затем – интерфейсы командной строки (1969-1980 гг.). в 1981 г. Появился GUI, осязаемые и сенсорные интерфейсы.

Стандартизация интерфейсов : в 2007 году был опубликован стандарт ISO/IEC 24752. Этот стандарт рассматривает требования к системам на основе информационных технологий. Common User Access (CUA) компании IBM – это наиболее полное руководство, определяющее стандарт для объектно-ориентированного пользовательского интерфейса.

Графический пользовательский интерфейс GUI .

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

Взаимосвязь GUI с объектно-ориентированным ПИ.

В ООПИ пользователь непосредственно взаимодействует с объектами, представляющими сущности в конкретной предметной области. Основные отличия: пользователь воспринимает и воздействует на объекты; пользователь может классифицировать объекты на основе их поведения. В ООПИ вначале выбирается объект, а затем действия над этим объектов.

Технология Naked Objects (чистые объекты) – это шаблон построения интерфейса пользователя.

В эту технологию заложены три идеи:

Вся бизнес-логика инкапсулируется в объектах предметной области;

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

ПИ на 100% создается автоматически, исходя из определения объектов предметной области.

Преимущества: сокращение цикла разработки; можно легко вносить изменения, следовательно, возникает гибкость; простой анализ требований пользователя.

Недостатки: ставится под сомнение инкапсуляция всей бизнес-логики в объектах предметной области. Это создаст трудности для масштабирования по быстродействию или приведет к созданию тесно взаимосвязанных объектов. Ставится под сомнение качество автоматически сгенерированных пользовательских интерфейсов. Критика направлена на конкретные реализации данного шаблона.

Технология Model-View-Controller (MVC). Одновременно это и шаблон для проектирования ПИ и шаблон для построения всей архитектуры приложения. Данный шаблон изолирует бизнес-логику от ПИ, давая возможность изменять одно, не затрагивая другое.

Описывается соотношение между моделью, представлением и 50 онтролером. Сплошные линии – прямая связь. Пунктирная линия – косвенная связь.

Модель - представляет собой информацию (данные), которыми оперирует приложение и бизнес-привила, используемые для манипуляции данными.

Вид (представление) – элементы ПИ (визуальные элементы оформления).

Контроллер – реализует передачу модели действий пользователя (нажатие клавиши, движения мышью и т.д.)

Описание шаблона

Шаблон для построения приложения. Обычно приложение разбивается на отдельные уровни, работающих на различных компьютерах.

Уровень представления;

Уровень бизнес-логики;

Уровень доступа к данным.

В MVC уровень представления разбивается на View и Controller. Web-приложение, где вид – это html-страница, а контроллер – это код, который обрабатывает динамические данные и генерирует содержимое html-страницы, модель представлена фактическими данными, хранимыми в базе данных, xml-файлах и т.д. бизнес-правило – правило, которое преобразует фактические данные в ответ на действия пользователя.

Сценарий работы программы:

Пользователь взаимодействует с ПИ (нажимает кнопку);

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

Контроллер информирует модель о действиях пользователя, приводя к изменению состояния модели.

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

ПИ ждет дальнейших действий пользователя.

Шаблон для проектирования.

Модель – это предметно-ориентированное представление информации, которой оперирует приложение.

Бизнес-логика наделяет смыслом сырые, необработанные данные. Во многих приложениях используется механизм сохранения состояния в базе данных. Часто для сохранения состояния модели в базе данных может использоваться библиотеки объектно-реляционного отображения.

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

Контроллер реагирует на события и обрабатывает их. Обычно это действия пользователя, но не всегда.

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

Проектирование ПИ состоит из следующих этапов:

Определение необходимой функциональности системы (анализ требований). Этот этап очень важен по своей сути. Традиционно определение функциональности системы исходит из отдела продаж. Для отдела продаж существует два источника информации (жалобы имеющихся клиентов и система конкурентов). Оба эти источника являются ненадежными. Также существует два метода анализа: 1) анализ целей пользователя : людям не нужны инструменты сами по себе, а им нужны результаты их работы. Основная задача – избежать ненужной конкретики, т.е. описанием, какова должна быть будущая функциональность. 2) анализ действий пользователя : этот метод заключается в наблюдении за людьми, выполняющими свою задачу, пользуясь уже имеющимися инструментами (это может быть система конкурентов и предметы реального мира). Кроме того, помимо действий необходимо анализировать и результаты работы. Нужно стремиться к минимизации количества функций. Существует два подхода к выделению функций: 1) рассматривается система в целом. выделяется максимальное количество функций, при этом результаты многих из функций являются суммой результатов других функций. 2) все составные функции из системы изымаются.

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

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

Логическая связь;

Связь по представлению пользователей;

Процессуальная связь.

Логическая связь определяет взаимодействие между блоками с точки зрения разработчика.

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

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

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

G OMS (Goals , Operators , Method and Selection rules – цели, операторы, методы и правила их выбора).

Цели – это просто цели пользователя.

Операторы – это те действия, которые программное обеспечение позволяет пользователю выполнять (например, действия мышью).

Методы – это последовательность знакомых пользователю действий, которые позволяют выполнять задачу.

Правила выбора – то, чем руководствуется пользователь.

Разработано в 1983г. Все действия пользователя можно разложить на составляющие. Ограничивая номенклатуру этих составляющих можно замерить время их выполнения на массе пользователей и получить статистически верные оценки их длительности. Для определения скорости решения любой задачи, зная продолжительность каждой составляющей, можно найти длительность всего процесса. Лучшим процессом будет тот, у которого время выполнения будет минимальным. Примеры методов: нажатие кнопки мыши – 0,1 сек; перемещение курсора мыши (модель Фиттса определяет время позиционирования курсора мыши в зависимости от расстояния до объекта и его размера) – в среднем 1,1 сек; взятие или бросание мыши – 0,4 сек; выбор действия – 1,2 сек; время реакции системы – от 0 до ∞.

Создание глоссария.

Сбор и начальная проверка полной схемы системы.

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

Пользовательские интерфейсы развивались в направлении повышения интеллектуализации. Основными такими направлениями являются:

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

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

ТЕОРИЯ АГЕНТОВ

Теория агентов (формализуема для описания агентов и выражения желаемых свойств этих агентов).

Методы кооперации агентов (для изучения способов кооперативного поведения агентов при совместном решении задач).

Архитектура агентов и многоагентных систем.

Языки программирования агентов.

Методы, языки и средства коммуникации агентов.

Методы и средства поддержки мобильности агентов.

Свойства агентов и терминология

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

При реализации агента можно содержать и аппаратные, и программные компоненты.

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

Самоконтроль (способность контролировать свои действия);

Автономность (способность работать без человека)

Общественное поведение (способность функционировать с другим агентом)

Реактивность (способность воспринимать окружающую среду и реагировать на ее изменения)

Способность агента брать на себя инициативу, т.е. генерировать цели и радикально действовать для из достижения.

Дополнительно от агента требуют наличия некоторого подмножества ментальных свойств: знаний (постоянная часть знаний агентов о себе и об окружающей среде, других агентах)

Убеждения – знания агента о среде и других агентах, которые могут манятся во времени, они могут становиться неверными.

Желания – состояние ситуации, достижение которой по разным причинам для агента является желательным. Желания агента могут быть противоречивыми, и агент не предполагает, что все они могут исполниться.

Намерения – это то, что агент должен сделать по обязательствам к другим агентам, либо то, что вытекает из его желаний (в соответствии с желаниями).

Цели – это множество конечных и промежуточных состояний, которые агент принял в качестве стратегии поведения.

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

Теория агентов изучает различные способы формирования описания агентов.

Для описания агентов используется следующее средство:

исчисления предикатов (имеются ограничения и полностью описать свойства агента невозможно)

использование метаязыков

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

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

Синтаксическая проблема

Семантическая проблема

Соответственно и язык формализации должен содержать как язык формализации, так и свою семантическую модель.

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

Для использования модальных логик при описании агентов предполагают разработку средств для описания временных аспектов «поведения» агентов. Для этого и разрабатываются расширения существующих модальных логик.

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

Модели коллективного поведения агентов

В случае взаимодействия агентов:

Агент не может решать поставленную задачу самостоятельно и обращается к другим агентам за помощью;

Одна большая сложная задача решается коллективом агентов.

Для того чтобы агент мог взаимодействовать должны быть решены следующие проблемы:

Формирование совместных планов действия

Учет интересов компаньонов агента

Синхронизация совместных действий

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

Распознавание необходимости коопераций

Выбор подходящего партнера

Обучение поведению в коллективе

Разделение обязанностей и декомпозиция задач

Разрешение конфликтных ситуаций и др.

Лекция 14.

Проектирование пользовательского интерфейса. Основные принципы и этапы проектирования пользовательского интерфейса: выбор структуры диалога, разработка сценария диалога, определение и размещение визуальных компонентов. Гибкие интерфейсы. Средства поддержки пользователя, справочные системы

Пользовательский интерфейс – это совокупность информационной модели проблемной области, средств и способов взаимодействия пользователя с информационной моделью, а также компонентов, обеспечивающих формирование ин­формационной модели в процессе работы программной системы (слайд 14.1) .

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

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

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

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

Согласно данному исследованию, интерфейс состоит из трех основных частей - подачи информации пользователю, взаимодействию и взаимосвязям между объектами. При этом «видимая» часть айсберга значительно меньше его «невидимой», скрытой части (слайд 14.2). Верх айсберга - информация для пользователей (цвет, анимация, звук, форма объектов, расположение информации на экране, графика) составляет всего 10% и является отнюдь не самой важной составляющей пользовательского интерфейса. Следующая часть пользовательского интерфейса (30% модели проектировщика) - это техника общения с пользователем и обратная связь с ним. И, наконец, нижняя часть айсберга (60%) модели проектировщика - наиболее важная его часть - это свойства объектов и связи между ними.

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

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

Для создания у пользователя такого ощущения «внутренней свободы» интер­фейс должен обладать целым рядом свойств (слайд 14.4) :

Естественность интерфейса.

Согласованность интерфейса.

Дружественность интерфейса (Принцип «прощения пользователя»)

Принцип «обратной связи».

Простота интерфейса.

Гибкость интерфейса.

Эстетическая привлекательность.

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

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

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

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

Согласованность в пределах рабочей среды. Поддерживая согласованность с интерфейсом, предоставляемым операционной сис­темой (например, ОС Windows), пользовательское приложение может «опираться» на те знания и навыки пользователя, которые он получил ранее при работе с другими приложениями.

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

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

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

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

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

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

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

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

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

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

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

Пользователь может переносить информацию из одного документа в другой путем включения нужных частей одного документа в соответствующие места другого документа. Это связывается с другой метафорой – «буфером вырезок». До появления систем автоматизированной обработки текстов был традиционный способ облегчения верстки: вклейка вырезанного фрагмента вместо перепечатывания страницы. WIMP-интерфейсы обеспечивают аналогичные возможности вырезки и вставки, но при этом буфер, в который помещается вырезанный фрагмент, дает возможность вставки стольких копий элементов данных, сколько требуется.

Метафорический принцип положен и в основу технологии WISIWIG - немедленную визуализацию на экране результатов действий. Это означает, что экран должен имитировать средства полиграфической печати, и если пользователь хочет напечатать часть текста курсивом, то он и на экране должен быть набран курсивом. Если файл уничтожается, то пользователь видит, что файл исчезает из изображенного на экране списка файлов. Интерфейс в естественной форме обеспечивает пользователя информацией о состоянии объекта, подтверждая, что действие было выполнено. Можно сказать, что эта метафора более точно соответствует формуле «Ты видишь то, что получил в результате своих действий» .

Гибкость интерфейса. Гибкость интерфейса - это его способность учитывать уровень подготовки и производительность труда пользователя. Свойство гибкости предполагает возможность изменения структуры диалога и/или входных данных. Концепция гибкого (адаптивного) интерфейса в настоящее время является одной из основных облас­тей исследования взаимодействия человека и ЭВМ. Основная проблема состоит не в том, как организовать изменения в диалоге, а в том, какие признаки нужно использовать для определения необходимости внесения изменений и их сути.

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

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

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

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

Скорость решения задачи с помощью данного приложения; при этом должнооцениваться не быстродействие системы и не скорость ввода данных с клавиатуры, авремя, необходимое для достижения цели решаемой задачи. Исходя из этого, критерий оценки по данному показателю может быть сформулирован, например, так: пользо­ватель должен обработать за час не менее 20 документов с ошибкой не более 1 %.

Субъективная удовлетворенность пользователя при работе с системой (которая количественно может быть выражена в процентах или оценкой по n-бальной шкале).