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

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

Элементы  окна

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

Строка  заголовка окна

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

строкой состояния можно пренебрегать. Точнее, самой строкой как раз пренебречь можно, но её содержимым – нельзя. Дело в том, что текст и, в меньшей степени, пиктограмма заголовка играют важную роль в ПО (они заведуют переключением задач) и очень важную в Интернете (заведуют навигацией).   

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

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

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

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

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

поисковых системах заголовком элемента становится содержимое тега Title.

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

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

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

Строка  статуса

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

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

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

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

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

Панели  инструментов

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

■ они  позволяют пользователям быстро вызывать нужные функции

мышью

■ они  позволяют пользователям меньше задействовать память

■ они  повышают визуальное богатство интерфейса

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

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

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

Полосы  прокрутки

Когда графических интерфейсов еще  не было, пользователи перемещались по документу с помощью клавиатуры. С тех далёких времен на клавиатуре остались клавиши Home и End, равно как Page Up и Page Down. В целом, пользователи были удовлетворены своей судьбой (благо, они не знали альтернатив). Затем появились графические интерфейсы. Первым делом были придуманы полосы прокрутки. К сожалению, оказалось, что они работают не слишком хорошо.

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

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

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

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

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

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

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

С появлением мышей с колёсиками, полоски прокрутки  смело можно делать тоньше. К сожалению, вовсе не использовать полосы прокрутки  в ПО затруднительно, MS Windows User Experience прямо заставляет разработчика ими пользоваться. В Интернете ситуация иная – никто никого не заставляет.

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

Если  всё-таки приходится оставлять полосы прокрутки, крайне желательно добиться нескольких свойств полосок:

■ Размер ползунка должен показывать общий объем  пролистываемого документа.

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

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