Интерфейс: новые направления в проектировании компьютерных систем
Добавить в закладки К обложке
- ВведениеВажность основ - Страница 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.3. Такие тумблеры нельзя переключить в другое положение случайно. Перед тем как изменить положение тумблера, его ручку сначала требуется немного вытянуть из пульта
____________Режимы также ограничивают диапазон действий пользователя. Если жест g вызывает действие a в режиме A, а в режиме B он вызывает действие b, то для того чтобы выполнить действие a, необходимо сначала выйти из режима B (если вы в нем находились) и переустановить интерфейс в режим A. И только после этого вы сможете использовать жест g для выполнения действия a. Разделение интерфейса на ограниченные области является неизбежным следствием наличия режимов. Набор состояний, в которых жест g имеет конкретную интерпретацию, можно назвать диапазоном (range) жеста g. Программное обеспечение, которое продается в виде прикладных программ, например электронные таблицы, обычно включает один или несколько пересекающихся диапазонов. Некоторые диапазоны относительно велики. Например, следующая последовательность выполняет действие вырезания почти во всех приложениях как на платформе Macintosh, так и в Windows:
Command↓ x↑
Бывают и небольшие диапазоны. Например, нижеприведенная последовательность позволяет в некоторых компьютерных играх открывать сундук с сокровищами, если только он находится в пределах видимости:
Command↓ h↑
Группирование команд по разным диапазонам, или, как мы это еще называем, по приложениям, позволяет понять и научиться использовать сложные интерфейсы. Тем не менее, существует возможность организовывать интерфейсы, которые могли бы создавать меньше ограничений, чем режимы. Полностью человекоориентированный интерфейс должен состоять только из одного диапазона.
В случаях когда интерфейс управляется с помощью другого компьютера, можно было бы подумать, что проблема наличия режимов снимается, поскольку машина может легко запомнить необходимое состояние интерфейса, просто-напросто внутренне синхронизируя его с собственным состоянием. Тем не менее, если интерфейс является модальным, и программа, управляющая этим интерфейсом, изначально не получает сведений о текущем состоянии интерфейса, – а это может произойти, если программа подключается после того, как система была запущена, – то для управления в каком-то из режимов системы программа должна быть оснащена средствами тестирования ее текущего состояния. В этом отношении особые трудности создают такие интерфейсные переключатели, для возвращения которых в исходную позицию требуется сделать подряд несколько переключений, изменив состояние системы (затем цикл повторяется сначала).
Случай, когда интерфейс управляется внешней программой, относится к вопросу разработки человеко-машинных интерфейсов, поскольку набор сохраняемых команд (называемый макросом), который может быть выполнен одним жестом, является рудиментарной формой компьютерной программы. Макрос не может установить такой переключатель в какое-либо из его допустимых состояний, если сам макрос сначала не задаст системе вопрос о ее текущем состоянии. Об этой проблеме мы уже говорили на примере фонарика в сумке. Одно из возможных решений состоит в том, чтобы обеспечить установку переключателя, имеющего несколько положений, в некое начальное состояние сразу после каждого случая его использования. В результате этого подсчет числа переключений позволит всегда определить текущее состояние переключателя. Если предполагается, что переключатель будет использоваться человеком, то целесообразно предусматривать не более 5 состояний переключателя. Другим решением может быть применение набора переключателей (radio buttons).
Тем не менее, на этом список проблем, к которым могут приводить режимы, не исчерпывается. Ко всему прочему, режимы могут еще лишать пользователя возможности взаимодействия с системой. Это особенно заметно в том случае, когда вы вынуждены прервать свою работу, чтобы ответить на возникшее окно сообщения. Некоторые разработчики считают, что принуждение пользователя остановиться или работать в жестких рамках установленной последовательности действий оказывается полезным, так как позволяет системе самой «направлять» действия пользователя. При некоторых обстоятельствах важно, чтобы пользователь принял то или иное конкретное решение к какому-то моменту времени или перед выполнением следующего шага из последовательности. Если же пользователь не имеет возможности принять свое решение, то и необходимости диалога с ним нет. В первом случае достаточно только поместить на экране часы с обратным отсчетом, но не следует ограничивать пользователя в том, чтобы в это время он мог совершать в системе и другие действия. Во втором случае пусть на экране появляется сообщение, в котором говорилось бы, что перед выполнением очередного шага необходимо принять следующее решение, но система не должна препятствовать пользователю в выполнении других операций, не относящихся к текущей программной последовательности. Необходимо учитывать, например, что для принятия решения пользователю требуется просмотреть какой-то файл или выполнить какие-то вычисления. Другими словами, запросы и подсказки должны даваться не модально, а так, чтобы пользователь мог в максимальной степени сохранять контроль над системой.
- 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