ГОСТ Р ИСО 9241-13-2016. Национальный стандарт Российской Федерации. Эргономические требования к проведению офисных работ с использованием видеодисплейных терминалов. Часть 13. Руководство пользователя

(утв. и введен в действие Приказом Росстандарта от 20.10.2016 № 1446-ст)

1 декабря 2017 года

Предисловие

1 ПОДГОТОВЛЕН Открытым акционерным обществом «Научно-исследовательский центр контроля и диагностики технических систем» (АО «НИЦ КД») на основе собственного перевода на русский язык англоязычной версии международного стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 201 «Эргономика, психология труда и инженерная психология»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 20 октября 2016 г. № 1446-ст

4 Настоящий стандарт идентичен международному стандарту ИСО 9241-13:1998 «Эргономические требования к проведению офисных работ с использованием видеодисплейных терминалов (VDT). Часть 13. Руководство пользователя» (ISO 9241-13:1998 «Ergonomic requirements for office work with visual display terminals (VDTs) — Part 13: User guidance», IDT).

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5 (пункт 3.5).

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

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

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

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

• более эффективного использования системы;
• снижения умственной нагрузки пользователя;
• помощи пользователям при обработке ошибок;
• помощи пользователям с различными уровнями навыков.

Настоящий стандарт полезен:

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

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

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

Рекомендации по использованию настоящего стандарта приведены в приложении А.

1 Область применения

В настоящем стандарте приведены рекомендации по разработке элементов руководства пользователя, относящихся к программным пользовательским интерфейсам и их проверке. Руководство пользователя в соответствии с настоящим стандартом является дополнительной информацией к обычному диалогу «пользователь — компьютер», которую система представляет пользователю по его запросу или автоматически. В дополнение к общим рекомендациям, приведенным в настоящем стандарте, рекомендации по руководству пользователя в зависимости от типа диалога приведены в ИСО 9241-12, ИСО 9241-14, ИСО 9241-15, ИСО 9241-16 <1>).

---

<1> При разработке следует также учитывать требования [47].

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

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

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

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

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ИСО 9241-12 Эргономические требования к проведению офисных работ с использованием видеодисплейных терминалов. Часть 12. Представление информации (ISO 9241-12 Ergonomic requirements for office work with visual display terminals (VDTs) — Part 12: Presentation of information)

ИСО 9241-14:1997 Эргономические требования к проведению офисных работ с использованием видеодисплейных терминалов. Часть 14. Диалоги, используемые в меню (ISO 9241-14:1997 Ergonomic requirements for office work with visual display terminals (VDTs) — Part 14: Menu dialogues)

ИСО 9241-15:1997 Эргономические требования к проведению офисных работ с использованием видеодисплейных терминалов. Часть 15. Диалоги команд/командные диалоги (ISO 9241-15:1997 Ergonomic requirements for office work with visual display terminals (VDTs) — Part 15: Command Dialogues)

ИСО 9241-16 Эргономические требования к проведению офисных работ с использованием видеодисплейных терминалов. Часть 16. Диалоги с прямым манипулированием (ISO 9241-16 Ergonomic requirements for office work with visual display terminals (VDTs) — Part 16: Direct manipulation dialogues)

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

3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1 независимая помощь (browsable help): Вид помощи (вспомогательной информации), доступ к которой не зависит от текущего состояния выполняемой задачи. Темы помощи могут быть просмотрены по желанию пользователя в любом порядке и любой последовательности.

3.2 контекстно-зависимая помощь (context-sensitive help): Вид помощи (вспомогательной информации), доступ к которой или диапазон тем раздела помощи зависит от информации, связанной с выполняемой пользователем задачей, последними введенными данными, выбранным объектом, текущим положением или текущим режимом работы системы или приложения.

3.3 ошибка (error): Ситуация, в которой реакция системы не соответствует цели пользователя. Ошибки делятся на ошибки навигации, синтаксические ошибки, концептуальные ошибки и т.д.

3.4 обработка ошибок (error management): Средства поддержки пользователя при обнаружении, объяснении и устранении ситуаций, вызывающих ошибки.

3.5 предотвращение ошибок (error prevention): Действия по снижению частоты возникновения ошибок.

3.6 обратная связь (feedback): Выход системы, предоставляемый пользователю в ответ на ввод данных пользователем, или сообщение о возникновении событий системы.

3.7 руководство, инструкция (руководящие принципы) (guidance): Элемент диалога, включающий рекомендации, помогающие пользователю получить желаемый результат. Руководство может помочь пользователю выявить новые возможности системы, составить план достижения своей цели, оказать помощь в достижении цели управлять ситуацией в случае возникновения ошибок.

