Директивно-диалоговая форма взаимодействия с программной системой Интерфейс командной строки (Command Line Interface - CLI)

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

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

До определённого  момента (смещение на 30-70 пикселей) система  должна такое смещение игнорировать.

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

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

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

Рис.9. Пример читаемого окна. Читается он следующим  образом: «Текст выравнива-

ется  по левому краю, уровень пятый, отступ слева 3 см, справа 0 см, первая строка нет,

на 5 и  так далее». На этом примере прекрасно  видны все неопределенности в  окне:

например, не говоря уже о том, что непонятно, чего именно пятый уровень, видно,

что подписи  к «первая строка» и к «на», расположенные сверху, разрывают  единый

по смыслу элемент управления на два разных.   

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

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

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

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

Увеличиваем площадь

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

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

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

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

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

Терминационные  кнопки

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

Перемещение в пределах окна

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

Последовательные  окна

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

Рис. 10. Пример мастера.  

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

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

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

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

Переход между экранами

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

Задача  раскладывается на две составляющие: во-первых, нужно реализовать возможность свободного перемещения по последовательности. Если экранов немного (3-5), то вполне можно ограничиться стандартными кнопками Назад и Далее. Если же экранов много, переход по этим кнопкам будет, как минимум, медленным. В таких случаях разумно дополнять кнопки раскрывающимся списком (при этом, возможно, исключая из него ещё не пройденные экраны), либо, если есть место, снабжать мастера списком всех экранов (отмечая текущий и пройденные экраны). Независимо от числа экранов в последовательности, необходимо информировать пользователей об объеме оставшегося действия (чтобы дать им возможность оценивать количество работы и тем самым повышать их чувство контроля над системой). Справедливости ради надо уточнить, что в длинных последовательностях показ объема оставшихся экранов может снизить мотивацию пользователей в начале действия, но повысить мотивацию в конце («осталось немного, не буду это бросать»).

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

Контекст

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

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

Вывод справочной информации

Благодаря обилию пустого места мастера  замечательно подходят к выводу справочной информации в самом интерфейсе. Справочную же информацию нужно выводить двух типов, а именно краткое и более  развернутое описания текущего шага. С развернутым описанием все просто. Где-нибудь снизу экрана (чтобы не сбивать фокус внимания пользователей) выводится один или два абзаца, рассказывающие стандартный набор: что, зачем и почему. С кратким же описанием сложнее. К сожалению, устоявшийся облик мастеров не имеет большого и заметного заголовка (этой проблемы, к счастью, нет в Интернете, где вообще нет ничего устоявшегося). Например, даже такой прогрессивный мастер, как использованный в примере, не имеет явно видимого заголовка. Шрифт мелкий, к тому же его разборчивость ослаблена фоном. Это неправильно. У каждого окна последовательности должен быть ясно видимый и бросающийся в глаза заголовок. При этом, в отличие от обычных заголовков окна, он должен быть написан не описательно, но командно (сделайте то-то и то-то). Microsoft, в некоторых своих продуктах широко использующая мастера (называя это побуждающим пользовательским интерфейсом) вообще рекомендует считать заголовки важнейшими элементами мастеров. Особо подчеркивается, что заголовки экранов должны быть созданы и сформулированы до начала проектирования экранов, при этом содержимое экранов не должно выходить за рамки смысла заголовков. Поспорить с Microsoft в данном случае затруднительно.

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

Пиктограммы

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

Чем пиктограммы плохи? В 1981 году Истерби и Грейдон провели масштабное исследование ста восьми пиктограмм, выбранных экспертами ISO для использования по всему миру. Некоторые из этих пиктограмм широко использовались и до этого. Цель исследования заключалась в том, чтобы определить, сколько пиктограмм правильно бы распознавались двумя третями целевой аудитории. Результат: три.