СОГЛАСОВАННОСТЬ ИНТЕРФЕЙСА

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

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

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

§ Согласованность в использовании метафор.

Когда уже существующие метафоры нельзя использовать в другом смысле.

Метафора – использование некоторого объекта для понимания характеристик другого объекта.

3) ДРУЖЕСТВЕННОСТЬ ИНТЕРФЕЙСА (ПРИНЦИП «ПРОЩЕНИЯ» ПОЛЬЗОВАТЕЛЯ)

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

Пользователь не должен навредить:

§ Себе.

§ Другим пользователям.

§ Системе.

Это осуществимо лишь при выполнении следующих пунктов:

§ В определенный момент времени должен быть доступен лишь определённый набор операций.

§ Операции должны иметь возможность быть отменены.

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

4) ПРИНЦИП «ОБРАТНОЙ СВЯЗИ»

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

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

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

5) ПРОСТОТА ИНТЕРФЕЙСА

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

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

Полнота интерфейса постоянно конфликтует с его простотой.

6) ГИБКОСТЬ ИНТЕРФЕЙСА

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

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

Существуют три вида адаптации:

Фиксированная

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

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

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

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

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

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

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

1. полная

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

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

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

1. косметическая.

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

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

§ использование умолчаний (распространенный способ — это нулевой ввод);

§ использование сокращений (ввод вместо имени команды ее любое допустимое сокращенное обозначение);

§ опережающий ввод символов (система, «узнав» по первым символам команду, «дописывает» ее сама);

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

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

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

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

Ситуация коренным образом изменилась в 1987 г., когда корпорация IBM объявила о намерении создать единую среду разработки приложений (Systems Application Architecture — SAA).

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

Целями проекта являлись:

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

§ Облегчение эксплуатации и сопровождения программного обеспечения.

§ Повышение эффективности распределенной обработки информации.

§ Увеличение отдачи инвестиций в разработку информационных систем.

Проект SAA содержит 4 компонента:

§ Соглашения по интерфейсу пользователя (Common User Access — CUA);

§ Соглашения по программному интерфейсу (Common Programming Interface — CPI);

§ Соглашения по разработке приложений (Common Applications — СА);

§ Соглашения по коммуникациям

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

Исследованиями и практической реализацией графических интерфейсов в то время уже занимались такие фирмы как Xerox, Apple, Digital Research и Microsoft. В результате их деятельности были определены основные концепции построения графических пользовательских интерфейсов:

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

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

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

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

В силу различных причин фирма IBM при реализации проекта SAA наиболее тесно сотрудничала с фирмой Microsoft, в результате чего была создана графическая оболочка Microsoft Windows IBM Top View. И хотя впоследствии пути двух гигантов компьютерного бизнеса несколько разошлись, основные положения проекта SAA живы и успешно развиваются: корпорацией IBM — применительно к OS/2, а фирмой Microsoft — в рамках семейства ОС Windows.

В марте 1997 года фирма Microsoft выпустила пакет Visual Studio 97, в который вошли все созданные ею инструментальные средства разработки приложений, а также средства автоматизации сопровождения программных продуктов (Visual SourceSafe). Это событие можно рассматривать как очередной шаг в направлении практической реализации идей проекта SAA.

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

Справедливости ради следует отметить, что для UNIX-систем, в определенном смысле являющихся конкурентом Windows, существует аналогичный «почти стандарт», представленный архитектурой XWindow.

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

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

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

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

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