3.8 онлайн-помощь, онлайн-справка (on-line help): Дополнительная информация руководства пользователя помимо подсказок/запросов, обратной связи, сообщений о состоянии и ошибках, которая может быть предоставлена по инициативе пользователя или по инициативе системы, как правило, содержит информацию об особенностях системы и диалога и о том, как они могут быть использованы при выполнении пользователем задач.

3.9 запрос (prompt): Выход системы, запрашивающий ввод данных пользователем.

3.10 информация о состоянии (статусе) (status information): Информация, отражающая текущее состояние системы.

3.11 руководство (подсказка) системы (system-initiated guidance): Руководство (подсказка), предоставляемое пользователю системой без запроса пользователя о предоставлении ему руководства.

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

3.12 руководство пользователя (user guidance): Дополнительная информация помимо обычного диалога «пользователь — компьютер», которая предоставляется системой пользователю по запросу или автоматически.

3.13 руководство (по запросу пользователя) (user-initiated guidance): Руководство (подсказка), предоставляемое пользователю системой только по запросу пользователя.

4 Применение настоящего стандарта

4.1 Целесообразность руководства пользователя

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

4.2 Применение рекомендаций

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

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

4.3 Оценка соответствия продукции

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

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

5 Общие рекомендации по руководству пользователя

5.1 Общие сведения

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

5.2 Общие рекомендации

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

Пример - В случае, если пользователь запрашивает руководство, появляется отдельное диалоговое окно другого цвета.

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

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

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

Пример - «День месяца должен быть указан в диапазоне значений от 1 до 31» вместо «Некорректные данные».

5.2.5 Руководство пользователя не должно прерывать задачу пользователя или последовательность диалога.

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

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

5.3 Формулировка сообщений руководства пользователя

5.3.1 Результат действия следует указывать до описания выполнения действия.

Пример - «Чтобы очистить экран, нажмите Enter»

вместо

«Нажмите Enter для того, чтобы очистить экран».

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

Пример - «Чтобы сохранить изменения, нажмите [ОК]»

вместо

«Система сохранит Ваши изменения, если Вы нажмете [ОК]».

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

Пример 1 — «Чтобы удалить символы слева от курсора, используйте клавишу»

«backspace», а не клавишу «delete».

Пример 2 — «Не работайте с ленточным накопителем, если программа архивирования данных все еще работает»

вместо

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

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

Пример 1 — «Доступные опции:»

отобразить файл,

распечатать файл,

удалить файл»

вместо

«Доступные опции:»

отобразить файл,

файловая печать,

удаление файла».

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

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

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

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

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

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

6 Запросы для ввода данных

6.1 Общие сведения

Запрос для ввода данных указывает на то, что система ожидает от пользователя ввода данных. Запрос может быть общим или конкретным. Общий запрос указывает на то, что система ожидает от пользователя ввода данных, но не указывает явно тип ожидаемых при вводе данных (например, «DOS „Y“, запрос командной строки в OC UNIX „$“). Конкретный запрос показывает, что система ожидает ввод данных пользователем, а также сообщает пользователю тип вводимых данных, который ожидается на данный момент в диалоге (например: „Введите имя файла, который требуется загрузить“).»

6.2 Рекомендации для запроса ввода данных

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

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

6.2.2 Конкретные запросы должны быть использованы при выполнении приведенных ниже условий. Чем больше из приведенных условий выполнено, тем более уместно использование конкретного запроса.

а) Пользователь не знаком с системой и нуждается в информации о том, как следует действовать.

б) Набор допустимых для ввода данных ограничен.

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

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

а) Не выполнены условия для использования конкретного запроса.

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

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

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

6.2.5 Если для выполнения задачи требуется конкретная последовательность действий пользователя, следует отображать запрос для текущего этапа действий (см. также ИСО 9241-12, 6.2.5).

6.2.6 Запросы для ввода данных/команд следует отображать в стандартном положении рядом с полем для ввода данных.

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

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

Пример - Сколько окон следует отображать при входе в систему?

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

Пример - Введите текущую дату://_

7 Обратная связь

7.1 Общие сведения

Обратная связь предоставляет информацию в ответ на введенную пользователем информацию. Тип обратной связи зависит от задачи, состояния системы и введенной пользователем информации.

Примерами обратной связи могут быть:

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

7.2 Рекомендации по использованию обратной связи

7.2.1 Каждый ввод данных пользователем должен сопровождаться своевременной и ощутимой обратной связью со стороны системы (см. также ISO 9241-15:1997, 7.9).

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

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

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

