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

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

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

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

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

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

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

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

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

Согласованность в пределах продукта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 
   Интерфейс пользователя необходимо проектировать и разрабатывать как отдельный компонент создаваемого приложения.
   
2. 
   Необходимо учитывать возможности и особенности аппаратно-программных средств, на базе которых реализуется интерфейс.
   
3. 
   Целесообразно учитывать особенности и традиции той предметной области, к которой относится создаваемое приложение.
   
4. 
   Процесс разработки интерфейса должен носить итерационный характер, его обязательным элементом должно быть согласование полученных результатов с потенциальным пользователем.
   
5. 
   Средства и методы реализации интерфейса должны обеспечивать возможность его адаптации к потребностям и характеристикам пользователя.
   

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

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

В качестве иллюстрации того, насколько серьезно относятся «законодатели моды» в области компьютерных технологии к проблемам интерфейса, можно отметить следующий факт. Американский Национальный институт стандартов (ANSI) имеет по данному направлению специальную консультативную группу — Комитет по стандартам интерфейса «человек-компьютер» (The Human-Computer Interface Standard Committee). Существуют подобные организации не только в США, но и в других странах: более того, имеются также международные исследовательские группы, работающие в этом направлении, например. Международный консультативный комитет по телеграфии и телефонии (International Telegraph and Telephone Consultation Committee), изучающий особенности интерактивных элементов интерфейса.

Многими из этих организаций или рабочих групп в свое время были подготовлены проекты документов по стандартизации пользовательских интерфейсов, содержащие принципы их проектирования и реализации. Так, в 1986 году было опубликовано «Руководство по разработке программного пользовательского интерфейса» [1], содержащее 944 принципа, касающихся ввода и отображения данных, поддержки пользователя, защиты данных и т.д. Однако ни один из этих проектов не получил статуса официального документа, поскольку все они имели общий недостаток (тот же, что и первые исследования в этой области): в них не учитывались технологические возможности инструментальных средств, имевшихся в распоряжении разработчиков программного обеспечения.

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

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

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

1. 
   Повышение производительности труда программистов и конечных пользователей.
   
2. 
   Облегчение эксплуатации и сопровождения программного обеспечения.
   
3. 
   Повышение эффективности распределенной обработки информации.
   
4. 
   Увеличение отдачи инвестиций в разработку информационных систем.
   

1. 
   Соглашения по интерфейсу пользователя (Common User Access — CUA);
   
2. 
   Соглашения по программному интерфейсу (Common Programming Interface — CPI);
   
3. 
   Соглашения по разработке приложений (Common Applications — СА);
   
4. 
   Соглашения по коммуникациям (Common Communications Support — CCS).
   

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

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

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

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

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

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

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

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

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

И в заключение раздела еще одно замечание. Несмотря на широкое распространение графического интерфейса, он не является единственно возможным или необходимым вариантом организации взаимодействия пользователя с приложением. Поэтому и в проектах документов по стандартизации интерфейса, и в данной книге рассматривается целый ряд вопросов, относящихся к общей методике проектирования и реализации пользовательского интерфейса.
ЭТАПЫ ПРОЕКТИРОВАНИЯ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА

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

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

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

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

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

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

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

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

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

Рассмотренные ниже четыре варианта структуры диалога являются разновидностями структуры типа «вопрос — ответ», тем не менее каждая из них имеет свои особенности и наиболее удобна для определенного класса задач.
ДИАЛОГ ТИПА «ВОПРОС - ОТВЕТ»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 
   Закрыть графы «Тип диалога».
   
2. 
   В графе «Выбор пользователя» пометить критерии, относящиеся к рассматриваемому применению.
   
3. 
   Для каждого типа диалога подсчитать число случаев, когда помечены соответствующие пункты и в графе «выбор пользователя», и в графе «тип диалога».
   
4. 
   Подсчитать число совпадений для каждого типа диалога.
   

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

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

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

голубой — успокаивает;

красный — волнует и утомляет;

зеленый — настраивает на добродушный и безынициативный лад;

желтый — веселый, оптимистичный, вызывает легкомысленный настрой;

оранжевый — раскрепощает фантазию;

фиолетовый — гибелен для глаз, цвет зависти, тревоги, неудовлетворенности;

коричневый — угнетает умственную активность;

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

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

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

1. 
   Хотя вы можете использовать цвет, чтобы отразить связь между теми или иными объектами, ассоциация между выбранным вами цветом и конкретным значением не всегда будет очевидна или легко узнаваема для пользователя.
   
2. 
   Цвет является очень субъективной характеристикой (помните народную мудрость: «На вкус и на цвет товарищей нет»?); поэтому то, что нравится вам, совсем не обязательно будет приятно пользователям.
   
3. 
   Некоторые пользователи могут иметь проблемы с цветовосприятием (около 9 процентов взрослого мужского населения имеют то или иное отклонение в восприятии цвета).
   

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

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

ШРИФТ

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