Интерфейс: новые направления в проектировании компьютерных систем

Аккуратный подсчет есть путь к знаниям всех существующих вещей и тайных секретов.

Папирусы Рхинда, 1650 г. до н. э.

Аккуратный подсчет есть путь к знаниям всех существующих вещей и тайных секретов.

Полезно подробно рассмотреть пример вычисления среднего количества информации, требуемого для некоего интерфейса. Для этого я снова использую пример интерфейса для перевода температур из одной шкалы в другую. В соответствии с условиями требуется, чтобы количество символов, вводимых в температурный преобразователь, равнялось в среднем 4. Кроме того, по условиям задачи десятичная точка используется однократно в 90 % вводимых данных, а в 10 % – вообще не встречается; знак минус появляется один раз в 25 % данных и совсем не встречается в остальных 75 % данных. Из соображений простоты, а также потому, что не требуется ответ с точностью до 1 %, я буду исходить из того, что все остальные цифры встречаются с одинаковой частотой, и не буду учитывать те 10 % данных, которые не содержат десятичной точки.

Требуется определить множество возможных вариантов ввода и их вероятности. Возможны 5 вариантов (d означает цифру):

1. -.dd

2. -d.d

3. .ddd

4. d.dd

5. dd.d

Первые два варианта встречаются в 12.5 % случаев, и количество каждого из них составляет 100. Каждый из последних трех вариантов встречается в 25 % случаев, и количество каждого из них составляет почти 1000.[24] Вероятность каждого из первых двух вариантов ввода составляет (0.125/100)=0.00125. Вероятность любого из последних трех вариантов ввода составляет (0.75/3000)=0.00025. Сумма вероятностей, как это и должно быть, составляет 1.

Количество информации (в битах), передаваемое каждым вариантом, определяется выражением (2):[25]

p(i) \log_2(1/p(i))

Значение этого выражения составляет приблизительно 0.012 для отрицательных значений ввода и 0.003 – для положительных. 200*0.00674+3000*0.003 дает в сумме 11.4 бита для каждого варианта ввода.

Важно учесть вероятности вариантов. Если использовать простой подход, в котором все 12 символов (минус, десятичная точка и 10 цифр) принять как равновероятные, то вероятность каждого символа составит 1/12, а количество информации, содержащейся в 4-значном варианте ввода, составит приблизительно

4 \log_2(12)≈14 бит

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

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

Другим упрощением, позволяющим провести быстрый анализ интерфейса, является вычисление различных жестов на основе количества информации, передаваемого одним нажатием клавиши или одной операцией ГУВ. При передаче информации нажатием клавиши ее количество зависит от общего количества клавиш и относительной частоты использования каждой из них. Таким образом, нажатия клавиши могут использоваться как приблизительная мера информации. Если на клавиатуре имеется 128 клавиш, и каждая из них используется с одинаковой частотой, то нажатие любой из них будет передавать 7 бит информации. В действительности частота использования клавиш субщественно различается. Например, пробел или буква е используются чаще, чем й или \, поэтому в большинстве приложений на каждое нажатие клавиши приходится в среднем около 5 битов. По условиям нашей задачи среднее число символов вводимых температурных значений не должно превышать 4.

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

Если в нашем интерфейсе потребуется вводить в среднем 4 символа, то символьная эффективность такого интерфейса составит 100 %. При добавлении еще одной клавиши, обозначающей шкалу перевода температурного значения, а также еще одной для разделения, средняя длина ввода возрастет до 6 символов, а символьная эффективность снизится до 67 %. Если в качестве устройства ввода Хол будет использовать числовую клавиатуру, состоящую из 16 клавиш, то каждой отдельной клавишей будет передаваться 4 бита информации, и поэтому производительность интерфейса возрастет. (Однако по условиям задачи такой возможности не предусмотрено.)

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

M + K + K + K + K = 2.15 с

Таким образом, он будет значительно быстрее, чем любой из двух уже рассмотренных вариантов. Однако введение 4 символов с помощью стандартной клавиатуры дает, по крайней мере, 20 бит информации, тогда как требуется только 10. Следовательно, теоретическая информационная производительность составляет 55 %, а значит, существует возможность улучшения. Как мы уже видели, использование стандартной числовой клавиатуры вместо полной клавиатуры снижает объем информации, вводимой на каждые 4 символа, до 16 бит, что повышает производительность до 60 %. Желаемая числовая клавиатура, содержащая только цифры, знак минус и десятичную точку, позволит немного повысить производительность – до 70 %. Дальнейшее повышение производительности возможно через использование особых кодировок обозначений температуры и изобретение новых устройств ввода, но здесь возникают трудности, связанные с обучением и лишними расходами, поэтому остановимся на варианте с 70 % теоретической информационной производительности. Независимо от того, могут ли теоретические границы быть достигнуты на практике или нет, они дают нам направление в разработке интерфейса.