7.2.3 При выборе типа обратной связи, предоставляемой системой, следует учитывать:

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

b) изменчивость в совокупности пользователей: обратная связь для начинающих пользователей должна содержать больше разъяснительной информации, чем для опытных пользователей;

c) требования к информации о задаче: обратная связь должна быть согласована с требованием задачи относительно внимания пользователя.

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

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

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

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

7.2.5 Когда пользователь выбирает отображаемый пункт для выполнения над ним некоторой операции или для того, чтобы выполнить его, пункт меню должен быть выделен цветом или подсвечен (см. также ИСО 9241-14:1997, п. 7.1.4).

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

7.2.7 Рекомендуется обеспечивать обратную связь по окончании выполнения запросов пользователя.

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

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

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

Пример 1 — Обратную связь, связанную с переходом к новому полю формы, дают в пределах 250 мс.

Пример 2 — Перемещение указателя на дисплее происходит с задержкой до 100 мс по отношению к движениям указательного устройства (например, мыши).

8 Информация о состоянии

8.1 Общие сведения

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

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

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

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

8.2 Рекомендации об отображении информации о состоянии

8.2.1 Информация о состоянии должна постоянно предоставляться при выполнении приведенных ниже условий. Чем больше условий выполнено, тем более уместно непрерывное представление информации о состоянии.

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

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

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

a) Информация о состоянии имеет отношение к задаче пользователя, и ее автоматическое предоставление скорее всего не приведет к нарушению выполнения задач пользователя.

b) Информация о состоянии является единственным способом обратной связи, предоставляемой в ответ на действия пользователя (например, если объект выбран, он меняет цвет).

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

d) Систему или приложение используют достаточно редко.

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

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

a) Информация о состоянии не имеет отношения к текущей задаче пользователя.

b) Информация о состоянии не является критичной и является полезной только для некоторой группы потенциальных пользователей.

c) Информация о состоянии лишь изредка необходима для руководства действиями пользователя.

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

8.2.4 Для каждого типа информации о состоянии следует использовать постоянное место на дисплее (или в окне).

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

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

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

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

Пример 2 — Состояние кнопки (галочка, чек-бокс) «ВЫКЛ» или «ВКЛ» отображается в графическом виде слева от подписи к кнопке.

9 Обработка ошибок

9.1 Общие сведения

Ошибки при взаимодействии человека с компьютером включают в себя:

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

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

9.2 Предотвращение ошибок

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

a) Пользователь имеет ограниченный опыт работы с системой или имеет доступ к системе на периодической основе (достаточно редко).

b) Работа пользователя с большой вероятностью может быть прервана во время выполнения задачи.

c) Задача имеет критические последствия в случае ошибок или ошибки часто встречаются.

d) Задача требует выполнения пользователем правильной последовательности ввода данных.

e) Система имеет несколько режимов работы.

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

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

Пример - Режим 1: F4 — Список каталогов, Режим 2: F4 — Список файлов

вместо

Режим 1: F4 — Список каталогов, Режим 2: F4 — Смена окна;

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

Пример - Клавишу F4 не назначают для выполнения команды «Удалить», если она была ранее назначена для выполнения команды «Файл».

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

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

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

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

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

9.3 Исправление ошибок системой

9.3.1 Исправление ошибок системой следует использовать при выполнении перечисленных ниже условий. Чем больше выполнено условий, тем более уместно использование исправления ошибок системой.

a) Ошибка возникает в результате аппаратного и/или программного сбоя, если в системе предусмотрена возможность устранения ошибки.

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

9.3.2 Если в системе предусмотрена возможность устранения ошибок, то рекомендуется:

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

b) предоставлять пользователю подтверждающее или предупреждающее сообщение, разъясняющее детали планируемого исправления.

9.4 Исправление ошибок пользователем

9.4.1 Если задача требует исправления ошибок пользователем, соответствующий диалог должен обеспечить пользователя средствами (информацией и/или функциями), позволяющими продолжить диалог.

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

В качестве примеров способа исправления ошибок могут быть:

• функция отмены;
• проверка синтаксических ошибок;
• перечень перекрестных ссылок;
• функция «история» (просмотр журнала выполненных действий);
• программа проверки орфографии.

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

Примеры способов выявления ошибок:

• визуальный редактор;
• функции предварительного просмотра;
• функции моделирования;
• список настроек системы.

9.4.4 При обнаружении ошибки пользователь должен иметь возможность редактировать введенные ошибочные данные, а не выполнять повторный ввод всех данных (см. также ИСО 9241-15:1997, 8.3).

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

