Динамические визуальные сигналы – это изменение изображения на экране с целью дать пользователю дополнительную информацию. Уже в стандартном оконном интерфейсе мы можем видеть примеры таких сигналов. При выполнении программой длительных действий курсор мыши приобретает форму песочных часов. Это – сигнал о том, что на действия пользователя система временно реагировать не будет. Второй пример – изменение изображения кнопки при нажатии на нее мышью. Это – сигнал о том, что система считает, что пользователь взаимодействует именно с этой кнопкой.
Беда в том, что в оконном интерфейсе динамические визуальные сигналы носят характер гениальных находок и не образуют полную логичную систему. В качестве аналогии отмечу разницу между алфавитом и иероглифами. Выучив алфавит, можно читать любой текст. Выучив иероглифы, нельзя гарантировать, что не появится новый.
Создавая анимационный интерфейс, надо закладывать систему динамических визуальных сигналов с самого начала, поскольку они являются столь же естественной, сколь и необходимой частью анимационного интерфейса.
Кроме того, информационная емкость (т. е. количество разных различимых вариаций) динамических сигналов огромна. Современные дисплеи отображают миллионы цветов, но это – вещь в себе, поскольку, даже если человеческий глаз и в состоянии отличить столько оттенков, человеческий мозг не в состоянии придавать им смысл. С другой стороны, и такой простой сигнал, как мигание, имеет действительно миллионы хорошо осознаваемых оттенков, связанных с изменением яркости объекта во времени. Здесь уместна аналогия с музыкой, где из небольшого количества нот составляется неисчислимое множество мелодий.
Однако, решая многие проблемы для пользователя, анимационный интерфейс, как это часто бывает, ставит тяжелые проблемы перед программистом и дизайнером.
Многие программисты еще помнят о трудностях перехода к созданию программ, управляемых событиями, как того требует оконная среда. Для использования анимационного интерфейса придется переходить к программам, управляемым временем. Вне зависимости от активности пользователя программе, построенной на анимационном интерфейсе, всегда есть что делать (например, менять фазу мигания). При этом, естественно, она должна постоянно быть доступной для взаимодействия, но, в отличие от многих сегодняшних мультимедиа-программ, не прерывать отображаемый поток, а плавно изменять его в соответствии с воздействием пользователя.
Такие требования легче всего реализуются в специфической архитектуре программ, управляемых временем. На каждом такте работы такой программы заново строится изображение на экране, а события, инициированные пользователем, например ввод с клавиатуры, отрабатываются всего лишь изменением состояния программы.
Соответствующее изменение на экране происходит (быть может, не сразу) на очередном временном такте. Таким образом, к двум привычным уровням программы – функциональному и интерфейсному – добавляется визуальный.
Для дизайнеров интерфейсов конкретных продуктов работа тоже существенно усложнится. Анимационный интерфейс – орудие очень мощное и поэтому требует особой осторожности. Попытки потрясти мир могут привести к быстрой утомляемости пользователя и, как следствие, отторжению системы. Основной задачей дизайнера становится организация не неподвижного пространства, а целой серии пространств, неразрывно связанных между собой. Аналогия с созданием фильмов представляется здесь очень уместной.
Для дизайна конкретной программы требуется разработка собственной среды взаимодействи (направленной на реализацию конкретной функциональности) на базе общепринятой системы динамических визуальных сигналов. Предпочтительно иметь сквозное визуальное решение. Практически единственный положительный пример можно взять из телевидения, а именно серию заставок Левина к программам НТВ. Все компьютерные программы в корне меняют дизайн при переходе от одного окна к другому.
После выработки сквозного визуального решения необходимо прорисовать картинки, называемые у аниматоров "фонами". Точнее называть их неподвижной составляющей подвижного изображения. На каждом фоне надо расположить анимированные элементы взаимодействия. И, наконец, самое трудное – надо спроектировать визуальные переходы между существенно отличающимися состояниями. И все это, сохраняя выбранный стиль! Кому это нужно? Пользователю, который ничего этого не заметит, но зато будет гораздо проще и быстрее взаимодействовать с системой. Хороший интерфейс похож на удобную обувь – никто его не замечает, а, если обратить на него внимание, в ответ получишь равнодушное "Ну и что такого?". Зато плохой интерфейс у всех на виду и на устах.
На самом деле, хороший интерфейс пользователями замечается подсознательно, и, когда он нравится, симпатии переносятся на функциональную часть программы. (Про "ДИСКо Командир" многие говорят, что он хорош, но НИКТО не говорит, чем именно.) К сожалению, следует констатировать, что сегодня стандартом стал плохой интерфейс, даже не столько плохо сделанный, сколько вообще "получившийся сам собой". Так, самое модное сейчас применение компьютеров – блуждание по Сети – имеет тот интерфейс, который вытекает из языка HTML, а он, в свою очередь, производит впечатление "времянки", которая, как теперь ясно, пришла всерьез и надолго.
Моя любимая цитата из обзора интерфейсов – "Интерфейс этой программы неестественен, потому что клавиша Alt+F4 не закрывает приложения". Здесь уже требуется талант Дарвина, чтобы понять происхождение такого вида естественности! Многие интерфейсные проблемы являются естественным продолжением маркетинговых достижений. Предположим, что ваша фирма выходит на рынок с новой моделью аудиомагнитофона, отличающейся от всех остальных некой возможностью А. Для успешной продажи этой модели та кнопка на панели управления, которая реализует А, должна быть как можно заметнее. Тогда потенциальный покупатель сам спросит "А что это?" – и продать ваше изделие будет гораздо легче. Однако, купив его и включив дома, этот покупатель будет, скорее всего, пользоваться стандартными кнопками для стандартных действий, показывая возможность А только гостям.
Таким образом, налицо противоречие, следующее из двух разных функций одного и того же товара. Первая функция – продавать самого себя за счет привлекательности и/или необычности внешнего вида, а вторая – использоваться по назначению. С точки зрения продавца (а часто, и производителя), первая функция гораздо важнее. Поэтому навязывается "стандарт", направленный именно на успешность первой функции. Замените аудиомагнитофон интерфейсными средами, и станет понятным, что я имею в виду.
(Желающих увидеть эту проблему крупным планом приглашаю на рынок пиратских CD-ROM, где покупатель принимает решение о покупке в общем-то недешевого товара, глядя только на обертку и даже будучи уверенным, что содержание в какой-то мере ей не соответствует.) Ряд интерфейсных проблем связан с конкурентной борьбой на рынке программ. Пожалуй, главная из них – какие формы должно принимать авторское право на интерфейсные решения. С одной стороны, ясно, что придумать и реализовать хороший интерфейс – очень сложная задача, и авторы такого интерфейса должны получить не только моральное вознаграждение. С другой стороны, если "защитить" такое решение патентом с последующими лицензионными выплатами, это может спровоцировать авторов новых продуктов искать свои, нехоженые и, зачастую, худшие пути в интерфейсе. В качестве яркого примера можно попробовать представить себе последствия патентования использования клавиши "F1" для вызова справки.
Лицензионная защита интерфейсных решений – прямой путь к тому, что одни и те же интерфейсные функции будут реализовываться в разных продуктах по-разному, а это далеко не в интересах пользователя. При всей моей нелюбви к фактической монополии фирмы Microsoft на рынке операционных сред должен отметить, что положительной чертой этой монополии явилась "бесплатная" стандартизация интерфейса под Windows.
С проблемой защиты авторского права в области пользовательского интерфейса связаны два громких судебных процесса – Apple Computer против той же Microsoft, где предметом был сам оконный интерфейс, и Lotus против Borland, где с правовой точки зрения оспаривалось включение в Quattro Pro (наравне с несколькими другими) интерфейса Lotus 1-2-3.
Нельзя сказать, что решения по этим делам могут использоваться как прецеденты, так как интересы пользователей в них почти не учитывались, а результат, как это часто бывает, соответствовал финансовым затратам сторон.
К сожалению, сегодняшнее состояние рынка программного обеспечения таково, что дорогу себе прокладывают не лучшие решения, а решения, имеющие "большую пробивную силу", в основном связанную с финансовой мощью предлагающих их компаний. Это особенно верно для пользовательского интерфейса. Если взглянуть на программы просмотра WWW, то вообще трудно говорить о дизайне интерфейса – получилось как получилось. Терпимо, но не более. А ведь этими программами пользуется большее число людей, чем какими-либо другими. Теперь такой интерфейс становится фактическим стандартом, а это значит, что последующий переход к более естественному интерфейсу (который, безусловно, рано или поздно произойдет) будет связан с тяжелой психологической ломкой.
Будем надеяться, что такую ломку пользователям придется испытать только один раз, а не несколько, как это вполне может случиться при замене одного плохого интерфейса другим.
Список литературы
Донской М. Пользовательский интерфейс