4.3.2. Другие решения интерфейса для Хола

В разделе 4.3.1 мы приостановили дальнейшие попытки улучшения интерфейса, достигнув 70 % теоретической информационной производительности. Данная производительность определена для пока еще неизвестного, теоретического интерфейса, в котором каким-то образом можно получить 100 % эффективность использования клавиш. Давайте посмотрим, насколько мы можем приблизиться к этому идеалу с помощью стандартной клавиатуры и ГУВ.

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

Для перевода температуры из одной шкалы в другую укажите нужную шкалу с помощью символа C (шкала Цельсия) или F (шкала Фаренгейта). Введите числовое значение температуры, затем нажмите клавишу Enter. Результат преобразования будет отображен на экране.

GOMS-анализ показывает, что пользователь должен сделать 6 нажатий клавиш. По правилам расстановки операторов M получаем. следующую запись:

M K K K K K M K

Среднее время составит 3.9 с.

Мы можем уменьшить это время, если сами символы C и F будем использовать в качестве разделителей. Рассмотрим интерфейс, в котором появляется следующая инструкция:

Для перевода температуры из одной шкалы в другую введите числовое значение температуры и следом поставьте символ C, если оно в шкале Цельсия, или F, если оно в шкале Фаренгейта. Результат преобразования будет отображен на экране.

В данном примере нажимать на клавишу «Enter» не требуется. Некоторые примитивные средства разработки интерфейсов требуют, чтобы пользователь обязательно использовал клавишу «Enter», и поэтому в них невозможно использовать символы C и F в качестве разделителей. Такие инструменты не подходят для разработки человекоориентированных интерфейсов.

GOMS-анализ показывает, что для интерфейса с символами C и F в качестве разделителей запись будет следующей:

M K K K K M K

Среднее время составит 3.7 с. Если бы мы не знали, что теоретически минимальное время составляет 2.15 с, то это решение могло бы показаться удачным. Оно является значительно более эффективным, чем ранее рассмотренные, поэтому мы могли бы на нем остановиться. Однако теоретический минимум подстегивает нас к поиску еще более быстрой интерфейсной модели. Рассмотрим интерфейс, изображенный на рис. 4.5. Такой интерфейс можно назвать разветвленным. В нем один ввод дает в результате два вывода.

Рис. 4.5. Интерфейс, в котором не используется разделитель. Более эффективным является вариант, в котором выполняется посимвольная обработка вводимых данных и одновременное преобразование в обеих шкалах

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

M K K K K

В разветвленном интерфейсе достигается минимальное время 2.15 с, и его символьная эффективность составляет 100 %.

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

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

Разветвленный интерфейс не обязательно является самым лучшим из тех, что уже были рассмотрены – или из тех, что возможны, – только потому, что он имеет оптимальную скорость работы и является весьма эффективным. Кроме скорости есть и другие параметры, которые также являются важными: частота появления ошибок; время, необходимое для изучения интерфейса; возможность длительного запоминания способа использования интерфейса. Особенно следует обратить внимание на частоту появления ошибок в разветвленном интерфейсе, поскольку есть вероятность того, что Хол может прочитать результат не из того поля. Это важно особенно потому, что когда он услышал, например слово Цельсий, ему необходимо прочитать значение из поля шкалы Фаренгейта. Тем не менее, разветвленный температурный преобразователь определенно входит в небольшое число тех интерфейсов, которые можно рассматривать как рабочие варианты для программы преобразования температурных значений из одной шкалы в другую. Другие рассмотренные нами примеры, которые могли бы показаться удачными, если бы мы не проводили с ними GOMS-анализ, на самом деле не являются таковыми.

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

4.4. Закон Фитса и закон Хика

Основы знаний надлежит искать в математике.

Роджер Бэкон «Opus Majus», XIII в.

Различные количественные законы, имеющие отношение к разработке интерфейсов, имеют хорошее когнитивное обоснование, и их правильность была неоднократно проверена. Эти законы часто дают нам дополнительные данные, на основе которых можно принимать те или иные решения, связанные с разработкой интерфейсов. Закон Фитса (Fitts' Law) позволяет определить количественно тот факт, что чем дальше находится объект от текущей позиции курсора или чем меньше размеры этого объекта, тем больше времени потребуется пользователю для перемещения к нему курсора. Закон Хика (Hick's Law) позволяет количественно определить наблюдение, заключающееся в том, что чем больше количество вариантов заданного типа вы предоставляете, тем больше времени требуется на выбор.