a) предоставить пользователю индикаторы наличия множественных ошибок;

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

9.5 Сообщение об ошибке

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

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

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

a) содержать информацию о причине ошибки (см. также ИСО 9241-15:1997, 8.3).

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

b) обеспечивать индикацию класса ошибки как можно точнее (например, ошибка чтения файла (имя файла)).

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

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

9.5.5 Сообщения об ошибках рекомендуется удалять:

а) как только ошибка исправлена;

б) до исправления ошибки, если пользователю необходимо удалить сообщение об ошибке.

9.5.6 Информацию об ошибках следует отображать в постоянном специально отведенном для этого месте одним из следующих способов:

a) как можно ближе к введенным пользователем данным, вызвавшим ошибку, не заслоняя введенную информацию;

b) в одном и том же постоянном месте дисплея или окна.

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

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

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

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

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

a) отключить появление сообщений, запрашивающих подтверждение;

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

10 Онлайн-справка

10.1 Общие сведения

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

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

• информация о синтаксисе команды, доступные ключи, процедуры задач;
• разъяснения (например, разъяснение понятий, связанных с задачей);
• вспомогательная информация (например, перечень опций);
• описания (например, описания экранов и связанных с ними действий).

10.2 Справка, инициируемая системой

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

a) Пользователи являются неопытными, и необходимо, чтобы они быстро повысили свою квалификацию в данном вопросе.

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

c) Пользователи не знают о доступных сочетаниях клавиш в системе.

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

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

b) Отображение текста онлайн-справки мешает выполнению пользователем основной задачи.

c) Функционирование системы или приложения заметно ухудшается при предоставлении информации из онлайн-справки.

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

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

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

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

b) регулярную онлайн-справку по инициативе системы не следует предоставлять в форме, отвлекающей внимание пользователя от основной области (например, не рекомендуется использовать мигание или экстремальные цвета);

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

10.2.5 Рекомендуется предоставлять пользователю возможность включения и отключения онлайн-справки по инициативе системы.

10.3 Справка по запросу пользователя

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

Пример - Клавиша «?»; функциональная клавиша F1; выбор значка справки; устно произнесенное слово «помощь».

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

a) Не существует области применения для определения типа онлайн-справки, необходимой пользователю.

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

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

a) Содержание задачи может помочь выделить возможный набор необходимых пользователю тем, но не одну тему.

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

10.3.4 В случае, если пользователь запрашивает справку методами, отличными от выбора из меню (например, набрав запрос о помощи), рекомендуется:

a) чтобы система понимала синонимы, указывающие темы онлайн-справки (в том числе не технические синонимы);

b) чтобы система понимала слова, близкие по написанию к стандартным терминам, используемым системой для указания темы онлайн-справки.

10.3.5 Если запрос пользователя на предоставление ему онлайн-справки не в полной мере указывает тему, по которой требуется онлайн-справка, рекомендуется, чтобы система:

a) отображала информацию из онлайн-справки, которая имеет отношение к содержанию задачи или текущей транзакции;

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

10.4 Представление справочной информации

10.4.1 Если пользователь указал тему онлайн-справки, рекомендуется отображать только информацию, относящуюся к указанной теме.

10.4.2 Рекомендуется отображать онлайн-справку после запроса пользователя как можно быстрее.

10.4.3 Рекомендуется, чтобы время отклика при отображении онлайн-справки было достаточно предсказуемым для конкретного типа взаимодействия с онлайн-справкой.

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

10.4.5 В онлайн-справке следует предоставлять связанную с задачей информацию о системе и ее назначении.

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

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

10.5 Навигация и средства управления справочной информацией

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

Пример - В терминальной среде пользователь может осуществлять переходы между онлайн-справкой и экранами задач.

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

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

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

b) инициирования запроса на получение онлайн-справки в любое время;

c) выбора и изменения темы онлайн-справки;

d) контроля вида информации онлайн-справки, если предусмотрены различные ее виды (например, учебник, синтаксис, задачи);

e) выхода из онлайн-справки в любое время.

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

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

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

10.5.6 Если онлайн-справка реализована в виде отдельного режима, рекомендуется:

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

Пример - система изменяет форму указателя запроса или указателя мыши на форму в виде «?»;

b) чтобы способ выхода из режима онлайн-справки и возврата к задаче был очевидным для пользователя.

Пример - Система отображает диалоговое окно с кнопкой для выхода из него.

10.6 Просматриваемая справка

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

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

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

