Таким образом, налицо противоречие, следующее из двух разных функций одного и того же товара. Первая функция - продавать самого себя за счет привлекательности и/или необычности внешнего вида, а вторая - использоваться по назначению. С точки зрения продавца (а часто, и производителя), первая функция гораздо важнее. Поэтому навязывается "стандарт", направленный именно на успешность первой функции. Замените аудиомагнитофон интерфейсными средами, и станет понятным, что имеется в виду.

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

С проблемой защиты авторского права в области пользовательского интерфейса связаны два громких судебных процесса - Apple Computer против той же Microsoft, где предметом был сам оконный интерфейс, и Lotus против Borland, где c правовой точки зрения оспаривалось включение в Qattro Pro (наравне с несколькими другими) интерфейса Lotus 1-2-3. Нельзя сказать, что решения по этим делам могут использоваться как прецеденты, так как интересы пользователей в них почти не учитывались, а результат, как это часто бывает, соответствовал финансовым затратам сторон.

К сожалению, сегодняшнее состояние рынка программного обеспечения таково, что дорогу себе прокладывают не лучшие решения, а решения, имеющие "большую пробивную силу", в основном связанную с финансовой мощью предлагающих их компаний. Это особенно верно для пользовательского интерфейса. Если взглянуть на программы просмотра WWW, то вообще трудно говорить о дизайне интерфейса - получилось как получилось. Терпимо, но не более. А ведь этими программами пользуется большее число людей, чем какими-либо другими. Теперь такой интерфейс становится фактическим стандартом, а это значит, что последующий переход к более естественному интерфейсу (который, безусловно, рано или поздно произойдет) будет связан с тяжелой психологической ломкой.

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

Заметим обычные ошибки.

1. Лишний выбор.

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

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

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

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

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

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

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