4.4.1. Закон Фитса

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

В одномерном случае, при котором размер объекта вдоль линии перемещения курсора обозначается как S, а дистанция от начальной позиции курсора до объекта – как D (рис. 4.6), закон Фитса формулируется следующим образом:

Время (мс) = a + b \log_2(D/S+1)

(Константы a и b устанавливаются опытным путем по параметрам производительности человека.)[26]

Рис. 4.6. Расстояния, которые используются в законе Фитса для определения времени, необходимого для перемещения курсора к цели

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

Для вычисления времени можно использовать любые единицы измерения дистанции, т. к. D/S является отношением двух дистанций и поэтому не зависит от единицы измерения. Отсюда следует, что хотя указательное устройство может переместиться на расстояние большее или меньшее, чем то расстояние, на которое переместится на экране курсор, закон все равно работает, при условии, что соотношение между движением ГУВ и курсора является линейным. Закон Фитса может применяться только к тем типам перемещения, которые совершаются при использовании большинства человеко-машинных интерфейсов, т. е. к таким перемещениям, которые невелики относительно размеров человеческого тела и которые являются непрерывными (совершаемыми одним движением). Для приближенных вычислений я использую следующие значения констант в уравнении закона Фитса: a=50, b=150.

Также проводились тестирования с законом Фитса, дополненным некоторыми более сложными параметрами, такими, например, как перемещение курсора между прямыми или искривленными границами (Accot и Zhai, 1997). Для двумерных целей обычно можно получить корректное приближенное значение времени, необходимого для перемещения курсора к объекту, используя в качестве параметра S наименьшее из значений размеров объекта по горизонтали или по вертикали (Mackenzie, 1995).

Рис. 4.7. Меню в Macintosh, расположенное у верхней границы экрана, увеличивается в размере, что является более эффективным по сравнению с меню, которое всплывает из-за границы экрана

Закон Фитса позволяет объяснить, например, почему переместить курсор к меню в стиле Apple Macintosh, располагающемуся на границе экрана (рис. 4.7), намного быстрее, чем переместить курсор к меню в стиле Microsoft Windows, которое всплывает из-за границы экрана (рис. 4.8). Размер S меню в Windows на моем экране составляет 5 мм. Эффективный размер меню в Macintosh является довольно большим, потому что пользователю не требуется останавливаться в пределах полосы меню; он может просто передвинуть ГУВ на любое расстояние превышающее расстояние, необходимое для размещения курсора в пределах меню, – курсор в любом случае остановится на границе экрана.

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

Ряд выполненных мной тестов помог установить, что пользователи Macintosh обычно останавливаются в пределах 50 мм от границы экрана, поэтому для Macintosh мы можем принять 50 мм как S. При использовании 14-дюймового плоского монитора среднее расстояние, на которое требуется переместить курсор, чтобы достичь панели меню, составляет 80 мм. Таким образом, время перемещения курсора к какому-либо из элементов меню в Macintosh будет:

50 + 150 \log_2(80/50+1) = 256 мс

Это время является намного меньшим, чем то, которое требуется на перемещение курсора к необходимому элементу меню в Windows:

50 + 150 \log_2(80/5+1) = 663 мс

Полученные значения времени относятся только лишь к перемещению курсора. Щелчок по целевому объекту, к которому перемещался курсор, добавляет в среднем еще 0.1 с. (Значение оператора K=0.2, принятое в модели GOMS, учитывает и нажатие кнопки, и ее отпускание, в то время как указанное значение учитывает только нажатие кнопки.) При проведении обычного эксперимента вам придется добавить еще 0.25 с, чтобы учесть время человеческой реакции в начале движения курсора. С учетом всех этих факторов мы получим именно те значения, которые я получил экспериментальным путем: в среднем пользователю требуется около 0.6 с, чтобы открыть Apple-меню, в то время как для открытия Windows-меню требуется более 1 с. Таким образом, этот анализ объясняет, почему при разработке интерфейса Macintosh меню были намеренно помещены на границе экрана.

4.4.2. Закон Хика

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

Время (мс) = a + b \log_2(n+1)

Если вероятность 1-го варианта равна p(i), то вместо логарифмического коэффициента используется

\sum_i p(i) \log_2(1/p(i)+1)

Коэффициенты, используемые в выражении закона Хика, в большой степени зависят от многих условий, включая то, как представлены возможные варианты, и то, насколько хорошо пользователь знаком с системой. (Если варианты представлены непонятным образом, значения a и b возрастают. Наличие навыков и привычек в использовании системы снижает значение b.) Мы не будем рассматривать эти зависимости – для нас важно, что для принятия того или иного решения требуется время; что для принятия сложных решений требуется больше времени, чем для принятия простых решений; и что взаимосвязь является логарифмической. При отсутствии более точных данных для проведения быстрых и приблизительных вычислений мы можем воспользоваться теми же значениями a и b, которые использовали для закона Фитса.