• поиск строки в перечне тем онлайн-справки;
• поиск по ключевым словам в тексте онлайн-справки;
• иерархическая структура текста онлайн-справки;
• карта разделов онлайн-справки.

10.6.4 Рекомендуется, чтобы при необходимости (например, это важно для задач, основанных на справочных материалах) система обеспечивала:

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

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

• возврат к предыдущему разделу справки;
• возврат к главной странице справочной системы;
• доступ к соответствующим темам одним действием (перекрестные ссылки);
• доступ к истории ранее просмотренных разделов справки.

10.6.6 Если информация онлайн-справки имеет иерархическую структуру, то рекомендуется:

a) обеспечить указание в структуре разделов онлайн-справки;

b) предоставить возможность доступа к информации по справочной теме на любом уровне иерархической структуры, а не только на самом верхнем уровне;

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

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

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

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

10.7 Контекстно-зависимая справка

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

10.7.2 Рекомендуется, чтобы контекстно-зависимая онлайн-справка обеспечивала доступ к следующей информации о задаче:

• аспекты (например, семантические или лексические, описательные или процедурные) текущего этапа диалога;
• выполняемая задача;
• текущее приложение;
• представленная на экране информация, относящаяся к задаче.

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

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

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

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

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

(справочное)

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

1. определения того, какие из предложенных рекомендаций применимы;

2. определения выполнения применимых рекомендаций.

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

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

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

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

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

Документами, подтверждающими выполнение рекомендаций настоящего стандарта, являются: проверенные руководства пользователя, методы, используемые для проверки применимости рекомендаций (см. в А.1); методы, используемые для проверки выполнения рекомендаций (см. А.3), и результаты проверки.

А.1 Применимость рекомендаций

Проверка применимости рекомендаций состоит из выполнения следующих двух этапов:

a) Проверка истинности условного утверждения, если оно включено в рекомендацию. Конкретная рекомендация является применимой (или неприменимой), если условное утверждение с логическим оператором «ЕСЛИ» является истинным (ложным). Например, если задача не требует выполнения определенной последовательности действий пользователя, рекомендации в соответствии с 6.2.5 не следует применять.

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

Подходящими методами для определения применимости конкретной рекомендации являются:

a) анализ документации системы;

b) документальное свидетельство;

c) наблюдение;

d) аналитические исследования;

e) эмпирическая проверка.

В разделе А.2 каждый метод проверки применимости описан более подробно.

А.2 Методы проверки применимости рекомендаций

А.2.1 Анализ документации системы

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

А.2.2 Документальное свидетельство

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

А.2.3 Наблюдение

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

А.2.4 Аналитические исследования

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

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

А.2.5 Эмпирическая проверка

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

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

А.3 Выполнение рекомендации

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

a) измерения;

b) наблюдение;

c) документальное свидетельство;

d) аналитические исследования;

e) эмпирическая проверка.

Примечание — Методы, подходящие для проверки выполнения конкретной рекомендации, приведены вместе с этой рекомендацией в контрольном перечне (см. таблицу А.1).

Результаты проверки применимости часто играют важную роль в проверке выполнения рекомендации. Различные методы проверки выполнения рекомендации описаны ниже.

А.4 Методы проверки выполнения рекомендации

А.4.1 Измерения

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

А.4.2 Наблюдение

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

А.4.3 Документальное свидетельство

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

А.4.4 Аналитические исследования

Как отмечено в А.2.4, аналитические исследования позволяют принять обоснованные решения относительно свойств руководств пользователя, принимаемые соответствующим экспертом. Такие исследования обычно используют для анализа свойств, которые можно проверить только при наличии другой информации или знаний. Кроме того, аналитические исследования подходят для проверки выполнения рекомендации в случаях, когда система существует только в виде проектных документов, а для применения эмпирической проверки нет необходимой группы пользователей или ограничены ресурсы и время. Например, аналитические исследования могут быть использованы для проверки точности отображения системой своего состояния, даже если ее состояние изменяется (7.2.4). В приведенном случае точность является субъективным аспектом.

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

А.4.5 Эмпирическая проверка

