Человеческий фактор в программировании
Шрифт:
Есть ли вообще смысл выставлять механизмы объектной технологии в интерфейсе, предназначенном для конечных пользователей? Как правило, если логика и структура программы становятся видны на экране, что-то является неправильным. Это признак конструкции вида «изнутри наружу», в которой интерфейс становится тонкой и пятнистой кожей, покрывающей бугорчатые внутренности. Наоборот, конструкция вида «снаружи внутрь» означает то, что внутренние компоненты и их внешние проявления отражают потребности пользователя, а не структуру программы.
Так называемые «объекты-фабрики» («factory objects»), помещенные в интерфейс, можно привести в качестве примера полезного исключения. Визуальные компоненты, которые при щелчке мышью или при перемещении порождают новые экземпляры класса, являются интересной и недостаточно используемой формой объектно-ориентированной технологии пользовательских
Коллинс противопоставляет ООПИ другим, не объектно-ориентированным ПИ, но тот соломенный заборчик, который он возводит, на самом деле является древним интерфейсом командной строки. В интерфейсах командной строки глагол (команда) ставится перед дополнением (параметром). Иногда утверждается, что грамматика типа «дополнение-глагол» в ООПИ является более естественной и более гибкой — выбираете картинку и щелкаете по инструменту изменения цвета или перетаскиваете документ к принтеру.
Если вы хотите получить удобный пользовательский интерфейс, то навязывание этого синтаксиса пользователю во имя чистоты объектно-ориентированной технологии — не очень подходящая идея. Плотник сначала берет гвоздь, а потом подносит к нему молоток — не наоборот. В задачах, решаемых в реальном мире, объекты как дополнения и объекты как операторы, как правило, не являются взаимозаменяемыми. Можно ударять молотком по гвоздю, но проводить обратную операцию бессмысленно.
Если одной из сильных сторон объектно-ориентированной технологии назвать сохранение соответствия с языком предметной области, то это относится к конструкции ООПИ. На самом деле хороший дизайн ПИ всегда согласуется не только с языком пользователей и предметной областью, но также с задачами из этой предметной области, которые интересуют пользователей. Такое соответствие достигается только тогда, когда у нас есть время для осмысления намерений пользователя и его действий.
Чтобы спуститься с абстрактных высот, рассмотрим одну частную, но показательную задачу: разработка взаимодействия со степлером в системе управления документами. Так же как чистые листы бумаги или документы можно скрепить вместе и получить единое целое, так и степлер в ПИ позволяет собирать совокупности документов в группы, которыми пользователь может манипулировать как единым целым.
В реальном мире работник офиса может поднести стопку документов к степлеру и скрепить их. Это соответствует «объектно-ориентированной» идиоме drag-and-drop: щелкаем мышью по пиктограмме стопки документов, перетаскиваем ее к пиктограмме степлера и отпускаем. Обратите внимание, что операция почти идентична выделению объекта нажатием кнопки мыши, затем перемещению указателя к степлеру и выполнению еще одного нажатия кнопки мыши, но только с одной существенной разницей. Для многих пользователей операция drag-and-drop оказывается одной из наиболее сложных для освоения. Они предпочитают последова-тельно щелкать мышью по двум объектам. Для них это проще, чуть быстрее и гораздо надежнее. Однако другие пользователи, зараженные интерфейсами командной строки или развращенные многолетним выполнением реальной работы вместо использования компьютеров, могут предпочесть сначала выбрать инструмент для скрепления и потом щелкнуть мышью по стопке документов, которые нужно скрепить.
Любое утверждение о том, что способ drag-and-drop — самый естественный и правильный, еще более ослабляется следующим аргументом. При разумной реализации стопка документов не должна оставаться в зубах объекта «степ л ер», так же как распечатанный документ не должен оставаться над пиктограммой принтера. Даже пуристы MacMetaphor признают возможность компьютера выполнять какую-то часть этой манипуляции. Они охотно согласятся на то, чтобы перетаскиваемые объекты чудом перескакивали на свои начальные позиции.
В реальном мире люди не путают метафоры объектов и функций. Они могут поднести бумагу к степлеру или степлер к бумаге и применить его, ничего не перепутав. Хороший пользовательский интерфейс дает такую же гибкость или даже увеличивает ее. Не создавая путаницы, такой интерфейс допускает все основные варианты взаимодействия: (1) перетаскиваем стопку бумаги к степлеру; (2) щелкаем мышью по стопке бумаги, потом щелкаем по степлеру; (3) щелкаем мышью по степлеру, потом щелкаем по стопке бумаги; (4) перетаскиваем степлер к стопке бумаги. Хорошая реализация интерфейса предоставляет пользователю все эти возможности. Степлер должен выглядеть солидно, всем своим видом показывая, что к этой пиктограмме можно перетаскивать другие. А при щелчке мышью пиктограмма степлера должна изменяться так же, как и любая кнопка. При щелчке мышью она должна «утопать». При приближении перетаскиваемой стопки бумаги ее цвет должен изменяться, чтобы показать готовность
степлера. Если же вы пытаетесь перетащить к нему принтер, степлер должен ответить отказом. Соответствующая анимация, изображающая работу степлера (со звуком или без), должна сообщать пользователю о завершении операции. Когда вы берете степлер как инструмент, ничего при этом не выделив, указатель превращается в пиктограмму ручного степлера.Является ли такой подход к ПИ объектно-ориентированным? Наверное, объектные пуристы ответят «нет», тогда как объектные евангелисты, вероятно, будут поддерживать этот подход — как все другое, что, по их мнению, является замечательным и будет работать. Конечно, можно реализовать это на каком-нибудь объектно-ориентированном языке или воспользоваться ретро-методами и собрать интерфейс из процедур. Для пользователей важнее всего соответствие интерфейса той работе, которую они выполняют.
Выбор технологии реализации может представлять интерес для пользователей, когда речь идет о добавлении новых возможностей или изменениях в соответствии с новыми требованиями. В конечном итоге, надежная технология, позволяющая быстро и качественно интегрировать новые возможности, приносит больше пользы, чем технология, которая не допускает изменений. Если под объектно-ориентированным пользовательским интерфейсом понимать интерфейс, построенный из взаимодействующих программных объектов, то в этом может быть большой выигрыш. Конечно, для создания такого интерфейса мы должны хорошо его понимать и действовать согласно нашему репертуару, конструируя гибкие, повторно используемые компоненты.
По материалам журнала Object Magazine, сентябрь 1996 г.
44
Абстрактные объекты
В фантастическом фильме «Темная звезда», являющемся классикой андеграунда, смелый лейтенант Дулитл пытается прочитать лекцию по феноменологии умной бомбе, готовой разнести себя вместе с кораблем. «Вселенная — это абстракция, — поспешно объясняет он, — и все, что мы когда-нибудь узнаем о ней, является абстрактными построениями нашего собственного сознания, пропущенными через наши ограниченные и ненадежные чувства». Отсюда вывод: не делайте потенциально фатальных выводов на основе возможно неверных построений.
Переходя к конкретным случаям, можно сказать, что объектная технология построена на основе абстракций. Классы абстрагируют свойства от множества экземпляров, а абстрактные классы действуют как понятийные ячейки для организации конструктивных идей. Даже экземпляры программных объектов являются тонкими абстракциями, не более чем призраками в машине, в лучшем случае дублерами, заменяющими отсутствующих актеров или существ из внешнего мира.
Временами, когда мы учим эту темную процедурную деревенщину, которая приходит в классы для избавления от своих структурных ограничений, мы начинаем с того, что обращаем внимание на реальные экземпляры стульев, или работников, или видеокассет, находящихся поблизости. Рано или поздно для ориентирования в объектном мире студенты начинают думать в терминах программных объектов и строить устойчивые абстракции. Это не новая задача с точки зрения обучения людей. До появления объектов существовали абстрактные типы данных. В те времена, когда модули в машинах были простыми подпрограммами, разложение цельных задач на абстрактные функции лежало в основе хорошего программного проектирования. По правде говоря, вся разработка программного обеспечения основана на абстракциях и абстрактных моделях. Абстракция дает нам возможность думать о целом, объяснять противоречивое и непредставимое и исследовать внутреннее содержание будущих программ, не создавая их. С позиций разработки, абстрактное мышление является сложным и тонким методом, для освоения которого детям требуются годы. Некоторым же взрослым никогда не удается освободиться от устойчивого буквализма, но было бы неприлично называть их имена.
Что касается остальной части нашей дисциплины, юзабилити-инжини-ринг и проектирование пользовательских интерфейсов являются специальностями, которые можно считать отстающими составляющими разработки. Или, как сегодня можно сказать, «абстрактно востребованными». Разработчики механизмов взаимодействия и проектировщики пользовательских интерфейсов записывают свои мысли на бумаге или в компьютере. Их изображения почти всегда очень похожи на то, что они разрабатывают. Они делают эскизы или тщательные рисунки, макеты или прототипы. Иногда рисунки бывают грубыми, одноцветными и неэстетичными, но все же они выглядят как экраны, формы и диалоговые окна, напичканные меню и панелями инструментов, списками и переключателями. Истинные юзабилити-специалисты и графические дизайнеры могут даже рисовать рожицы на своих штриховых рисунках или человечков на пояснительных заметках с карандашными расчетами. Они составляют детальные и точные сценарии и увешивают свои офисы диаграммами, которые могли бы привести в восхищение работников студии Диснея.