Интерфейс для идиотов. Да/Нет/Отмена
Есть одна категория Homo Sapiens, которая здорово портит жизнь проектировщикам интерфейсов. Давайте откажемся от обидного слова "идиоты" и примем, что эти люди одарены в каких-то других, неизвестных нам областях.
Автор: Сергей Задорожный | Раздел: | Дата: 08 июля 2005 года
Третья часть статьи "Проектирование интерфейса для идиотов". Начало можно найти здесь.
Котенок на клавишах
Мы начали с разговора об идиотах, а потом перешли к пользователям, у которых нет ни времени, ни желания разбираться в новых компьютерных программах. Если у вас сложилось впечатление, что идиотами я назвал именно таких юзеров, то впечатление это неверное. Ни один человек не может разбираться во всем без исключения, и нет ничего зазорного в том, чтобы не разбираться в компьютерах. Совершенно нормально не испытывать к компьютерам ни малейшего интереса. Пользователи не должны понимать, как работает программа, если она делает то, что нужно. А если программа не делает того, что от нее ждут, виноваты в этом точно не пользователи.
Но есть одна категория Homo Sapiens, которая здорово портит жизнь проектировщикам интерфейсов, разработчикам и другим ни в чем не повинным пользователям. Давайте откажемся от обидного слова "идиоты" и примем, что эти люди одарены в каких-то других, неизвестных нам областях. Возможно, они хорошо отбивают чечетку или вышивают крестом.
Эти пользователи совершают глупые, нелогичные, непредсказуемые действия и, наломав дров, винят во всем программу. Это они способны закрыть программу, предварительно не сохранив файл. Это они, вместо того чтобы открыть файл, сохраняют на его место другой. В общем, они делают все, чтобы испортить жизнь себе и окружающим. И они жалуются в службу поддержки, обвиняя программистов во всех смертных грехах.
Всему есть причина. И вероятнее всего, что глупые и нелогичные диалоговые окна ("Вы хотите закрыть этот файл?
Да/Нет/Отмена", "Вы точно хотите закрыть этот файл? Да/Нет/Отмена", "Вы на сто процентов уверены, что хотите закрыть этот файл? Да/Нет/Отмена") впервые появились именно после звонка разгневанного пользователя, который убил четыре часа, попиксельно рисуя цветочек в MS Paint, а потом потерял все за десять секунд. Как же так, - возмущается пользователь, - вы что, не могли предвидеть, что я закрою программу, не сохранившись?!
К сожалению, его жалоба попала не к проектировщику интерфейсов, а к программисту, который просто вставил в код заглушку. И теперь, если пользователь хочет закрыть программу, не сохранив файл, программа обязательно поинтересуется, уверен ли он в необходимости таких решительных действий. Программы, созданные особыми талантами, спрашивают об этом всегда - даже если сохранять вовсе нечего. Программистам больше нечего бояться - если даже после десятка предупреждений пользователь умудряется закрыть файл, не запомнив исправлений, значит, он просто-напросто дипломированный идиот, и тут уже ничего не сделаешь. А программисты, получается, все в белом.
К сожалению, это простое, но глубоко ошибочное решение стало стандартом де-факто. Из-за сотой доли процента не слишком внимательных людей страдают все остальные пользователи, тогда как более трудоемкая защита от дурака в виде глобального undo (когда любое действие программы, включая сохранение, можно отменить на несколько - в идеале на бесконечное - количество шагов назад) практически нигде не реализована. А все современные программы заполнены массой заглушек и подсказок для людей, которые хорошо вышивают крестом.
>> Ко многим вещам мы привыкли и даже не замечаем их неудобства. Взять, например, обычные пальчиковые батарейки. Кто из нас не путал плюс с минусом, меняя батарейки в плейере или фотоаппарате? А ведь решить эту проблему очень просто - достаточно слегка изменить форму элементов, но изменить ее так, чтобы батарейку физически невозможно было вставить неправильно.
Да/Нет/Отмена
Пример с гипотетическим программистом, запустившим в мир программного обеспечения занудные "переспрашивающие" диалоги, очень показателен, поскольку иллюстрирует одну из главных проблем создания ПО. Разработчики не знают, что они делают. Очень часто во время разработки не существует описания продукта. Вместо этого используется список функций, которые нужно реализовать, и, если повезет, прототип интерфейса. Разница между описанием готового продукта и перечнем необходимых свойств программы такая же, как между рецептом слоеного пирога и списком ингредиентов, которые требуются для его приготовления.
Программист зачастую мыслит локально. Ему необходимо реализовать определенную часть из перечня функций будущей программы, который менеджеры уже обсудили и признали единственно верным. Если программист успевает сделать это к дедлайну, значит, оговоренные функции включаются в финальный релиз. Если не успевает - программа функционально урезается или (если это невозможно) на какой-то срок откладывается. Последнее случается реже.
Но пользователю-то наплевать на список функций. Ему вообще наплевать на программу как таковую. Ему не нужна сама программа. Ему нужно решить свои проблемы. Программа для него - всего лишь инструмент, и пользователь вовсе не жаждет тратить половину жизни на изучение ее возможностей. Он хочет, чтобы все было просто, надежно и удобно.
Нетрудно заметить, что ни одна из этих характеристик не является сколь-нибудь важной для Homo Logicus. Иногда доходит до смешного - Джефф Безос, рассказывая о том, как в Amazon внедряли систему 1-Click, вспомнил о первом разговоре с программистами, которым было поручено реализовать новую модель взаимодействия с покупателями (1-Click отличается от обычной системы покупок в интернет-магазине тем, что в ней купить товар можно с помощью одного щелчка мыши). Программисты внимательно выслушали маркетологов, сказали, что технических проблем возникнуть не должно, и отправились кодировать. Когда через некоторое время они решили показать черновой вариант, выяснилось, что на покупку требуется не один, как требовали маркетологи, а два клика.
Возникли непредвиденные технические трудности? В ряды амазоновских программистов затесался саботажник? Один из программистов - заика? Нет, нет и еще раз нет. Они создали двухкликовую систему потому, что так было проще, и им показалось, что один или два клика - совершенно неважно. В конце концов, два клика тоже не очень много. Ну щелкнет покупатель лишний раз, рука не отвалится.
>> Предполагается, что прогресс эквивалентен повышению эффективности, однако есть и забавные противоположные примеры. Так, недавнее соревнование между 90-летним английским телеграфистом и 13-летней любительницей понабирать SMS закончилось... сокрушительным поражением тинейджера. Азбука Морзе оказалась эффективнее современных технологий текстового набора - по крайней мере, в руках профессионала.
Вместо заключения
Попробуем подытожить. Проектировщику современных интерфейсов приходится иметь дело с
- программистами, у которых есть свое мнение о том, как должна выглядеть программа, и есть сроки, в которые они должны уложиться;
- пользователями, которые, как правило, не могут объяснить, что им нужно, но без проблем определяют, что им не нужно, после того как программа уже закончена;
- творческими ограничениями, потому что миллионы леммингов не хотят и не будут переучиваться.
Даже удивительно, что проектировщикам интерфейсов удается добиться хоть каких-то результатов. Да?
Нет?
Отмена?
Читайте на следующей странице: пара слов в защиту леммингов.
>> Даже если вы всё сделали правильно, нет никакой гарантии, что пользователь верно вас понял. В России принято мыть посуду под проточной водой. В Великобритании домохозяйки затыкают раковину пробкой, наливают воду и только после этого начинают заниматься посудой. Никаких концептуальных отличий между русскими и британскими раковинами, естественно, не существует. Главные отличия - в головах.
- Из журнала "Компьютерра"
