Интерфейс для идиотов. Homo Logicus против Homo Sapiens

В самолете Homo Logicus отправляется в кабину пилота, поскольку ему важно знать, как это работает, чтобы быть уверенным, что это работает. Homo Sapiens в салоне эти мелкие подробности нисколько не интересуют - ему гораздо важнее вовремя долететь до места.

Вторая часть материала про тонкости проектирования программных интерфейсов. Вернуться к первой статье.

Чтобы определить, к какому виду - Homo Logicus или Homo Sapiens - вы относитесь, Купер предлагает пройти небольшой тест.

Представьте, что вы находитесь в самолете и можете выбрать, куда отправиться: в нашпигованную ручками, рычагами и приборами кабину пилота, где, потратив некоторое время на обучение, вы сможете контролировать полет, или в комфортабельный салон, где вы сможете расслабиться вплоть до момента приземления. Homo Logicus - по Куперу - отправляются в кабину пилота, поскольку им важно отслеживать ситуацию, им важно знать, как это работает, чтобы быть уверенными, что это работает. Homo Sapiens, отправившегося в салон, эти мелкие подробности нисколько не интересуют - ему гораздо важнее вовремя долететь до места, а потом отправиться по своим делам. Ради собственного спокойствия он готов пожертвовать контролем над ситуацией. Хотя, скорее всего, ему даже в голову не придет, что он, отправившись в салон, что-то потерял.

Почти все программисты принадлежат к виду Homo Logicus. Подавляющее большинство пользователей - за исключением, пожалуй, узкой прослойки так называемых продвинутых пользователей - это Homo Sapiens. Классификация, конечно, шуточная, но и мотивация, и поведенческие реакции у этих групп совершенно различны. И если для Homo Logicus в первую очередь важна функциональность продукта, то для Homo Sapiens важнее удобство использования и соответствие конкретным нуждам.

Обычному человеку лень разбираться в сложном интерфейсе, даже если знание интерфейса дает некоторое преимущество. Никто не будет спорить с тем, что функция расширенного поиска на веб-сайте позволяет задать дополнительные параметры и в конечном счете повысить эффективность поиска, однако, как правило, пользователи предпочитают пролистать несколько страниц с результатами, надеясь, что искомая страница вот-вот появится перед глазами. Это если не считать тех, кто пребывает в блаженном неведении относительно дополнительных параметров вообще.

Для Homo Logicus наличие дополнительных возможностей очень важно, но для большинства пользователей огромные списки реализованных функций абсолютно бесполезны. Программа может быть сколь угодно сложно устроена, однако недостаточное внимание к простейшим пользовательским нуждам может привести ее производителя к фиаско. Примеров тому не счесть. Один из самых ярких - провал электронных таблиц Lotus Improv.

История Lotus Improv, которая была лучше всех

Благими намерениями вымощена дорога к банкротству. Когда в 1986 году в компании Lotus была образована специальная исследовательская группа, в чью задачу входило создание новой парадигмы электронных таблиц, вряд ли кто-то мог предположить, что выпущенный продукт станет одним из последних самостоятельных проектов Lotus.

Напомню, что на рубеже 80-х и 90-х годов прошлого века компания Lotus была главным разработчиком электронных таблиц, а ее программа Lotus 1-2-3 - образцом, который нещадно копировали конкуренты. Впрочем, первопроходцами лотусовцы не были - Lotus 1-2-3 эксплуатировал идею электронных таблиц, найденную авторами более раннего продукта, VisiCalc.

Считается, что от добра добра не ищут, но в Lotus предположили, что двухмерные таблицы (когда пользователь может оперировать только вертикальными столбцами и горизонтальными строками) не оптимальны и современным финансистам гораздо нужнее трехмерная модель данных. Кроме того, было очевидно, что ссылочная система адресации, стандартная для электронных таблиц, слишком сложна и неудобна. С какой это, простите, стати пользователь должен складывать ячейку B1 с ячейкой B2, чтобы получить сумму в ячейке B3? Зачем все усложнять? Давайте сделаем проще (см. таблицу).

В любой электронной таблице сумма стоимости билетов в кино и расходы на попкорн описывались бы следующим образом (c поправкой на различия в нотации): B1+B2. Однако в Lotus Improv от ссылочности отказались, поэтому формула получалась куда нагляднее: Tickets+Popcorn.

Для своего времени Lotus Improv был очень продвинутым продуктом с дружелюбным пользовательским интерфейсом. И тем не менее он потерпел поражение, проиграв более примитивным конкурентам. Почему?

Процитируем Джоэла Сполски (Joel Spolsky), автора цикла статей "Дизайн пользовательских интерфейсов для программистов"[Joel Spolsky, User Interface Design for Programmers. Chapter 9: The Process of Designing a Product]: Во время разработки с первой по четвертую версию Excel большинство сотрудников Microsoft пребывало в уверенности, что юзеры используют эту программу для отработки сценариев "а что если…" - вы легко можете менять значения в ячейках, а потом смотреть, что у вас получилось.

Однако корпя над Microsoft Excel 5.0, разработчики решили поинтересоваться, какие функции имеют для пользователей наибольший приоритет, и выяснили, что невероятное количество людей применяло Excel исключительно для ведения списков: Они не писали формул, они вообще ничего не считали! И пользователи намного чаще составляют в Excel списки, чем делают что-либо еще. Это вынудило нас создавать целый ряд новых возможностей, которые бы облегчали составление списков: упрощенная сортировка, автоматический ввод данных, автофильтр плюс многопользовательские возможности, позволявшие редактировать списки сразу нескольким людям.

