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

43 Глубокое понимание

43

Глубокое понимание

На что похож объект? Кто его применяет и как? Какую пользу он приносит?

В известном смысле пользователи и обращенные к ним пользовательские интерфейсы есть raison d'etre[39] объектной технологии. Именно для решения задач, связанных с графическим представлением информации и взаимодействием пользователя с устройствами, позднее названными электронно-лучевыми дисплеями, Айвен Сазерленд (Ivan Sutherland) первым сформулировал многие базовые понятия объектно-ориентированного программирования. Действительно, мой коллега-преподаватель однажды заметил, что почти все, что есть в современной объектной технологии, можно найти в диссертации по Sketchpad, представленной Сазерлендом в 1963 году (Sutherland, 1963 [61]).

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

Будучи преподавателем в Сиднейском технологическом университете, я проанализировал некоторые из самых известных и успешных книг по объектно-ориентированному анализу и проектированию. Это была высококлассная выборка. Сначала я проверил каждую книгу по этой теме в моем офисе, потом прошел по коридору к профессору Брайану Хендерсон-Селлерзу (Brian Henderson-Sellers) и пробежался по его книжным полкам. Конечно, я не удивился, что у него много таких же книг, как у меня, но все же нашел 15 других, недавно вышедших книг по объектно-ориентированной разработке, включая почти все из самых известных и цитируемых. В целом, в книгах было около 6000 страниц. И лишь 161 страница относилась к обсуждению аспектов, связанных с пользователями, пользовательскими требованиями, юзабилити или пользовательскими интерфейсами. Почти три четверти из этих страниц принадлежали трем книгам. Больше половины книг содержали три или меньше страниц, посвященных пользователям и применению продуктов. Треть книг не содержали никаких подходящих упоминаний в предметном указателе. В одной книге нашлась целая страница, посвященная полезности программного обеспечения, но она не попала в указатель. Наверное, сейчас ситуация меняется, что подтверждается появлением нескольких книг, в том числе: «Designing Object-Oriented User Interfaces» (Разработка объектно-ориентированных пользовательских интерфейсов) (Collins, 1995 [9]) и «Object Modeling and User Interface Design» (Объектное моделирование и разработка пользовательских интерфейсов) (van Harmelen, 2000 [63]). Согласитесь, выход этих книг нисколько не преждевременен, и ни одна страница этих книг не является лишней.

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

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

Большинству пользователей не интересно, что находится «под капотом» тех систем, которые они применяют. Дон Норман (Don Norman), эксперт по юзабилити и защитник удобства применения технологий с точки зрения пользователя, говорит просто: для потребителя пользовательский интерфейс и есть система (Norman, 1988 [53]). Но бывают исключения. При определенных обстоятельствах технология, спрятанная «под капотом», становится важной для пользователя. Она становится важной, если легковой автомобиль не может разогнаться и безопасно обойти грузовик. Или когда компилятор не может выдавать качественный код. Технология приобретает значение, если двигатель нужно ремонтировать или регулировать через каждые 5000 км. Она важна, если Windows необходимо перезагружать через каждые несколько часов из-за утечки памяти в пакете офисных презентаций.

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

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

Что же такое ООПИ¹? Еще одна аббревиатура с двойным «О» или что-то еще? Существует ли настоящий объектно-ориентированный пользовательский интерфейс? Захочет ли его применять уважающий себя человек? Если это всего лишь ГПИ с возможностью непосредственного мани-пулирования визуальными объектами, то добавление 00 почти ничего не меняет для ПИ.

Одна из постоянных трудностей в мире ОО становится особенно неприятной, когда речь заходит о пользовательском интерфейсе. Эта трудность — различие (или чаще его отсутствие) между объектами в программном обеспечении или программных моделях и объектами в банальном смысле, то есть объектами внешнего физического мира, который так часто с высокомерием называют «реальным миром». Многие новички в объектной технологии попали в ловушку, думая, что для успеха в работе с объектами достаточно найти объекты в реальном мире, настрочить немного кода для классов, к которым принадлежат объекты, и программное обеспечение уже готово для поставки. Что может быть более бесшовным? Как убедительно показали Айвар Джекобсон (Ivar Jacobson) и другие методисты, в качественных программных системах многие из наиболее важных объектов не соответствуют напрямую объектам из реального мира или предметной области.

Банальное и техническое значения слова «объект» все еще объединяют или путают. Согласно повседневной терминологии, все пользовательские интерфейсы содержат в себе объекты, которыми пользователи могут манипулировать. Тот факт, что некоторые объекты представляют собой монохромные символы, управляемые с помощью команд с клавиатуры, не делает их менее достойными именоваться «объектами».

В своей книге на эту тему Дэйв Коллинс (Dave Collins, 1995 [9]) предложил «определение» ООПИ, основанное на трех характеристиках: (1) пользователи воспринимают объекты и воздействуют на них; (2) пользователи классифицируют объекты исходя из поведения объектов; (3) все интерфейсные объекты объединены в одну общую согласованную концептуальную модель. Звучит неплохо, но первый пункт относится к пользователям, а не к пользовательским интерфейсам. Можно возразить, что восприятие объектов присуще человеческому мозгу, если речь идет об обычных объектах, либо является феноменом, существующим только для разработчиков, если речь идет о программных объектах. Второй пункт, касающийся классификации, также относится к пользователям, а не к интерфейсам. Это правило почти наверняка не подходит для всех людей (или даже для кого-то одного), если принимать во внимание все возможные обстоятельства. Люди классифицируют обычные объекты по многим свойствам и показателям, которые не относятся к поведению. Например, вы можете сказать, что все политики действуют почти одинаково, однако ваш друг при этом похож на Билла Клинтона. Что касается третьего предполагаемого свойства ООПИ, то согласованность модели является характеристикой любых хорошо организованных пользовательских ин-терфейсов: хорошие интерфейсы внутренне непротиворечивы и воспринимаются как одно целое.

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

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

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

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

Коллинс противопоставляет ООПИ другим, не объектно-ориентированным ПИ, но тот соломенный заборчик, который он возводит, на самом деле является древним интерфейсом командной строки. В интерфейсах командной строки глагол (команда) ставится перед дополнением (параметром). Иногда утверждается, что грамматика типа «дополнение-глагол» в ООПИ является более естественной и более гибкой — выбираете картинку и щелкаете по инструменту изменения цвета или перетаскиваете документ к принтеру.

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

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

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

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

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

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

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

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

По материалам журнала Object Magazine, сентябрь 1996 г.

Оглавление книги