Проектирование1- слово емкое
В этой книге говорится о том, что интерактивные продукты должны проектироваться проектировщиками взаимодействия (interaction designers), а не разработчиками программного обеспечения (software engineers). Это утверждение часто вызывает мгновенную неприязнь у программистов, которые всю жизнь занимались проектированием. Более того, эти программисты боятся, что, отнимая у них проектирование, я отнимаю лучший и наиболее творческий аспект их работы, приговаривая их к унылому написанию кода, не способному приносить удовольствие. Это совершенно не так. Их беспокойство происходит из неточной природы термина «проектирование».
Весь процесс создания программного обеспечения пронизан проектированием, начиная с выбора языка программирования и заканчивая выбором цвета грузовика, доставляющего готовый программный продукт. И ни один аспект этого продолжительного и сложного процесса не включает столько проектирования, как собственно программирование. Программисты принимают решения из области проектирования на каждом шаге своей деятельности. Программист должен решить, как одна процедура будет вызывать другие, как будут передаваться, храниться, изменяться данные и информация о состоянии и как обеспечить целостность операций. Все эти решения (и миллионы подобных) - решения проектирования, и успех каждого зависит от способности программиста использовать собственный опыт и здравый смысл.
В этом море проектирования я провожу простую разделительную линию. По одну сторону остаются решения, напрямую влияющие на конечного пользователя. По другую - все прочие решения проектирования. В этой книге, говоря о «проектировании взаимодействия», я говорю лишь о первой категории. Проектирование, не затрагивающее конечного пользователя, я называю «проектированием программы».
Невозможно провести разделительную линию в технических аспектах, и нельзя выразить ее в терминах, знакомых инженерам. Дело в том, что дифференцирующий фактор - антропогенный, а не технический, а правила инженерных наук к людям не применимы. Скажем, проектировщик взаимодействия обычно безразличен к таким вопросам, как выбор языка программирования. Но иногда выбор языка влияет на время реакции системы, наблюдаемое пользователем, что совершенно определенно можно отнести к аспектам взаимодействия, и здесь проектировщику будет что сказать.
Проектирование взаимодействия практически целиком лежит в области выбора поведения, назначения, информации, а также пользовательского представления этих аспектов. Проектирование взаимодействия для конечного продукта - единственная часть процесса проектирования, которую я хочу забрать у программистов и передать в руки людей, специализирующихся на проектировании взаимодействия.
- Алан Купер Психбольница в руках пациентов
- Содержание
- Часть I. Компьютерная безграмотность 27
- Глава 1. Загадки века информации 27
- Глава 2. Когнитивное сопротивление 44
- Часть II. Масштабные издержки 68
- Глава 3. Пустая трата денег 68
- Глава 4. Танцующий медведь 89
- Об авторе
- Благодарности
- Предисловие научного редактора
- Предисловие
- Введение Книга-обоснование
- Инженер, сведущий в бизнесе, либо бизнесмен, сведущий в технологии
- ЧастьI. Компьютерная безграмотность Глава 1. Загадки века информации Что получится, если скрестить компьютер с самолетом?
- Что получится, если скрестить компьютер с фотокамерой?
- Что получится, если скрестить компьютер с будильником?
- Что получится, если скрестить компьютер с автомобилем?
- Что получится, если скрестить компьютер с банком?
- Компьютер позволяет легко попасть в беду
- Коммерческое программное обеспечение тоже страдает
- Что получится, если скрестить компьютер с военным кораблем?
- Техноярость
- Индустрия в «несознанке»
- Мотивы создания этой книги
- Глава 2. Когнитивное сопротивление
- Поведение, не связанное с физическими силами
- Проектирование1- слово емкое
- Отношения между программистами и проектировщиками
- Большинство программ проектируются случайным образом
- Проектирование «взаимодействия» против проектирования «интерфейса»
- Отличительные черты продуктов, основанных на программном обеспечении
- Танцующий медведь
- Стоимость дополнительных возможностей программного обеспечения
- Апологеты и уцелевшие
- Наша реакция на когнитивное сопротивление
- Демократизация власти потребителя
- Виноват пользователь
- Программный апартеид
- ЧастьIi. Масштабные издержки Глава 3. Пустая трата денег
- Управление, ориентированное на крайние сроки сдачи
- Что такое «готово»?
- Закон Паркинсона
- Продукт, вечно не готовый к выпуску
- Поздний выпуск - не беда
- Торг за набор функций
- Кто главный? Программисты
- Возможности не всегда нужны
- Итерации и миф о непредсказуемости рынка
- Скрытые издержки некачественного программного обеспечения
- Дороже разработки по обходится только разработка плохого по
- Стоимость возможностей
- Издержки прототипирования
- Глава 4. Танцующий медведь
- Если это проблема, то почему ее до сих пор не решили?
- Жертва бытовой электроники
- Чем плохи почтовые клиенты
- Чем плохи программы для планирования
- Чем плохи календари
- Массовая веб-истерия
- Что не так с программным обеспечением?
- Программы забывают
- Программы ленивы
- Программы скупы на информацию
- Программы не гибки
- Программы возлагают вину на пользователей
- Программы не несут ответственности
- Глава 5. Нелояльность клиентов
- Привлекательность
- Одно сравнение
- Время выхода на рынок
- ЧастьIii. Как есть суп вилкой Глава 6. Психбольница в руках пациентов
- Вождение на заднем сиденье
- Подготовка катастрофы
- Компьютеры против людей
- Учим собак быть кошками
- Глава 7. НоmoLogicus
- Авиационный тест
- Психология программистов
- Программисты пожертвуют простотой ради контроля
- Программисты обменяют успех на понимание
- Программисты сосредотачиваются на исключительных ситуациях
- Программисты ведут себя грубо и прямолинейно
- Глава 8. Отмирающая культура
- Культура программирования
- Повторное использование кода
- Общепринятая культура
- Культура программирования в Мicrоsоft
- Культурная изоляция
- Шкурный интерес
- Дефицитный образ мыслей
- Обесчеловечивает процесс, а не технология