Эмпирическая проверка относится к применению испытаний с использованием репрезентативной группы конечных пользователей с целью определения выполнения рекомендации. Как отмечено в А.2.5, этот метод является наиболее подходящим при наличии опытного образца или реальной системы, а также потенциальных или фактических пользователей системы. Может быть использовано много процедур испытаний, но в каждом случае испытуемые должны быть представителями репрезентативной группы конечных пользователей и их количество должно быть достаточным для того, чтобы результаты испытаний можно было распространить на всю совокупность пользователей. Для проверки выполнения различных условных рекомендаций может быть проанализирована производительность выполнения задачи конечным пользователем с использованием руководства пользователя. Например, анализируя время, необходимое пользователям для исправления ошибок, можно определить, отображают ли сообщения об ошибках информацию о том, что является ошибкой, какие корректирующие меры могут быть приняты, и причину ошибки (см. 9.5.3). Такие проверки могут быть выполнены как в процессе разработки (например, путем быстрого создания образцов), так и после завершения проектирования и внедрения системы (например, с помощью методов проверки работы системы) и могут быть основаны на объективных и субъективных данных, полученных от пользователей. Могут быть разработаны специальные испытания для проверки выполнения конкретной рекомендации.

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

А.5 Процедура

При проверке конкретного приложения руководства пользователя на соответствие рекомендациям настоящего стандарта нужно следовать приведенной в настоящем разделе процедуре (см. рисунок А.1).

Рисунок А.1. Процесс принятия решения — Оценка

А.5.1 Рекомендации, содержащие условные высказывания, с оператором «ЕСЛИ»

a) Применимость. Каждая рекомендация, содержащая условное высказывание, содержит логический оператор «ЕСЛИ», либо в тексте рекомендации (см. 5.2.3), либо этот оператор подразумевается в заголовке соответствующего подраздела (см. 10.2). Для каждой условной рекомендации применимость условного высказывания определяют с использованием методов проверки истинности этого высказывания (например, в 9.5.9 документальное свидетельство, аналитические исследования и эмпирическая проверка подходят для определения необходимости представления в сообщении об ошибке набора альтернативных вводимых данных). Кроме того, если существует несколько дополнительных условных рекомендаций, таких как в 9.3.2, a), и 9.3.2, b), применимость следует определять с помощью предложенных методов. Различные наборы дополнительных условных рекомендаций далее приведены в контрольном перечне для проверки применимости и выполнения рекомендации настоящего стандарта с использованием логических связей.

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

А.5.2 Другие условные рекомендации

a) Применимость. Условные рекомендации, не включающие логическую операцию «ЕСЛИ», как правило, могут быть использованы в любом руководстве пользователя. Тем не менее часть разделов (например, 10.2 Справка по инициативе системы) применяют только в случае, когда руководство пользователя включает такую операцию. Если руководство пользователя содержит справку по инициативе системы, то рекомендации данного подраздела являются применимыми (а применимость операции «ЕСЛИ» определяют в соответствии с А.5.1).

b) Выполнение. Для каждой безусловной рекомендации, использующей логический оператор «ЕСЛИ» в соответствии с а), необходима информация о выполнении рекомендации в соответствии с А.5.1, б). Например, аналитические исследования или эмпирическая проверка являются подходящими методами для определения выполнения рекомендации относительно соответствия времени отклика системы на ввод данных пользователем (см. 7.2.9). При наличии веских причин, по которым предложенная рекомендация не может быть выполнена, пользователям настоящего стандарта рекомендуется проанализировать как причины, так и выбранное проектное решение.

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

А.6 Контрольный перечень

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

Контрольный перечень, приведенный в таблице А.1, предназначен в качестве помощи проектировщикам и для проверки руководства пользователя при анализе его применимости и выполнения условных рекомендаций настоящего стандарта. В этом перечне приведено «сокращенное наименование» всех рекомендаций настоящего стандарта и сформирована логическая структура, помогающая пользователям определять применимость руководства пользователя. Многие условные рекомендации допускают альтернативные решения. В контрольном перечне такие взаимозависимости приведены с использованием логических операторов «и», «или». Эти операторы использованы только для условных рекомендаций по отношению к конкретному разделу (предполагается, что к разделу применим оператор «и» в той степени, в какой применим раздел). В некоторых случаях, когда варианты выбора не являются взаимоисключающими, указано «и/или».

А.6.1 Описание контрольного перечня

А.6.1.1 Колонка «рекомендации»

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

А.6.1.2 Колонки применимости

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

S — анализ документации системы;

D — документальное свидетельство;

O — наблюдение;

A — аналитические исследования;

E — эмпирическая проверка;

DM — другой метод (кроме вышеперечисленных).

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

А.6.1.3 Колонки выполнения рекомендаций

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

M — измерение;

O — наблюдение;

D — документальное свидетельство;

A — аналитические исследования;

E — эмпирическая проверка;

DM — другой метод (кроме вышеперечисленных).

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

А.6.1.4 Примечания

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

А.6.2 Итоговые данные

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

