Интерфейс: новые направления в проектировании компьютерных систем
Добавить в закладки К обложке
- ВведениеВажность основ - Страница 1
- 1. Предпосылки - Страница 3
- 1.1. Определение интерфейса - Страница 4
- 1.2. Простое должно оставаться простым - Страница 5
- 1.3. Ориентация на человека и на пользователя - Страница 6
- 1.4. Инструменты, которые препятствуют новым идеям - Страница 7
- 1.5. Разработка интерфейса как часть общего цикла разработки - Страница 8
- 1.6. Определение человекоориентированного интерфейса - Страница 10
- 2. Когнетика и локус внимания - Страница 11
- 2.1. Эргономика и когнетика: что мы можем и чего не можем - Страница 12
- 2.2. Когнитивное сознательное и когнитивное бессознательное - Страница 13
- 2.3. Локус внимания - Страница 17
- 2.3.1. Формирование привычек - Страница 19
- 2.3.2. Одновременное выполнение задач - Страница 21
- 2.3.3. Сингулярность локуса внимания - Страница 23
- 2.3.4. Истоки локуса внимания - Страница 26
- 2.3.5. Эксплуатация единого локуса внимания - Страница 27
- 2.3.6. Возобновление прерванной работы - Страница 28
- 3. Значения, режимы, монотонность и мифы - Страница 29
- 3.1. Терминология и условные обозначения - Страница 30
- 3.2. Режимы - Страница 32
- 3.2.1. Определение режимов - Страница 36
- 3.2.2. Режимы, пользовательские настройки и временные режимы - Страница 39
- 3.2.3. Режимы и квазирежимы - Страница 44
- 3.3. Модели «существительное-глагол» и «глагол-существительное» - Страница 46
- 3.4. Видимость и состоятельность - Страница 48
- 3.5. Монотонность - Страница 50
- 3.6. Миф о дихотомии «новичок-эксперт» - Страница 52
- 4. Квантификация - Страница 54
- 4.1. Количественный анализ интерфейса - Страница 55
- 4.2. Модель скорости печати GOMS - Страница 56
- 4.2.1. Временные интервалы в интерфейсе - Страница 57
- 4.2.2. Расчеты по модели GOMS - Страница 59
- 4.2.3. Примеры расчетов по модели GOMS - Страница 60
- 4.2.3.1. Интерфейс для Хола: вариант 1. Диалоговое окно - Страница 61
- 4.2.3.3. Интерфейс для Хола: вариант 2. ГИП (GUI, graphical user interface) - Страница 62
- 4.3. Измерение эффективности интерфейса - Страница 63
- 4.3.1. Производительность интерфейса для Хола - Страница 66
- 4.3.2. Другие решения интерфейса для Хола - Страница 68
- 4.4. Закон Фитса и закон Хика - Страница 70
- 4.4.1. Закон Фитса - Страница 71
- 4.4.2. Закон Хика - Страница 72
- 5. Унификация - Страница 73
- 5.1. Унификация и элементарные действия - Страница 74
- 5.2. Каталог элементарных действий - Страница 76
- 5.2.1. Подсветка, указание и выделение - Страница 78
- 5.2.2. Команды - Страница 81
- 5.2.3. Экранные состояния объектов - Страница 85
- 5.3. Имена файлов и файловые структуры - Страница 87
- 5.4. Поиск строк и механизмы поиска - Страница 91
- 5.4.1. Разделители в шаблоне поиска - Страница 93
- 5.4.2. Единицы взаимодействия - Страница 94
- 5.5. Форма курсора и методы выделения - Страница 96
- 5.6. Позиция курсора и клавиша «LEAP» - Страница 99
- 5.7. Ликвидация приложений - Страница 101
- 5.8. Команды и трансформаторы - Страница 104
- 6. Навигация и другие аспекты человекоориентированных интерфейсов - Страница 108
- 6.1. Интуитивные и естественные интерфейсы - Страница 109
- 6.2. Улучшенная навигация: ZoomWorld - Страница 111
- 6.3. Пиктограммы - Страница 117
- 6.4. Способы и средства помощи в человекоориентированных интерфейсах - Страница 121
- 6.4.1. Вырезать и вставить - Страница 124
- 6.4.2. Сообщения пользователю - Страница 125
- 6.4.3. Упрощение входа в систему - Страница 128
- 6.4.4. Автоповтор и другие приемы работы с клавиатурой - Страница 129
- 6.5. Письмо от одного пользователя - Страница 131
- 7. Проблемы за пределами пользовательского интерфейса - Страница 134
- 7.1. Более человекоориентированные среды программирования - Страница 135
- 7.1.2. Важность ведения документации при создании программ - Страница 137
- 7.2. Режимы и кабели - Страница 138
- 7.3. Этика и управление разработкой интерфейсов - Страница 140
- Заключение - Страница 143
- Приложения - Страница 144
- B. Теория работы интерфейса для SwyftCard - Страница 146
- Библиография - Страница 148
3.2. Режимы
Поскольку люди более уступчивы, чем компьютеры, бывает легче заставить человека приспособиться к ограничениям компьютера, чем создать компьютер, приспособленный к потребностям человека. И когда это происходит, человек попадает в подчинение к компьютеру, а вовсе не освобождается им.
Карла ДженнингзРежимы (modes) являются важным источником ошибок, путаницы, ненужных ограничений и сложности в интерфейсе. Многие проблемы, создаваемые режимами, хорошо известны. Тем не менее, практика создания систем без режимов почему-то не находит широкого применения в разработке интерфейсов. Прежде чем приступить к обсуждению методов устранения режимов, следует рассмотреть их подробно, тем более что даже среди специалистов по интерфейсам нет общего мнения относительно того, что представляет собой режим (Johnson and Engle-beck, 1989).
Чтобы понимать режимы, нам следует сначала определить понятие жеста. Жест (gesture) – это последовательность действий человека, которая выполняется автоматически (после старта). Например, для опытного пользователя набор такого простого слова, как это, представляет всего один жест, в то время как для начинающего пользователя, который еще не вполне овладел клавиатурой, набор этого слова по буквам будет состоять из отдельных жестов. Объединение последовательности действий в жест, связанный с определенным психологическим процессом, определяется как формирование модуля (chunking), т. е. соединение отдельных элементов когнитивного процесса в единый ментальный модуль, что позволяет воспринимать множество элементов как целое (Buxton,1986, с. 475–480; Miller, 1956).
В большинстве интерфейсов допускается несколько интерпретаций конкретного жеста. Например, в одном случае с помощью клавиши «Return» можно вставить в текст символ возврата каретки, тогда как в другом случае нажатие этой клавиши приводит к исполнению предшествующей строки в качестве команды.
Режимы проявляются в том, как реагирует интерфейс на тот или иной жест. Состояние интерфейса, при котором интерпретация данного конкретного жеста остается неизменной, называется режимом. Если жест получает другую интерпретацию, это значит, что интерфейс находится в другом режиме. Такое определение дает ценное первоначальное представление о том, что составляет режим. Позже мы уточним это определение.
Фонарик, управляемый с помощью кнопочного выключателя, может быть либо включен, либо выключен при условии, что он находится в хорошем рабочем состоянии. При нажатии кнопки свет зажигается, если фонарик находился перед этим в выключенном состоянии, и наоборот, если текущее состояние «включено», то после нажатия кнопки фонарик выключается. Два состояния фонарика соответствуют двум режимам интерфейса. В одном режиме нажатие кнопки включает свет. В другом режиме нажатие кнопки выключает свет. Если вы не знаете текущее состояние фонарика, вы не можете предсказать, к чему приведет нажатие кнопки. Если ваш фонарик лежит глубоко в сумке, и вы его не видите, то не можете узнать, включен свет или нет, при условии, что это нельзя почувствовать по температуре. Чтобы убедиться, что фонарик выключен, вам требуется вынуть его из сумки. Невозможность определить текущее состояние фонарика – это пример классической проблемы, возникающей в интерфейсе, в котором есть режимы. По состоянию управляющего механизма невозможно сказать, какое действие следует выполнить, чтобы достичь поставленной цели. Оперируя с управляющим механизмом без одновременной проверки состояния системы, вы не сможете предсказать, какой результат будет иметь данная операция.
К переключателям трудно подобрать надписи. Например, однажды мне показали интерфейс, в котором кнопка на экране была подписана Lock (Блокировать). Когда пользователи в первый раз видели эту кнопку, они считали, что должны нажать на нее для блокировки данных в этом окне. Когда они делали так, подпись кнопки изменялась на Unlock (Разблокировать), показывая, что при нажатии на эту кнопку данные разблокировались бы. После этого многие пользователи удивлялись, что данные оказывались разблокированными, поскольку кнопка показывала Unlock, что они считали индикатором текущего состояния, как это часто бывает при использовании переключателей на кнопках и в меню. Естественно, это приводило к путанице: на самом деле кнопка показывала Lock, когда данные были разблокированы, и Unlock – когда они были заблокированы. Очевидно, что проблему нельзя решить, просто поменяв надписи таким образом, чтобы разблокированные данные обозначались как Unlock, а заблокированные как Lock.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
- 132
- 133
- 134
- 135
- 136
- 137
- 138
- 139
- 140
- 141
- 142
- 143
- 144
- 145
- 146
- 147
- 148
- 149
- 150