Команды
Я как писатель-фантаст уверен, что этот чертов робот должен говорить на человеческом языке, а не наоборот.
Спайдер Робинсон
Некоторые команды (как, например, Отменить) не обязательно могут применяться к выборкам. Другие команды действуют только по отношению к текущей выборке — как, например, команда, которая удаляет текущую выборку. Некоторые из этих команд вводятся с клавиатуры. Однако число клавиш на клавиатуре меньше, чем количество возможных команд. Каждая дополнительная клавиша-модификатор (как, например, <Shift>, <Alt>, <Command>, <Control> или <Option>) позволяет удвоить число клавиатурных команд. Полная клавиатура, в которой любая комбинация клавиш может быть воспринята компьютером, допускает астрономическое число сочетаний клавиш. Например, программное обеспечение, в котором предусмотрено использование любых трехклавишных дваждыквазимодальных сочетаний на 110-клавишной клавиатуре, позволяет передать более одного миллиона команд с помощью только одного жеста. Однако широкое использование клавиш-модификаторов, особенно в сочетаниях клавиш, очень часто приводит к появлению чрезвычайно сложных комбинаций, в которых можно просто «сломать пальцы». Кроме того, комбинации редко бывают запоминаемыми или понятными. (Знаете ли вы, какое действие выполняет на вашем компьютере сочетание <Control>+<Shift>+<Option>+<\>?) Запомнить различные сочетания клавиш не просто. Такое запоминание является недопустимым требованием к памяти пользователя. Кроме того, такие команды нарушают критерий видимости, если только в системе каким-то образом не отображается то, какой результат будет получен при применении той или иной команды. Конечно, если в отдельных случаях какой-то из этих жестов не может быть выполнен или если жест имеет разные значения в разные моменты, это означает модальность системы по отношению к данному жесту, что приводит к проблемам, которые обсуждались в главе 3.
Если разделить систему на приложения таким образом, что данная команда может многократно использоваться, но с разными значениями в разных приложениях, появляется возможность увеличить количество команд, которые пользователь может вызвать для заданного множества сочетаний клавиш.
Однако использование команд в приложениях, в которых для них устанавливаются разные значения, приводит к модальным ошибкам. Кроме того, различающийся смысл жеста создает ненужные трудности для его запоминания. Частично эта трудность облегчается с помощью меню. Тем не менее, пользователю все равно приходится запоминать, где находится та или иная команда. (Возможно, пользователю даже придется сначала вспомнить, в каком именно приложении используется необходимая ему команда, особенно если используется несколько приложений с подобными функциями.) Процесс просматривания меню иногда становится привычным, но иногда он оказывается утомительным, особенно если искомая команда находится в каком-то из подменю и если способ организации меню, который показался разработчику очевидным, не является таковым для пользователя.
Для назначения команд требуется такой метод, который был бы таким же быстрым и физически простым, как нажатие на пару клавиш, и с помощью которого было бы проще и быстрее найти необходимую команду, чем с помощью системы меню. Нежелательно повторять двойной метод, который используется в большинстве известных графических пользовательских интерфейсах и включает в себя как систему меню, так и набор непонятных горячих клавиш. Например, нет ничего запоминаемого в сочетании
Command↓ v↓ ↑↑
которое используется для вставки, кроме того, что клавиша v расположена рядом с клавишей c, используемой в сочетании
Command↓ c↓ ↑↑
которое запоминается несколько лучше, поскольку с может напоминать слова «вырезать» (cut) или «скопировать» (copy). Другой метод позволяет решить многие из этих проблем. Предположим, что на клавиатуре есть клавиша <Вычислить> (Calculate). При нажатии на эту клавишу текущая выборка рассматривается как арифметическое выражение и вычисляется. Далее я буду использовать подчеркивание, чтобы показать выборку. Допустим, что текст является следующим: Я хочу купить 3+4 рубашек При нажатии на клавишу <Вычислить> он будет преобразован в следующий текст: Я хочу купить 7 рубашек До нажатия на клавишу <Вычислить> 3+4 было обычным текстом, Он ничем не отличался от остального текста, за исключением того, что он был выделен.
Пять символов (включая пробелы), из которых состояла выборка, можно было переместить или удалить, или же к ним могла быть применена любая другая обычная команда текстового процессора. Но в данном случае была использована операция Вычислить. Пользователю не потребовалось открывать окно калькулятора или вызывать специальное приложение. Теперь рассмотрим случай, когда на клавиатуре нет клавиши <Вычислить>. (Хотя специальная клавиша для вычисления математических выражений — это пока только ценная идея, но она, несомненно, была бы более полезной, чем те клавиши, которые уже существуют, как, например, <F9>.) То, что нам необходимо — это более общий механизм для команд. Перед обсуждением такого механизма рассмотрим требования, которым должен отвечать новый метод вызова команд:
- Этот механизм не должен быть модальным
- Он должен включать любое число команд (в частности, он не должен ограничиваться количеством клавиш на клавиатуре)
- Пользователь должен иметь возможность вызывать команду непосредственно с клавиатуры
- Пользователь должен иметь возможность вызывать команду с помощью графического устройства ввода
- Использование механизма не должно требовать изобилия специальных клавиш
- Механизм не должен порождать большого количества квазирежимов
Важно также и то, что в этом случае пользователь может назначать команды самым простым способом — всего лишь набирая их с клавиатуры или рисуя их. Такой способ не противоречит методу, при котором команда выбирается из уже имеющегося списка. Преимуществом меню является то, что список команд, из которых оно состоит, является видимым. Тем не менее, вместо того чтобы выбирать команду из меню, пользователь может с такой же легкостью выбирать команду из небольшого документа, в котором содержится список всех команд. Такой документ может быть составлен как разработчиками, так и самим пользователем. Кроме того, в этом документе может быть не только список команд, но и, например, описания команд и даже заметки, сделанные пользователем. Такой документ, служащий в качестве меню, может использоваться как обычный текстовый документ, а не как нечто, что может быть изменено только программистами или только с помощью специальных средств настройки. Такой подход имеет ряд преимуществ. Например, онлайновые руководства автоматически содержат примеры использования команд, которые в нем описываются. В современных системах команды, имеющиеся в меню, могут как иметь, так и не иметь своего клавиатурного аналога. Однако при таком подходе каждая команда, описанная в меню последовательностью символов, имеет свой клавиатурный эквивалент. Это обеспечивается не благодаря стараниям разработчиков, а по самой природе такой системы. Как команда из меню, так и клавиатурный эквивалент имеют одинаковое написание. И большинство пользователей будут чаще использовать именно клавиатурный эквивалент. Другим преимуществом этого подхода является то, что вы можете составить меню только из тех команд, которые вы используете, просто набрав их в список с помощью текстового процессора. Конечно, если вы постоянно изменяете список, а не просто, скажем, добавляете к нему новые команды, то теряется преимущество их привычного расположения. Аналогично тому, как гиперссылки в тексте часто выделяются визуальными методами, например изменением цвета (обычно на синий) и подчеркиванием, команды также могут обозначаться какими-то особыми способами (например, красным цветом или обратным курсивом).
При таком выделении пользователь сможет указывать на имя команды (или на какую-то из букв ее имени) и затем вызывать ее нажатием на клавишу <Command>. В этом случае выделение команды для ее вызова перестает быть необходимым. Если для команд не использовать особый шрифт или цвет, то придется предусматривать другие правила для обозначения того, что какое-то слово или последовательность слов следует рассматривать как единую команду. Разумнее было бы избежать использования каких-то из существующих сегодня условностей, которые используются для группировки отдельных слов в одну единицу, разделенную пробелами или другими символами. Например, если бы у нас была команда, которую мы бы хотели назвать «преобразовать изображение в формат JPEG», то по существующим правилам нам пришлось бы написать ее в виде преобразовать.изображение.в.формат.JРЕG, <преобразовать изображение в формат JPEG> или преобразовать_изображение_в_формат_JРЕG. Такие способы написания являются слишком «компьютерными», неудобными и унылыми, особенно для тех, кто только знакомится с компьютерами. Синтаксис, который мы выбираем для написания команд, не должен исключать пробелы или символы новой строки. Любые ограничения, накладываемые на набор допустимых символов, используемых для набора команд, в будущем приведут к проблемам. Более того, любые подобные ограничения пользователю придется учитывать при назначении команде имени. Следует также иметь в виду и другой принцип, заключающийся в том, что использование обычаев, которые не совпадают с традициями обычной речи, приводит к возникновению непонимания между пользователем и компьютером. Следует сделать так, чтобы машина подстраивалась под нас, а не подстраивать обычаи естественной речи под то, что проще решить с точки зрения программирования. Еще одно взаимодействие ввода с клавиатуры и создания выборки вызывает проблемы в сегодняшних интерфейсах. В человекоориентированном интерфейсе ввод с клавиатуры не замещает выделенный текст и не отменяет выделение текущей выборки.
Это отличается от распространенного правила, в соответствии с которым ввод символов замещает содержимое текущей выборки, что время от времени приводит к проблемам в тех случаях, когда новый материал неожиданным для пользователя образом удаляет текст, который он не собирался удалять. Идея, что при вводе символов они должны замещать выборку, стала использоваться для того, чтобы сэкономить на одном нажатии клавиши — в большинстве редакторов, чтобы заместить текстовый блок, вы можете просто выделить его и начать ввод. Без этого правила пользователю придется сначала выделить некоторый текст, затем нажать <Backspace> или <Delete> и потом вводить новый текст. В способе, который используется сегодня, экономится только лишь нажатие на клавишу <Backspace>, при этом при первом нажатии текст исчезает и замещается текстом, который вводится далее. Это происходит независимо от того, находился ли замещаемый текст на экране или нет и (обычно) состоял ли он из нескольких символов или трех четвертей вашего документа. Таким образом, вне локуса вашего внимания вы можете удалить текст в 40 страниц. Если вы вовремя заметите это, то, наверное, сможете отменить действие. Но если же вы не заметите удаление, и если ничего не подскажет вам, что текст был удален, вам может не повезти. Человекоориентированный интерфейс никогда не подвергает работу пользователя риску. Экономия одного нажатия на клавишу куплена за слишком большую цену. Случайная потеря хотя бы одного символа может означать потерю части телефонного номера или адреса электронной почты, которая не может быть восстановлена из оставшейся части. Удаление текста должно проходить явным образом по желанию пользователя и не быть побочным эффектом другого действия. Понятие локуса внимания позволяет точно определить, что мы определяем как побочный эффект. Побочный эффект — это следствие применения команды, при котором изменяется содержание или события, которые не находятся в локусе вашего внимания. В только что рассмотренном случае в локусе вашего внимания находится текст, который вставляется, а побочным эффектом является удаление. Устранение побочных эффектов должно быть одной из целей для разработчика человекоориентированпого интерфейса. Другой возможностью текстовых процессоров, которая часто считается полезной, является перетаскивание выделенного текста из одного места в другое.
Однако при этом у пользователя нет возможности создать другую выборку, которая пересекалась бы с текущей, или создать под выборку текущей выборки. Если вы попытаетесь сделать какую-нибудь из этих выборок, система воспримет это действие как попытку переместить текущую выборку. Это означает, что сначала вам следует щелкнуть в каком-то месте вне выборки, чтобы снять ее выделение. Таким образом, жесту перетаскивания были даны два разных значения, а именно: выделение и перетаскивание выборки. Это может препятствовать формированию привычки. Ошибки возникают в результате того, что, хотя символы выборки находятся в локусе вашего внимания, текущее состояние выборки не находится в локусе вашего внимания, несмотря на то, что оно визуально выделено. Во время моих наблюдений я видел, как некоторые пользователи могли случайно перетащить выборку, хотя собирались создать новую выборку. Другая проблема возникает при перетаскивании текста (она также может возникать и в графических программах): иногда случается так, что как только вы начинаете перетаскивать выборку, выясняется, что место, куда вы хотите перенести ее, не видно на экране. В этом случае приходится возвращать выборку обратно или ставить ее в другое место и применять метод вырезания и вставки. Принцип монотонности предполагает, что предпочтительным является наличие только одного метода. В некоторых системах при перетаскивании выборки к нижнему или верхнему краю экрана автоматически начинается его прокрутка, но она происходит слишком медленно, если место назначения находится на расстоянии нескольких страниц. Кроме того, прокрутка может происходит и слишком быстро, что не позволяет остановиться или даже заметить необходимое место. Если бы не маркетинг, я бы не стал оснащать интерфейс возможностью перетаскивания текста, по крайней мере, в том виде, в каком эта опция сейчас используется на персональных компьютерах. В этом случае меньшее число ошибок и проблем было бы хорошей компенсацией для тех пользователей, которые привыкли к возможности перетаскивать текст.
Желательно, чтобы для выделения и для перетаскивания использовались отдельные квазирежимы, поскольку тогда не будет возникать «когнитивная путаница» между этими опциями. Например, ГУВ может быть снабжено кнопкой для создания выборок, а также специальным устройством (например, встроенной сбоку кнопкой), с помощью которой можно было бы сжимать ГУВ (при этом для того, чтобы было понятно, что действие произошло, важно наличие тактильной обратной связи, например в виде щелчка кнопки), что означало бы, что вы забрали выборку. В этом случае между этими функциями не возникало бы никакой путаницы (или она была бы минимальной). После нескольких секунд объяснений и одной-двух попыток использования такого устройства уже было бы понятно, как им пользоваться. Более простой метод для разделения функций выделения и перетаскивания заключается в том, чтобы использовать другую кнопку мыши для перетаскивания или же использовать квазирежим (например, удерживание в нажатом положении специальной, ясно обозначенной кнопки во время использования основной кнопки мыши). (См. более подробно в приложении А.) Функцию перетаскивания, которой может быть оснащен ГУВ, можно также использовать вместо прокручивания. Вы можете захватывать какую-то часть документа и с помощью этого устройства перемещать ее: верх или вниз — в узких документах, и во всех направлениях — в широких документах. Когда курсор перетаскивания (который в некоторых из сегодня существующих системах разумно отображается в виде руки) достигает границы экрана, прокручивание продолжается в выбранном направлении до тех пор, пока пользователь не отпустит устройство перетаскивания или не вернет курсор обратно внутрь окна. Метод прокручивания с помощью полос прокрутки может приводить к путанице. В частности, при нажатии на кнопку со стрелкой вниз содержимое экрана прокручивает вверх. Если же использовать стрелки, повернутые в другую сторону, это создаст только еще большую путаницу. Кроме того, кнопки со стрелками на полосе прокрутки имеют небольшие размеры и поэтому требуют больше времени при использовании, а, как хорошо показывает анализ по закону Фитса, возможность захватывать элементы в любой части документа является намного более быстрым способом. Вышеописанный пример со специальной функцией захватывания, которой может быть оснащена мышь, показывает, что при разработке интерфейсов программного обеспечения часто могут возникать идеи по улучшению аппаратного оборудования, так же как те или иные характеристики аппаратного строения могут приводить к улучшению программного обеспечения.Необходимо сказать, что всегда лучше разрабатывать аппаратное и программное обеспечение вместе, несмотря на то, что такая возможность редко случается. Попытки «подставить» чистый программный интерфейс в аппаратное оборудование, которое было разработано для другого интерфейса, редко могут дать удовлетворительные результаты. Тем не менее, в большинстве случаев это именно то, что мы должны сделать.