Обозначение ссылочного международного стандарта	Степень соответствия	Обозначение и наименование соответствующего национального стандарта
ISO 9241-12:1998		<*>
ISO 9241-14:1997		<*>
ISO 9241-15:1997		<*>
ISO 9241-16:1999		<*>
<*> Соответствующий национальный стандарт отсутствует. До его утверждения рекомендуется использовать перевод на русский язык данного международного стандарта.

БИБЛИОГРАФИЯ

[1]	AKSCYN R.M., MCCRACKEN D.L. and YODER E.A., KMS: A distributed hypermedia system for maintaining knowledge in organizations, Communications of the ACM, 1986, 31, 7, 820 — 835.
[2]	Bell Communications Research, Guidelines for Dialog and Screen Design, J\A-STS-000045, Sept. 1986. Piscataway, N.J. (based on course Dialog and Screen Design, Bell Communications Research, 1985).
[3]	BUTLER T.W., Computer response time and user performance during data entry. Bell Laboratories Technical Journal, 1984, 63, 100710018.
[4]	BORENSTEIN N.S., Help texts vs. Help Mechanisms: A new mandate for Documentation Writers. Proceedings of the 1985 SIGDOC Annual Meeting, 1985, 8 — 10.
[5]	CARBONELL J.R., ELKIND J.I. and NICKERSON R.S., On the psychological importance of time in a time-sharing system. Human Factors, 1969, 10, 135 — 142.
[6]	CHEN H. and TSOI K., Factors affecting the readability of moving text on a computer display. Human Factors, 1988, 30, 25 — 33.
[7]	CLARK H.H., and E.V. CLARK, Semantic distinctions and memory for complex sentences. Quarterly Journal of Experimental Psychology, 1968, 20, 129 — 138.
[8]	COHILL A.M. and R.C. WILLIGES, Computer-augmented retrieval of HELP information for novice use. Proceedings of Human Factors Society — 26th Annual Meeting, 1982, 79 — 82.
[9]	COHILL A.M. and WILLIGES R.C. Retrieval of Help information for novice users of interactive computer systems. Human Factors, 1985, 27, 335 — 343.
[10]	CONKLIN J. A survey of Hypertext, STP-356-86 Rev.2., Microelectronics and Computer Technology Corporation, 1987.
[11]	DIN 66 234, Part 8, Display Work Stations Principles of Dialog Design, Deutsches Institut fur Normung, 1986.
[12]	ENGEL S.E. and GRANDA R. Guidelines for Man/Display Interfaces. Technical Report TR 00.27200, IBM Poughkeepsie, New York, Dec. 1975.
[13]	FECHT B.A., RIDEOUT T.B., RANKIN W.L., BARNES V.E., SAARI L.M., TRIGGS and DESTEESE J.G. Human Factors Applications to Computer-Aided System Design in LNG Facilities, Volume 1 Design Principles. Technical Report GRI-85/0183.7, Battelle Pacific Northwest Laboratories, Richland, Washington 99352, 1985.
[14]	FISHER G. Computational models of skill acquisition processes. In R. Lewis and D. Tagg (Ed.) Computers in Education, World Conference on Computers and Education, Lausanne, Switzerland, 1981, 477 — 481.
[15]	FISHER G., LEMKE A. and T. SCHWAB, Active help systems. In Green, et al. (Ed.) Cognitive Ergonomics, Mind and Computer, Proceedings of the Second European Conference on Cognitive Ergonomics, Mind and Computer, Sept. 1984.
[16]	FOLEY J.D. and A. VAN DAM Fundamentals of Interactive Computer Graphics, Addison-Wesley, Reading, MA, 1982.
[17]	GREGORY M. and POULTON E.C. Even versus uneven right-hand margins and the rate of comprehension in reading. Ergonomics, 1970, 13, 427 — 434.
[18]	Human Computer interaction Standards Committee. General consensus of committee members.
[19]	HORTON W.K. Designing and Writing On-line Documentation. John Wiley and Sons, 1990.
[20]	JOHNSON-LAIRD P.N. and TRIDGELL J.M. When negation is easier than affirmation. Quarterly Journal of Experimental Psychology, 1972, 24, 87 — 91.
[21]	KEARSLEY G. On-line Help Systems: Design and Implementation, Ablex Publishing Corp., Norwood, New Jersey, 1988.
[22]	KEISTER L. and SHNEIDERMAN. B. Making software user friendly, an assessment of data entry performance. Proceedings of the Human Factors Society 27th Annual Meeting. Santa Monica, Ca: Human Factors Society, 1983.
[23]	LIMANOWSKI J.J. On-line documentation system: History and issues. Proceedings of Human Factors Society 27th Annual Meeting. Santa Monica, CA: Human Factors Society, 1983.
[24]	MAGERS C.S. An experimental evaluation of on-line Help for non-programmers. Proceedings of CH/'83 Human Factors in Computing Systems. New York: Association for Computing Machinery, 1983.
[25]	MIL-STD-1472C. Military standard: Human engineering requirements for military systems, equipment and facilities. Washington, DC: Department of Defense, Sept. 1983.
[26]	MONK A. Mode errors: a user-centred analysis and some preventative measures using keying contingent sound. International Journal of Man-Machine Studies, 1986, 2, 313 — 327.
[27]	MOSKEL S. ERNO J. and SHNEIDERMAN B., Proofreading and comprehension of text on screens and paper. University of Maryland Computer Science Technical Report, June 1984.
[28]	NEAL A.S. Time intervals between keystrokes, records, and fields in data entry with skilled operators, Human Factors, 1977, 19, 163 — 170.
[29]	PAKIN SE. and WRAY P. (1982). Designing screens for people to use easily. Data Management, 1982, 20, 36 — 41.
[30]	PARON D., HUFFMAN K., PRIDGEN P, NORMAN K. and SHNEIDERMAN B., Learning a menu selection tree: training methods compared. Behaviour and information Technology, 1985, 4, 81-W.
[31]	RAMSEY HR. and ATWOOD M.E. Human Factors in Computer Systems: A Review of the Literature. Technical Report No. SA1-79-1 I I-DEN. Science Applications Inc., Denver, CO, 1979.
[32]	RUBINSTEIN R. and HERSH H. The Human Factor: Designing Computer Systems for People, Digital Press, Burlington, MA, 1984.
[33]	SHNEIDERMAN B. System message design: Guidelines and experimental results. In Badre, A., and Shneiderman B. (Editors), Directions in Human Computer Interaction, Ablex Publishers, Norwood, NJ, 1982, 55 — 78.
[34]	SHNEIDERMAN B. Designing the User Interface: Strategies for Effective Human-Computer Interaction. Addison-Wesley Publishing, 1987.
[35]	SLATIN J. Hypertext and the teaching of writing. In Text, ConText and HyperText: Writing with and for the Computer. Cambridge, MA: The MIT Press, 1988, 111 — 129.
[36]	SMITH S.L. Exploring compatibility with words and pictures. Human Factors, 1981, 23, 305 — 315.
[37]	SMITH S.L. and AUCELLA A.F., 1983. Design Guidelines for the User Interface to Computer-Based Information Systems. Technical Report ESD-TR-63422m NT/S AD A127345, USAF Electronic Systems Division, Hanscom Air Force Base, Massachusetts.
[38]	SMITH S.L. and MOSIER J.N., 1986. Design Guidelines for the User Interface for Computer-Based Information Systems. Technical Report ESD-TR-86-278, Mitre, Bedford Massachusetts.
[39]	SNOWBERRY K. PARKINSON and SISSON N. Effects of help fields on navigating through hierarchical menu structures. International Journal of Man-Machine Studies, 1985, 22, 479 — 491.
[40]	STIBIC V. A few practical remarks on the user-friendliness of on-line systems. Journal of information Science, 1980, 2, 277 — 283.
[41]	TIJERINA L. CHEVALAZ G. and MYERS L.B. 1985. Human Factors Aspects of Computer Menus and Displays in Military Equipment. Battelle Colombus Division, Columbus Ohio 43201-2693.
[42]	TINKER M.A. Prolonged reading tasks in visual research. Journal of Applied Psychology, 1955, 39, 444 — 446.
[43]	WASON P.C. The contexts of plausible denial. Journal of Verbal Learning and Verbal Behaviour. 1965, 4, 7 — 11.
[44]	WATLEY C. and MULFORD J. A comparison of commands documentation: On-line vs hard copy, Unpublished student project, University of Maryland, 1983, cited in B. SHNEIDERMAN Designing the User Interface: Strategies for Effective Human-Computer Interaction. Addison-Wesley Publishing, 1987.
[45]	WHITE C.T. Eye movements, evoked responses and visual perception: some speculations. Acta Psychologica, 1976, 27, 337 — 340.
[56] WOGALTER M.S., GODFREY S.S., FONTENELLE G.A., DESAULNIERS D.R., ROTHSTEIN P.R. and LAUGHERY K.R. Effectiveness of Warnings, Human Factors, 1987, 29(5), 599 — 612.
[47]	СанПин 2.2.2/2.4.1340-03 «Гигиенические требования к персональным электронно-вычислительным машинам и организации работы».

---