Интерфейс: новые направления в проектировании компьютерных систем
Добавить в закладки К обложке
- ВведениеВажность основ - Страница 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
5. Унификация
Это чрезвычайно хитроумно, чрезвычайно сложно и крайне эффективно, но в то же время грубо, неэкономно и топорно, и чувствуется, что есть лучший способ.
К. Стрэтчи (говоря не о Windows, а о компьютере IBM Stretch в 1962 г.)Если пытаться создать универсальный интерфейс, в котором были бы учтены те требования, о которых шла речь в предыдущих главах, то выяснится, что для этого нужно радикально изменить нашу обычную практику. Здесь возможно много направлений. Одно из них заключается в том, чтобы посмотреть, что мы можем сделать в условиях существования Интернета и сотен миллионов компьютеров, а также других устройств обработки информации, которые уже существуют или которые только разрабатываются сегодня.
В настоящее время аппаратная конфигурация обычного персонального компьютера является почти универсальной. Если принять точку зрения, что внутри почти всех приложений, использующих общие аппаратные средства, акцент делается на унификацию физических действий, у нас появляется возможность разработать всеобъемлющий и в то же время простой интерфейс.
Набор действий, которыми пользователь влияет на содержание – будь оно текстовым, графическим или мультимедийным, – можно организовать в простую таксономию, с помощью которой мы сможем описать любой интерфейс в некой унифицированной форме. Такая организация позволила бы упростить разработку интерфейсов. Например, внедрение универсального средства «отменить/повторить» (undo/redo) тоже позволяет создавать единообразные интерфейсы, тем самым избавляя от необходимости придумывать средство обработки ошибок специально для каждой программы.
Разные приложения имеют разные наборы команд, и пользователь обычно не может в целом использовать команды приложения А при работе с приложением В или наоборот. Если же сделать команды независимыми от приложений, то тем самым мы сможем устранить модальность, которая изначально им присуща. При такой унификации общее количество команд, которое пользователю придется запоминать, существенно сократится, – главным образом потому, что унификация позволит избавиться от огромного числа повторений команд. Например, в компьютере Canon Cat с помощью всего 20 команд можно было управлять текстовым процессором, электронными таблицами, созданием, сортировкой и обработкой баз данных, вычислениями и т. д. В современных системах аналогичной мощности используется более 100 команд для выполнения того же самого набора задач. Тысячи команд, которые используются в современных средах, можно было бы сократить до сотни. Так как не все команды могут применяться ко всем типам данных, возникнет необходимость применять к объектам преобразователи типов данных, чтобы создать новые объекты, к которым при определенных условиях уже можно будет применить выбранную команду.
Кроме того, может быть снято и другое разделение, которое имеется сегодня между теми средствами, которые содержатся в коммерческих программных продуктах, и теми, которые могут быть созданы самим пользователем. Например, сегодня меню являются объектами операционной системы, которые устанавливаются в каждом приложении. Однако меню представляют собой всего лишь какой-то текст. Почему бы тогда не дать возможность пользователю самому составлять список часто используемых команд, защитить его от случайного изменения, прикрепить наверху экрана и использовать его как обычное системное меню? Для упрощения создания таких меню в интерфейсе можно было бы предусмотреть возможность блокировать и разблокировать какой-то текст, а также возможность его перемещения вместе с другим содержанием или закрепления в каком-то месте на экране. Текст может быть в разных состояниях.
Хотя Eudora и Microsoft Word являются программами, в которых можно изменять меню, тем не менее, для изменения его содержания вы должны использовать только специально предназначенные для этого средства. В данном случае мы как раз и говорим о том, что должна быть возможность создавать меню обычными средствами создания и редактирования текстов. В этом смысле меню можно рассматривать как содержание.
Еще одним шагом к упрощению интерфейса является устранение трудно запоминаемых и неудобных файловых имен, а также системных файловых структур. При наличии хороших механизмов поиска использование имен файлов и файловых структур перестает быть необходимым.
- 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