При использовании любых положительных и ненулевых значений a и b из закона Хика следует, что предоставление пользователю сразу нескольких вариантов одновременно обычно является более эффективным, чем организация тех же вариантов в иерархические группы. Выбор из одного меню, состоящего из 8 элементов, производится быстрее, чем из двух меню, состоящих их 4 элементов каждое. Если все элементы могут быть выбраны с равной вероятностью и если не учитывать время, необходимое для открытия второго меню (которое, конечно, еще более увеличило бы время для интерфейса, состоящего из двух меню), то сравнение времени для выбора одного элемента из восьми (a + b \log_2 8) с удвоенным временем для выбора одного элемента из четырех 2 (a + b \log_2 4) покажет, что

а + 3b < 2(а + 2b)

поскольку \log_2 8 = 3, a \log_2 4 = 2, а также поскольку a < 2a и 3b < 4b.

Это согласуется с данными, полученными в экспериментах со структурами меню (см. например, Norman и Chin, 1988).

Наше рассмотрение законов Фитса и Хика нельзя считать полным. Например, следует обратить внимание на то, что эти законы не случайно принимают ту же форму, что и теорема Шэннона – Хартли (Shannon-Hartley). Тем не менее, этого короткого рассмотрения вполне достаточно для того, чтобы отметить их ценность с точки зрения разработки интерфейсов. Они могут быть полезными даже в том случае, когда эмпирические значения коэффициентов a и b не известны (как это было в нашем примере). (Более подробные сведения см. в Card, Moran и Newell, 1983, с. 72–74.)

5. Унификация

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

К. Стрэтчи (говоря не о Windows, а о компьютере IBM Stretch в 1962 г.)

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

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

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

Разные приложения имеют разные наборы команд, и пользователь обычно не может в целом использовать команды приложения А при работе с приложением В или наоборот. Если же сделать команды независимыми от приложений, то тем самым мы сможем устранить модальность, которая изначально им присуща. При такой унификации общее количество команд, которое пользователю придется запоминать, существенно сократится, – главным образом потому, что унификация позволит избавиться от огромного числа повторений команд. Например, в компьютере Canon Cat с помощью всего 20 команд можно было управлять текстовым процессором, электронными таблицами, созданием, сортировкой и обработкой баз данных, вычислениями и т. д. В современных системах аналогичной мощности используется более 100 команд для выполнения того же самого набора задач. Тысячи команд, которые используются в современных средах, можно было бы сократить до сотни. Так как не все команды могут применяться ко всем типам данных, возникнет необходимость применять к объектам преобразователи типов данных, чтобы создать новые объекты, к которым при определенных условиях уже можно будет применить выбранную команду.

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

Хотя Eudora и Microsoft Word являются программами, в которых можно изменять меню, тем не менее, для изменения его содержания вы должны использовать только специально предназначенные для этого средства. В данном случае мы как раз и говорим о том, что должна быть возможность создавать меню обычными средствами создания и редактирования текстов. В этом смысле меню можно рассматривать как содержание.

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

5.1. Унификация и элементарные действия

Сущности не должны множиться без необходимости.

Уильям Оккамский

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

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

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

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

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

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

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

Для создания человекоориентированного интерфейса для компьютеров или компьютерных систем (таких, например, как Palm Pilot) важным шагом является обеспечение одинаковых правил для всех случаев, в которых вводится или редактируется текст. Например, в Macintosh или Windows вы не можете при вводе имени файла сделать его орфографическую проверку, поэтому, если вы не уверены в правильности написания слова рандеву (randezvous), которое вы хотите использовать в качестве имени файла,[27] то вам придется вводить его наугад или открыть текстовый процессор и набрать в нем (или скопировать) это слово, чтобы проверить правильность написания. Могу предположить, что если бы я подал разработчикам программного обеспечения идею о том, чтобы пользователь мог проверять орфографию файловых имен, то они, весьма вероятно, и добавили бы такую возможность, но такое особое добавление, – которое, вероятно, было бы решено в виде какого-нибудь нового элемента в одном из системных меню (скорее всего, меню Правка), – только бы увеличило и без того абсурдную сложность программного обеспечения. Наилучшим решением здесь было бы упрощение на основе уже описанной идеи, заключающейся в том, что одна команда орфографической проверки должна применяться к любому тексту, независимо от того, какую роль он играет в данный момент.

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

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