Вышедший в это время Lotus Improv - превосходно подходивший для финансовых расчетов - со списками работал из рук вон плохо. И пользователю было наплевать на то, что все остальное он делал лучше всех. Improv, вероятно, был идеальным продуктом для Homo Logicus, однако для Homo Sapiens он оказался неудобен[Lotus Improv не канул в Лету. Идеи, заложенные в него, были позднее реализованы в пакете Quantrix].

>>  Несмотря на наличие стандартов и методик изучения пользовательской активности, главное оружие хорошего проектировщика интерфейсов - здравый смысл. Если буквально применять принципы юзабилити, то вскоре выяснится, что пианино спроектировано из рук вон плохо. У него слишком много клавиш - неопытный пианист легко может запутаться. Клавиши слишком большие, и пользователю нужен широкий размах пальцев широко раздвигать пальцы. При желании список можно продолжать: в общем, пианино - очень неудобный музыкальный инструмент.

Мануальная терапия

Разумеется, наивно сводить провал Lotus Improv к недостаточной функциональности. И среди множества причин неудачи проекта есть еще одна, которую следует упомянуть. Это инерция пользователей.

Проектировщики интерфейсов часто используют термин "метафора". Что такое метафора в контексте проектирования интерфейсов, легко понять, представив себе страницу MS Word или рабочий стол Windows. Получилось? Отлично. Однако страница Word вовсе не является страницей в привычном смысле этого слова, хотя она гораздо больше похожа на страницу, чем рабочий стол Windows на обыкновенный рабочий стол. В обоих случаях создатели интерфейса воспользовались терминами, обозначающими объекты реального мира, чтобы облегчить нам взаимодействие с абстрактными концепциями интерфейса программной среды Windows. Метафора - это точка опоры для пользователя. Понимая, как действует знакомый ему объект, пользователь может предположить, как функционирует цифровой "аналог" этого объекта.

На более низком уровне метафоры часто используются для графического изображения функциональности элементов интерфейса. Как правило, иконка на кнопке является символическим изображением функции, которую выполнит программа при нажатии на кнопку. И любой пользователь Windows прекрасно знает, что звено цепи означает гиперссылку, дискетка - сохранение, открытая папка - диалог открытия файла, а лупа - увеличение масштаба.

Хотя нет, постойте. В панели Word лупу можно обнаружить на иконках "Найти", "Предварительный просмотр" и "Схема документа", тогда как функция зуммирования вынесена в отдельный элемент управления с выпадающим списком. В общем, метафоры не всегда выбраны наилучшим образом.

Но часто критике подвергаются не такие мелочи, как изображения на иконках, а более концептуальные понятия. Например, не всем специалистам по юзабилити нравится "Рабочий стол". Упомянутому Алану Куперу "метафорический" подход к построению интерфейсов вообще претит. По его мнению, привязка к метафоре хоть и облегчает привыкание и обучение пользователей, значительно ограничивает проектировщиков интерфейсов и вынуждает их выбирать неоптимальные решения.

Один из главных недостатков "Рабочего стола" в том, что на стол он и отдаленно не похож. Например, у вас на столе когда-нибудь были ярлыки? Конечно, нет. Реальный мир вообще обходится без ссылок, в нем мы оперируем объектами. Так почему же вы должны мириться с ярлыками на виртуальном рабочем столе? Зачем они нужны? Если вам нужен какой-то файл на рабочем столе - просто скопируйте его. Если вам нужна папка - перенесите ее сюда и перестаньте множить сущности почем зря. Так считают апологеты жизненной философии Homo Sapiens.

Другая точка зрения прямо противоположна предыдущей. "Рабочий стол" - и вообще иерархические системы хранения файлов - недостаточно гибки для пользовательских нужд. Почему в Windows нельзя создавать виртуальные папки? Почему файл не может находиться в нескольких папках одновременно? Почему мы не можем менять представление информации так, как нам удобнее в настоящий момент? Так - или очень похоже - могли бы ответить на критику представители Homo Logicus.

Очевидно, что Lotus Improv был спроектирован для Homo Logicus, хотя его потенциальные пользователи - работники финансовых органов - никогда не были замечены в горячей любви к компьютерам. Для работы с Lotus Improv необходимо было переучиваться. Чтобы получить от новой программы максимум отдачи, нужно было как минимум прочитать руководство пользователя. И все ради программы, в которой даже списки составлять неудобно? Увольте!

Возможно, интерфейс Windows - самый худший графический интерфейс в мире. Но это не отменяет того факта, что к нему привыкли десятки миллионов людей и что любому программисту нужно считаться с их привычками, если он хочет, чтобы его программой пользовался кто-то, кроме него самого.

Мы не знаем, изучали ли в Microsoft, насколько активно пользователи читают печатные руководства к программным продуктам, но любой специалист по юзабилити скажет вам, что мануал - это последнее убежище пользователя. Больше того - многие пользователи не читают даже сообщения, которые выводятся в диалоговых окнах

Возможно, здесь уместно упомянуть об исследовании поведения веб-пользователей. Общеизвестно, что серферы по мере накопления опыта перестают замечать рекламные баннеры. Но как выяснилось в результате исследования пользовательской активности, почти так же они игнорируют и элементы меню веб-сайтов. И если вы хотите, чтобы визитер кликнул на ссылке, ее нужно помещать внутрь текста, не рассчитывая на то, что юзер найдет нужный пункт в навигационном меню (подробнее).

Читайте на следующей странице: ещё одна категория Homo Sapiens, которая здорово портит жизнь проектировщикам интерфейсов.

- Из журнала "Компьютерра"