Программистам о разработке пользовательских интерфейсов.
Глава 3: Выбираем

Joel Spolsky

Когда вы видите в ресторане знак «Вход с собаками воспрещен», вы считаете это вполне нормальным – владалец ресторана поставил его, потому что не любит собак. Если бы это было всё, тогда еще должен быть знак «Вход со змеями воспрещен», потому что никто не любит змей, и знак «Вход со слонами воспрещен», потому что слоны сломали бы все столы в зале.

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

Программы тоже имеют свои хронологические записи – они называются окнами настроек. Откройте Tools  | Options и вы увидите историю аргументов разработчиков по поводу дизайна программы. Должна ли программа автоматически открывать последний файл, над которым работал пользователь? Да! Нет! После двухнедельных дебатов, чтобы никого не обидеть, прнимается решение сделать это настройкой.

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

Первая проблема этого окна в том, что он отрывает вас от ваших мыслей. Вы обращаетесь за помощью к файлу справки, и вам нет никакого дела, по крайней мере в этот момент, до того, будет ли база данных маленькой, большой, или покрытой шоколадом. Тем временем эта наглая программа читает вам лекцию о том что она должно создать список (или  базу данных). Там же встречается совершенно неуклюжая фраза «your help file(s)». То есть у вас может быть один или несколько файлов. Какк будто для вас это имеет какое-то значение. Но программист, работавший над этим окном очевидно понимал что файлов может быть много, поэтому просто сказать «help file» было бы неправдой.

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

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

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

Но они не заботятся о том, где находится тулбар программы – сверху или снизу, они не заботятся, индексирован ли файл справки или нет. Они не заботятся о многом другом, и в этом и состоит ответственность дизайнера сделать этот выбор за них.

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

Когда в 1990 г. был выпущен Microsoft Excel 3.0, это была первая программа с новым интерфейсным решением – панелью инструментов (toolbar). Это было интересное решение, которое нравилось людям, и каждый стал его копировать – до такой степени, что сейчас уже непривычно видеть программу без панели инструментов. Успех панели инструментов вдохновил разработчиков Excel на исследование с использованием специальной версии программы, котороую они распространили среди узкого круга людей. Эта версия отслеживала наиболее часто используемые команды и передавала эту информацию в Microsoft. Поэтому в следующюю версию Excel был добавлен еще один ряд кнопок на панели инструментов, на этот раз содержащий большинство часто используемых команд. Великолепно.

Но проблема заключается в том, что создатели панели инструментов не знали, когда следует остановиться. Они хотели позволить пользователям настраивать панель инструментов. Они хотели дать пользователям возможность перемещать панель инструментов по экрану. Затем они подумали о том, что меню – это не что иное как панель инструментов, с надписями вместо иконок, поэтому они дали пользователям возможность перемещать меню по экрану. Проблема: кому это надо? Я ни разу не встречал человека, который бы хотел расположить меню в каком либо другом месте, кроме как сверху. Но вот каковы последствия: если вы случайно чуть-чуть промахнетесь мимо пункта меню Файл и двинете мышкой, вы вытащите панель с меню туда, где бы вы меньше всего хотели её видеть – блокируя документ, над которым работаете.

Сколько раз вы видели это?  И если это произошло по ошибке, не так то просто догадаться что вы сделали не так, и как это исправить. В итоге существует возможность (двигать меню), которая никому не нужна (хорошо, пускай она нужна 0.1% всех людей), но которая мешает практически каждому.

Однажды мне позвонила моя знакомая и попросила помочь ей с проблемой отправки e-mail. Она сказала «Половина моего экрана - серая».

Половина экрана серая?

Целых пять минут я пытался выяснить по телефону что же произошло: она случайно перетащила панель задач Windows к правому краю экрана, а затем случайно расширила её.

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

Вы скажете «Подождите! Важно иметь возможность выбора для опытных пользователей, которые хотят настраивать своё рабочее окружение». На самом деле, это не так важно, как вы думаете. Это напоминает мне о том, как я пытался использовать клавиатуру Дворака. Проблема была в том, что я не пользуюсь одним компьютером. Я использую разные виды компьютеров и я работаю на чужих компьютерах.

Большинство опытных пользователей используют регулярно несколько компьютеров, они делают upgrade своему компьютеры каждую пару лет, и переустанавливают новую ОС каждые три недели.  Действительно, когда они в первый раз поняли, что можно полностью перенастроить клавиатурные комбинации в Word’е, они изменили все что могли, чтобы подстроить систему под себя, но как только они перешли на Windows 95, все эти настройки потерялись, и им было некогда перенастраивать все заново. Я спрашивал большинство моих друзей, опытных пользователей, об этом; если кто и настраивал систему под себя, то только минимально.

Каждый раз, предоставляя пользователю выбор, вы просите его принять решение. Это не обязательно плохо, но все же вы должны всегда пытаться минимизировать количество решений, которые должен принять пользователь.

Это не значит, что надо избавиться от всех случаев выбора. Для пользователя есть достаточно решений, которые он должен принять в любом случае: как будет выглядеть документ, как будет работать веб-сайт, и т.д. В этих случаях, сходите с ума: это здорово давать людям выбор, любыми способами, чем больше, тем веселее. И есть еще одна категория, когда людям нравится выбирать – возможность изменить внешний облик программы, не меняя ее поведения. Все нравятся «скины» в WinAmp, каждый устанавливает себе картинку на рабочий стол. Так как этот выбор оказывает влияние только на внешний вид программы, не меняя ее функциональность, это хорошой способ дать людям выбор.  

Вернуться к списку статей