Интерфейс: новые направления в проектировании компьютерных систем
Добавить в закладки К обложке
- ВведениеВажность основ - Страница 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
При таком подходе вместо прикладных программ разработчики будут поставлять наборы команд, представляющие собой совокупность взаимосвязанных операций. Например, вместо программы для обработки фотоизображений разработчик будет предлагать ряд отдельных команд, которые в совокупности будут давать те же возможности, что и программа. Пользователь сможет устанавливать столько команд, сколько ему необходимо, вместо того, чтобы устанавливать целое приложение, из которого ему может понадобиться только некоторая часть. С помощью Интернета передовой разработчик сможет продавать свое программное обеспечение отдельными командами и даже предусмотреть скидки на покупку определенных наборов или определенного числа команд.
Когда пользователи сетуют на невероятную сложность приложений и просят, чтобы программы были проще, «без этих ненужных колокольчиков и свистков», разработчики отвечают, что облегченные («lite») версии программного обеспечения зачастую не имеют успеха на рынке. Неудачи с облегченными версиями программных пакетов могут быть объяснены следующим образом. Поскольку пользователь никогда не знает, какие именно возможности полного пакета могут ему понадобиться, он покупает весь пакет, т. к. это единственный способ получения этих возможностей. Если пользователь приобретет ограниченную версию по меньшей цене, единственный способ, каким он сможет обновить эту версию, – это купить полный пакет, даже если пользователь хочет получить только какую-то одну небольшую функцию из этой программы. Поэтому выходит, что лучше сразу покупать полную версию и примириться с ее сложностью. В результате не удивительно, что мы оказываемся как бы в ловушке. Более гуманным подходом было бы предоставление возможности покупать команды по отдельности.
В различных обзорах сообщается о большом количестве никогда не используемых элементов того или иного программного обеспечения. В последнее десятилетие это число возросло приблизительно с 15 % до почти 50 %. Это создает большой беспорядок. Если же вместо приложений использовать наборы команд, каждая из которых может быть установлена независимо от других, пользователи сведут показатели этой статистики почти до 0. Другими преимуществами такого подхода для разработчиков является возможность поступенчато улучшать свои продукты, а также более простым образом и чаще поставлять (т. е. продавать!) новые элементы приложений, поскольку в этом случае производителям не придется каждый раз выпускать весь пакет заново. Интернет является самым подходящим средством для осуществления таких многократных поштучных продаж.
Разработчики (необязательно те же, кто выпускает наборы прикладных команд) также могут производить трансформаторы. И они тоже могут продаваться поштучно. Если большинство пользователей регулярно использует большинство команд текстовой обработки, выпущенных разработчиком А, и разработчик В придумает какую-то полезную команду, которую разработчик А не поставляет, то разработчик В сможет продавать эту команду покупателям продукта, производимого разработчиком А. Однако разработчик В может использовать другую структуру данных. В этом случае он может предложить также и трансформатор для перевода из одной структуры данных в другую, и наоборот. Если продуктом, производимым разработчиком А, пользуется большое число потребителей, разработчик В может создать версию данной команды, работающую непосредственно со структурой данных, предусмотренной разработчиком А. Кроме того, третий разработчик (С) может специализироваться на разработке трансформаторов. Для пользователей может стать обычной практикой покупать трансформаторы именно у таких разработчиков, а для разработчиков команд – давать лицензии на соответствующие трансформаторы. Эта коммерческая структура частично уже существует сегодня, и различные компании (например, DataViz) специализируются на разработке трансформаторов.
Элементы такой компьютерной среды «команды плюс трансформаторы» также существуют, и их нетрудно будет собрать в единую рабочую систему. Для пользователей такие системы будут проще в использовании и более гибкими в сравнении с сегодняшними разработками, ограниченными применением приложений. Такое решение может уменьшить степень избыточности и сложности, снять проблему совместимости между приложениями и необходимость многократно решать одну и ту же проблему. Со временем операционная система может полностью исчезнуть из поля зрения пользователя. Если этого подхода будут придерживаться должным образом, то даже общепринятая версия операционной системы – рабочий стол – не сохранится в ее сегодняшнем виде.
- 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