Ларри Константин - Человеческий фактор в программировании

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

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

Чтобы спуститься с абстрактных высот, рассмотрим одну частную, но показательную задачу: разработка взаимодействия со степлером в системе управления документами. Так же как чистые листы бумаги или документы можно скрепить вместе и получить единое целое, так и степлер в ПИ позволяет собирать совокупности документов в группы, которыми пользователь может манипулировать как единым целым.

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

Любое утверждение о том, что способ drag-and-drop — самый естественный и правильный, еще более ослабляется следующим аргументом. При разумной реализации стопка документов не должна оставаться в зубах объекта «степ л ер», так же как распечатанный документ не должен оставаться над пиктограммой принтера. Даже пуристы MacMetaphor признают возможность компьютера выполнять какую-то часть этой манипуляции. Они охотно согласятся на то, чтобы перетаскиваемые объекты чудом перескакивали на свои начальные позиции.

В реальном мире люди не путают метафоры объектов и функций. Они могут поднести бумагу к степлеру или степлер к бумаге и применить его, ничего не перепутав. Хороший пользовательский интерфейс дает такую же гибкость или даже увеличивает ее. Не создавая путаницы, такой интерфейс допускает все основные варианты взаимодействия: (1) перетаскиваем стопку бумаги к степлеру; (2) щелкаем мышью по стопке бумаги, потом щелкаем по степлеру; (3) щелкаем мышью по степлеру, потом щелкаем по стопке бумаги; (4) перетаскиваем степлер к стопке бумаги. Хорошая реализация интерфейса предоставляет пользователю все эти возможности. Степлер должен выглядеть солидно, всем своим видом показывая, что к этой пиктограмме можно перетаскивать другие. А при щелчке мышью пиктограмма степлера должна изменяться так же, как и любая кнопка. При щелчке мышью она должна «утопать». При приближении перетаскиваемой стопки бумаги ее цвет должен изменяться, чтобы показать готовность степлера. Если же вы пытаетесь перетащить к нему принтер, степлер должен ответить отказом. Соответствующая анимация, изображающая работу степлера (со звуком или без), должна сообщать пользователю о завершении операции. Когда вы берете степлер как инструмент, ничего при этом не выделив, указатель превращается в пиктограмму ручного степлера.

Является ли такой подход к ПИ объектно-ориентированным? Наверное, объектные пуристы ответят «нет», тогда как объектные евангелисты, вероятно, будут поддерживать этот подход — как все другое, что, по их мнению, является замечательным и будет работать. Конечно, можно реализовать это на каком-нибудь объектно-ориентированном языке или воспользоваться ретро-методами и собрать интерфейс из процедур. Для пользователей важнее всего соответствие интерфейса той работе, которую они выполняют.