Человеческий фактор в программировании
Добавить в закладки К обложке
- Предисловие - Страница 1
- Предисловие к первому изданию - Страница 3
- IГрупповая разработка - Страница 5
- 2Консенсус и компромисс - Страница 7
- 4Скромный и высокопоставленный писарь - Страница 11
- 5Официальное пространство - Страница 14
- 6Раздражающие прерывания - Страница 17
- IIКовбои и ковгерлы - Страница 19
- 8Возвращение блудного ковбоя - Страница 22
- 9Единство в разнообразии - Страница 25
- 10Кодеры-ковбои и программисты-мудрецы - Страница 28
- IIIОрганизация работы - Страница 33
- 12Методы хаоса - Страница 36
- 13Открытая архитектура - Страница 39
- 14Синхронное плавание - Страница 42
- 15Командная политика - Страница 45
- 16Все сразу - Страница 47
- 17Заговор упрямцев - Страница 49
- IVИнструменты, модели и методы - Страница 51
- 19Вопросы моделирования - Страница 54
- 20Свет мой, зеркальце - Страница 56
- 21Методичное сумасшествие - Страница 58
- 22Говоря по существу - Страница 60
- 23Будущие формы - Страница 63
- 24Цели программного обеспечения - Страница 66
- 25Шито белыми нитками - Страница 69
- VСовершенствование процесса - Страница 73
- 27Повторение и вознаграждение - Страница 76
- 28Суперобучение - Страница 79
- 29Вверх по водопаду - Страница 81
- 30Своевременная поставка - Страница 83
- 31Под давлением - Страница 85
- 32Re: Архитектура - Страница 87
- 33Пошаговое улучшение качества - Страница 89
- VIЮзабилити программного обеспечения - Страница 95
- 35Сложность и прогрессирующий функционизм - Страница 98
- 36Назад к истокам - Страница 101
- 37Цветной язык - Страница 104
- 38Совершенствующиеся середнячки - Страница 107
- 39Пригодны ли вы - Страница 110
- 40Редактирование интерфейсов - Страница 113
- 41Сервис - Страница 115
- VIIУдобные объекты - Страница 117
- 43Глубокое понимание - Страница 121
- 44Абстрактные объекты - Страница 125
- 45Новая среда - Страница 128
- 46Полезные ситуации - Страница 132
- 47Эффективные объекты - Страница 136
- 48Связанные объекты - Страница 140
- VIIIЭто превосходное новое программное обеспечение - Страница 143
- 50Интерфейсы разнообразные - Страница 146
- 51Мастеры - Страница 148
- 52Образы будущего - Страница 150
- IXКультура и качество - Страница 152
- 54Агенты изменения - Страница 154
- 55Встроено самое лучшее - Страница 156
- 56Заметки из итальянского ресторана - Страница 159
- 57Наставничество - Страница 162
- 58На обучение - Страница 164
- 59Одаренные программисты - Страница 166
- 60Иконы отрасли - Страница 168
- 61Импресарио - Страница 170
- Приложение - Страница 172
- Библиография - Страница 174
Пользовательские ситуации не только дают внешнее представление, но и отступают от буквального языка сценариев, обращаясь к более абстрактному языку переменных и классов. Например, в сценарии может быть написано: «Программист Паула щелкает по пиктограмме на рабочем столе, чтобы запустить мастер технической поддержки. Ей предлагаются два варианта соединения: сетевое или модемное. Она выбирает модемное. Затем предлагается ввести номер пользователя — она набирает 4477-610. Далее, в предложенном списке проблем она щелкает по пункту «Проблемы с печатью» и т. д». В пользовательской ситуации, наоборот, дается более общее описание: «Пользователь щелкает по пиктограмме запуска программы технической поддержки, производит соединение с системой, вводит номер пользователя, выбирает пункт из предложенного списка проблем». Таким образом, мы делаем шаг назад, который приближает нас к пониманию реальной задачи, стоящей перед пользователем.
К сожалению, большинство пользовательских ситуаций все же содержат много скрытых, невыраженных допущений, связанных с пользовательским интерфейсом системы. В данном примере система технической поддержки обозначена пиктограммой, а у пользователя есть свой номер. Этот номер необходимо ввести для получения доступа к системе, после чего нужный раздел выбирается из списка. Такие допущения могут показаться не слишком существенными, но мы знаем по опыту, что именно невысказанные, а значит, и не подвергнутые сомнению допущения могут в конечном итоге нанести наибольший вред. Они привязывают нас к конкретным дизайнерским решениям, принятым без подробного описания задачи и без учета альтернативных вариантов.
Условный, конкретный вариант пользовательских ситуаций представляет собой блюдо, состоящее из неявных решений в сочетании с описанием текущей задачи. Зачастую эти ингредиенты трудно различить или отделить друг от друга. Действительно ли применение пользовательского номера является частью проблемы, или это одно из возможных решений неуточ-ненной задачи по идентификации пользователя? Для создания хорошего пользовательского интерфейса нужна более абстрактная и очищенная модель, напоминающая пользовательские ситуации, но не засоренная допущениями относительно дизайна интерфейса, который еще не разработан.
Хорошие целиПо этим причинам Люси Локвуд (Lucy Lockwood) и я разработали метод сущностных пользовательских ситуаций как упрощенную, обобщенную и более абстрактную модель в сравнении с ее конкретными аналогами (см. главу 22). Абстракция (как об этом говорилось в главе 44) способствует новаторскому мышлению и созданию более надежного дизайна. Целью моделирования сущностных пользовательских ситуаций является описание пользовательских задач как таковых — без каких-либо технологических допущений и ограничений. Сущностная пользовательская ситуация представляет собой абстрактную сущность целей пользователя. Она выражается в терминах намерений, а не в терминах действий пользователя. Например, пользователи системы технической поддержки намереваются получить помощь — сообщить, кто они, и объяснить, с какой проблемой или проблемами они столкнулись.
Сущностные пользовательские ситуации не только отделяют пользовательскую проблему от дизайнерских решений, но и различают пользовательские намерения и системные ответы, обеспечивающие реализацию этих намерений. Вместо одного свободного описания взаимодействия — того описательного подхода, который применяется в сценариях и большинстве пользовательских ситуаций, — сущностные пользовательские ситуации принимают форму структурного описания, в котором диалог разбивается на две колонки: то, что пользователь хочет сделать, и то, что система должна представить в качестве ответа. Названия этих колонок: модель пользовательских намерений и модель системных ответов. Такая модель имитирует формат, предложенный Ребеккой Уирфс-Брок (Rebecca Wirfs-Brock) для конкретных пользовательских ситуаций. В задаче, связанной с разработкой системы технической поддержки, сущностную пользовательскую ситуацию можно назвать получение технической помоши. Она может принять следующую форму:
В сущностном варианте пользовательской ситуации опускаются посторонние детали взаимодействия и не затрагивается визуальная или физи-ческая форма интерфейса. Высокая степень абстракции и сосредоточенность на цели позволяют разработчику рассмотреть разные пути достижения одних и тех же результатов. Например, приведенная сущностная пользовательская ситуация может описывать как применение системы сетевой технической поддержки, так и программу обработки голоса при телефонном общении. Так как сущностные пользовательские ситуации обычно короче и проще конкретных, они часто помогают создать более компактные системы с более простыми и удобными интерфейсами. Поскольку пользовательские ситуации являются целевыми моделями задач, они помогают сосредоточиться на целях и реальных потребностях пользователей.
- 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
- 151
- 152
- 153
- 154
- 155
- 156
- 157
- 158
- 159
- 160
- 161
- 162
- 163
- 164
- 165
- 166
- 167
- 168
- 169
- 170
- 171
- 172
- 173
- 174
- 175
- 176
В конце февраля 2009 года в продаже на Amazon появил
Электронная читалка - вещь очень хрупкая. Если с ней обращаться не правильно - она может сломаться. Чтобы этого не случилось, нужно придерживаться лиш
Большинство книг в сети интернет распространяется в формате FB2 (Fiction Book). Этот формат очень удобен для чтения. Файлы, в нем созданные, отличаютс
Популярность электронных книг у читателей неуклонно растет. Для доказательства этого мы провели маленький эксперимент. Из 10 людей, читающих в метро,
Файлы формата FB2 часто можно увидеть среди огромнейшего разнообразия текстовых форматов. Такая высокая популярность объясняется его предназначением.
Первую версию формата PDF (Portable Document Format) еще в 1993 году разработала фирма Adobe Systems. В 2006 году она уже разработала версию 1.7, а с
Фирма Apple порадовала пользователей iPad, выпустив под него красивую и удобную читалку iBooks.