Графические пользовательские интерфейсы не имеют ничего общего с юзабилити — они связаны с графикой. Какой смысл в фантастическом ГПИ, если вы не применяете его для рисования красивых картинок? А с учетом того, что качество изображения на экране монитора растет, почему бы не анимировать ваши замечательные картинки? Целью является повышение продаж, а мишенями — обозреватели и покупатели программного обеспечения, которые смотрят (не очень внимательно), а потом пишут восторженные рецензии или покупают лицензию на использование системы. Потребители, которые больше заботятся о том, чтобы действительно выполнять работу, — это совсем другая группа людей, поэтому вы больше слышите о пользовательских интерфейсах, чем о юзабилити; больше говорится о философии проектирования, ориентированного на пользователя, чем о реальной поддержке процесса работы; больше рассуждений о необходимости прислушиваться к голосу покупателя, чем о внимании к проблемам пользователей.

Возьмем объектную технологию. Если когда-то всему надлежало быть «структурированным», чтобы заслуживать внимания, то теперь все обязано быть «объектно-ориентированным». Если что-то не «объектно-ориентировано», оно не считается современным. Если программное обеспечение не построено из «объектов» и «классов», то в нем не может быть ничего хорошего. В примитивном представлении объекты считаются естественными и интуитивными. Более того, они политически корректны, потому как могут использоваться повторно!

Сегодня пользовательские интерфейсы стали объектно-ориентированными. По крайней мере, так написано на коробке.

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

На что же похожа эта объектная революция, когда она переходит из языка программирования в пользовательский интерфейс? Представьте такую картину. На экране показана модель карманной записной книжки-ежедневника. Вы можете щелкать мышью по вкладкам для перехода к любому разделу. Вы можете щелкнуть мышью в углу «страницы» и «пе-релистнуть» ее. Ну надо же, как удобно! Конечно, большую часть времени пол-экрана не задействовано, а для чтения надписей на вкладках нужно поворачивать голову — сначала по часовой стрелке, потом против, поскольку при перелистывании страниц текст переворачивается с одной стороны на другую. Ах, но зато это выглядит таким знакомым, а ведь каждый знает, что знакомые метафоры облегчают применение программного обеспечения, не так ли? Особенно не следует придавать значение тому, что на экране super-VGA помещается меньше информации, чем на старом DOS-дисплее с 80 колонками, хотя информация отображается более мелким шрифтом. Зато все в цвете. Это очень приятно, если только вы не являетесь одним из двенадцати мужчин, которые не различают цвета. Этот «персональный информационный менеджер», должно быть, очень полезная штука, раз в нем так много замечательных картинок. Но постойте, это не просто картинки, это объекты! Их можно перемещать, с ними можно работать, с ними можно взаимодействовать, и это делает вашу жизнь такой приятной.

В другом персональном информационном менеджере на экране показана картинка вращающегося файла предметного указателя (наподобие Rolodex™). Щелкаете по крышке, она открывается, и вы видите небольшие карточки, на которых написаны имена, адреса и телефонные номера. Щелкните и потяните за «ручки», расположенные по обе стороны, и карточки начнут переворачиваться.

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

Что же такое объектно-ориентированный интерфейс? Пиктограммы, панели кнопок и выпадающие меню — ваш персональный вариант ГПИ? Или же это методы «указать-выбрать» (point-and-click) и «перетаскивание» (drag-and-drop), являющиеся догмами непосредственного манипулирования? (Кстати, если приводить точные аббревиатуры, то мы сейчас говорим об OOI GUI WIMP.) Может быть, это любой пользовательский интерфейс, созданный с помощью языка объектно-ориентированного программирования, или же пользовательский интерфейс любой системы, разработанной с помощью объектно-ориентированных методов, независимо от языка? Возможно, это означает, что интерфейс усыпан картинками «реальных» объектов. Или то, что пользователи могут взаимодействовать с системой, передавая объектам сообщения («Документ, распечатай себя»).

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

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

Играет ли это какую-нибудь роль? Какое значение имеет форма пиктограммы или детали копирования с помощью «выбрать-перетащить» (click-and-drag)? Большое. Небольшие ошибки и небольшое раздражение постепенно накапливаются, замедляя работу, а не ускоряя ее. Работа — это то, что некоторые из нас пытаются выполнить, часами просиживая за рабочим столом. Программное обеспечение, которое противоречит человеческим способам мышления и решения задач, неизбежно приводит к росту количества ошибок. Если программа заставляет пользователя выполнять лишние шаги, или думать дважды, или переосмысливать что-либо, то независимо от того, насколько он свыкнется с программой, количество его ошибок будет больше неизбежного минимума. На самом деле эти дополнительные ошибки вовсе не являются человеческими. Они вызваны ошибками в интерфейсе, в программном обеспечении.

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

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

Еще на заре компьютерной эры, когда проектирование программного обеспечения было связано лишь с обработкой данных, аналитики и программисты поняли горькую истину: простая автоматизация старых ручных методов приводит к созданию плохих систем, являющихся всего лишь неудобными эмуляциями, а не полезными нововведениями. Сегодня у нас есть «объектно-ориентированные интерфейсы» — и что произошло со старыми продуктами Rolodex™? Они переместились с рабочего стола на так называемый «рабочий стол»! Создатели этих бездумных копий ручных систем не учли того факта, что изначально продукты Rolodex™ сами по себе были технологическим прорывом. Они позволили отказать-ся от неудобной технологии индексных карточек, которые, в свою очередь, применялись вместо менее удобных конторских книг. Rolodex™, или DayTimer™, или DayRunner™, которые кажутся весьма полезными, когда вы держите их в руках, становятся просто неудобными и бестолковыми, когда они моделируются на экране.

Все дело в том, что объектная технология испытывает затруднения из-за наивной мифологии. Айвар Джекобсон (Ivar Jacobson), гуру в объектной технологии, отмечает, что наивные объектные модели приводят к программному обеспечению, которое ненадежно в условиях изменяющихся требований и целей. Наивные объектные модели основаны на примитивном поиске программной среды для объектов из «реального мира». Далее поведение объектов отображается в объектных классах. Практика описания поведения с помощью кнопок и пиктограмм, представляющих объекты из реального мира, является не менее наивной и ведет к созданию ненадежных интерфейсов.

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

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

Между объектной технологией и хорошим пользовательским интерфейсом существует реальная связь, но она тонкая и отчасти косвенная. При хорошей вспомогательной инкапсуляции и сокрытии информации объекты позволяют производить более рациональное и эффективное разбиение задачи на подзадачи. Качественная объектно-ориентированная архитектура программного обеспечения помогает четко отделить реализацию пользовательского интерфейса от реализации базовой функциональности приложения и в то же время сохранить их взаимосвязь. Качественная объектно-ориентированная разработка программного обеспечения подразумевает разделение объектных классов, представляющих и обеспечивающих разные аспекты задачи (Jacobson и др., 1992 [44]). Интерфейсные объекты, которые инкапсулируют интерактивное поведение с характеристиками и элементами внешних интерфейсов, могут быть отделены от других объектов — от объектов предметной области, которые инкапсулируют данные и поведение, связанные с понятиями и структурами предметной области, а также от управляющих объектов, которые осуществляют координирование и взаимодействие множества объектов.

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

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

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

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

По материалам журнала Object Magazine, июль 1993 г.

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

В известном смысле пользователи и обращенные к ним пользовательские интерфейсы есть 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 г.

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

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

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

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

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

Появление превосходных и мощных инструментов визуального проектирования, таких как Delphi компании Borland или Visual Age компании IBM, по-видимому, способствовало еще большему распространению примитивного метода проектирования и даже возвысило его до уровня стандартной практики. При помощи современных инструментов люди проектируют пользовательские интерфейсы, не проектируя, а конструируя их. Они соединяют объекты вместе, манипулируя реальными окнами списков, сетками данных и другими компонентами из растущего разнообразия приспособлений современного ГПИ. Конечно, ярые сторонники точности и объектно-ориентированной чистоты тут же заметят, что некоторые мнимые объектно-ориентированные среды визуального проектирования лучше было бы назвать средами, основанными на методе экземпляров, а не объектно-ориентированными. Однако как самые лучшие, так и самые худшие инструменты находятся почти на одном уровне, если вести речь о конкретных элементах управления. Внутри этих инструментов предметы означают самих себя. Форма, являющаяся формой, является формой.

Быстрая зарисовка на бумаге со множеством сырых пиктограмм и косых линеек прокрутки является в той степени абстрактной, в какой большинство разработчиков пользовательских интерфейсов может ее понять. Когда пользователи жалуются на нечитаемость или указывают на недостаток мастерства дизайнеров, разработчики быстро перестают делать рисунки для программного обеспечения. Ведь быстрее и проще накидать в форму каких-нибудь реальных «штучек» с помощью Visual Objects, или Visual Basic, или Visual Age, или Visual Goober. Всего за несколько минут можно создать работоспособный интерфейс. Он выглядит как первоклассный интерфейс, потому что он и есть первоклассный. И кроме того, как и многие первоклассные компоненты реального программного обеспечения, он с помощью клавиатуры переместился из замысла прямо на экран, минуя этап тщательного обдумывания.

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

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

Работа контекстна. Работая на складе или в офисе, в гараже или на компьютере, люди выполняют свои задачи в четко определенных контекстах с заранее известными наборами инструментов и материалов. Для выполнения какой-то конкретной задачи люди идут туда, куда нужно, с тем инструментом, который требуется. Желая нарисовать картину, вы становитесь перед мольбертом с палитрой и кистью в руках. Для приготовления поздним вечером итальянского блюда вы идете на кухню, берете несколько томатов, базилик и чеснок, кастрюли для макарон и для соуса, ложку и терку для pecorino.[40] Решив отремонтировать сломавшийся стул, вы идете в нужное место и берете нужные материалы и инструменты. Даже если место остается одним и тем же, контекст меняется в соответствии с требованиями текущей задачи. Помощник зубного врача раскладывает на подставке разные наборы инструментов для обработки канала зуба или для выполнения обычной чистки.

Как можно представить такие разнообразные контексты применения, не вдаваясь в конкретные детали? Как можно без схем и макетов экранных изображений показать, что следует связать, а что следует разделить? На помощь приходит интерфейсная контент-модель. Люди придумывали различные варианты этого метода, но решающее влияние оказала техника фиксации требований с помощью клеящихся листков, прикрепляемых к листу большого перекидного блокнота (Holtzblatt и Beyer, 1998 [40]).

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

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

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

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

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

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

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

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

Как любил отмечать французский пуантилист Жорж Сера (Georges Seu-rat), именно пустой холст, а не законченный портрет наводит на изобретение нового. Наверное, пришло время для того, чтобы объектно-ориентированная технология применила силу абстракции к проблеме взаимодействия.

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

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

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

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

Как нам говорят, непротиворечивость является критерием хорошего пользовательского интерфейса (см. главу 34). Пользователи предпочитают интерфейсы, которые выглядят и работают подобно уже известным им интерфейсам. Такие интерфейсы для них более комфортны. Каждое предполагаемое новшество, каждое новое устройство или средство наталкивается на высокий барьер в виде некоторого естественного сопротивления. Даже более совершенные интерфейсы могут категорически отвергаться пользователями, которые не хотят или не могут научиться новым способам взаимодействия со своими компьютерами. Пользователи Apple Macintosh хорошо известны тем, что всегда настаивают на непротиворечивости и отвергают программное обеспечение с «немакинтошевским» поведением или функциями. Но многие ли сейчас помнят, что среди первых тестеров ОС Macintosh нашлись такие, которые посчитали ее крайне неудобной, ставя в вину отсутствие стандартных команд и какого-либо из принятых приглашений вида «С:›».

У новаторов есть целая масса хороших концепций, на основе которых они могут разрабатывать пользовательские интерфейсы — одновременно и оригинальные, и вполне знакомые. Многие методы создания внутренней структуры объектно-ориентированных программ также находят применение при разработке пользовательского интерфейса. Обобщение и конкретизация, компоновка и перекомпоновка, расширение и перегрузка — все эти методы могут помочь в разработке новых эффективных интерфейсных средств и способов взаимодействия с ними. Зачастую самые удачные новшества в пользовательских интерфейсах — это не впечатляющие рывки в будущее, а вариации на заданную тему, когда знакомые элементы комбинируются в новых сочетаниях. Художник-новатор Билл Бакстон (Bill Buxton) назвал это «радикальной эволюцией».

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

Инновации и непоследовательность могут проявляться в различных аспектах пользовательского интерфейса: во внешней форме объектов, в их поведении или в идиомах, посредством которых мы взаимодействуем с ними. Алан Купер (Alan Cooper), который прямо критикует многие современные методы разработки пользовательских интерфейсов, ввел термин идиомы взаимодействия, обозначающий идиоматические жесты и последовательности, с помощью которых пользователи взаимодействуют с графическими пользовательскими интерфейсами. Из общепринятых идиом для общения с программным обеспечением на основе ГПИ можно назвать следующие: один щелчок мышью для выделения или активизации, двойной щелчок для открытия или запуска, обведение для выделения группы объектов, перетаскивание (drag-and-drop) для перемещения объектов.

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

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

В основе объектно-ориентированной парадигмы лежит взаимодействие посредством сообщений. Хорошее взаимодействие с пользователями также является ключом к созданию новых интерфейсов, способных обучить пользователей работе с ними. Психолог и гуру в юзабилити Дональд Норман (Donald Norman) ввел два понятия, которые могут помочь разработчикам придумывать новые компоненты и идиомы — новые, но понятные и удобные. Ограничители — это элементы пользовательского интерфейса, которые сообщают об ограничениях той или иной операции. Они помогают пользователям избежать бесполезных или бессмысленных действий.

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

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

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

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

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

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

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

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

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

По материалу из журнала Object Magazine, март 1997 г.

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

Ряд ведущих специалистов-практиков также пришли к заключению, что пользовательские ситуации полезны при разработке пользовательских интерфейсов (см. главу 22). Если пользовательские ситуации можно применять для управления разработкой объектного взаимодействия и разбиения методов по классам, значит, их можно применять для проектирования взаимодействия между человеком и компьютером и для распределения элементов интерфейса между интерфейсными контекстами. Логика может показаться неубедительной, однако эта идея обладает привлекательностью, являясь своего рода технологическим вариантом волшебства, основанного на внушении. В конце концов, оба термина имеют общий ко-рень и могут даже рифмоваться. «Идя в рейсы по пользовательскому интерфейсу, не забывайте пользовательские кейсы»[41] — это вполне может быть девизом часа.

Конечно, проектировщики взаимодействий и другие специалисты по пользовательским интерфейсам уже много лет применяют разные формы сценариев, включая раскадровки — визуальные эквиваленты киносценариев. И вот к чему это привело. Офисные программные пакеты теперь все больше и больше напоминают широкоэкранные голливудские киноэпопеи с распределением ролей между смешными закадычными друзьями, вызывающими раздражение. (Честно говоря, я каждый день пускал бы дорожный каток по анимированной скрепке.)

Айвар Джекобсон (Ivar Jacobson) объясняет, что сценарии и пользовательские ситуации — это не одно и то же, несмотря на все заявления «ну и что, мы тоже их применяем» от людей, всегда говорящих «мы тоже», и вопреки всем творческим переопределениям, сделанным батальонами практиков. И то и другое — это модели задач, в которых применяются описания последовательности событий, однако пользовательская ситуация является абстракцией, отдельным случаем (видом) использования. В сценарии документируется конкретный пример взаимодействия. В нем представлено буквальное, если не литературное описание (Constantine и Lockwood, 2000). Чтобы написать сценарий взаимодействия пользователя и пользовательского интерфейса, нужно представлять себе и пользователя, и интерфейс. Кроме того, необходима возможность ссылаться в описании на сам интерфейс и его компоненты. Это значит, что сценарии не могут помочь в разработке пользовательских интерфейсов, поскольку пользовательский интерфейс является одним из персонажей этой истории. Перед созданием сценария вам обязательно нужно придумать хотя бы частичную схему пользовательского интерфейса. Сценарии не бесполезны — они помогают понять задачи и доработать формы взаимодействия с уже созданным пользовательским интерфейсом. Однако обычно сценарии слишком конкретны, чтобы помочь в разработке структуры и содержимого совершенно нового пользовательского интерфейса. (Constantine и Lockwood, 1999 [30]).

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

Пользовательские ситуации не только дают внешнее представление, но и отступают от буквального языка сценариев, обращаясь к более абстрактному языку переменных и классов. Например, в сценарии может быть написано: «Программист Паула щелкает по пиктограмме на рабочем столе, чтобы запустить мастер технической поддержки. Ей предлагаются два варианта соединения: сетевое или модемное. Она выбирает модемное. Затем предлагается ввести номер пользователя — она набирает 4477-610. Далее, в предложенном списке проблем она щелкает по пункту «Проблемы с печатью» и т. д». В пользовательской ситуации, наоборот, дается более общее описание: «Пользователь щелкает по пиктограмме запуска программы технической поддержки, производит соединение с системой, вводит номер пользователя, выбирает пункт из предложенного списка проблем». Таким образом, мы делаем шаг назад, который приближает нас к пониманию реальной задачи, стоящей перед пользователем.

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

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

По этим причинам Люси Локвуд (Lucy Lockwood) и я разработали метод сущностных пользовательских ситуаций как упрощенную, обобщенную и более абстрактную модель в сравнении с ее конкретными аналогами (см. главу 22). Абстракция (как об этом говорилось в главе 44) способствует новаторскому мышлению и созданию более надежного дизайна. Целью моделирования сущностных пользовательских ситуаций является описание пользовательских задач как таковых — без каких-либо технологических допущений и ограничений. Сущностная пользовательская ситуация представляет собой абстрактную сущность целей пользователя. Она выражается в терминах намерений, а не в терминах действий пользователя. Например, пользователи системы технической поддержки намереваются получить помощь — сообщить, кто они, и объяснить, с какой проблемой или проблемами они столкнулись.

Сущностные пользовательские ситуации не только отделяют пользовательскую проблему от дизайнерских решений, но и различают пользовательские намерения и системные ответы, обеспечивающие реализацию этих намерений. Вместо одного свободного описания взаимодействия — того описательного подхода, который применяется в сценариях и большинстве пользовательских ситуаций, — сущностные пользовательские ситуации принимают форму структурного описания, в котором диалог разбивается на две колонки: то, что пользователь хочет сделать, и то, что система должна представить в качестве ответа. Названия этих колонок: модель пользовательских намерений и модель системных ответов. Такая модель имитирует формат, предложенный Ребеккой Уирфс-Брок (Rebecca Wirfs-Brock) для конкретных пользовательских ситуаций. В задаче, связанной с разработкой системы технической поддержки, сущностную пользовательскую ситуацию можно назвать получение технической помоши. Она может принять следующую форму:

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

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

Подобно применению наследования для определения классов и подклассов внутри объектно-ориентированных программ, мы можем создать квалификационную иерархию сущностных пользовательских ситуаций. В этой иерархии абстрактные ситуации содержат типичные или совместные части описаний, а подситуации содержат конкретные детали. Точно так же с помощью объединения простых ситуаций мы можем построить комплексные пользовательские ситуации. Одним из самых мощных средств для организации и упрощения сущностных пользовательских ситуаций является новаторский метод, представленный Джекобсоном (Ja-cobson и др., 1992 [44]). Части описания, которые являются необязательными или особыми вариантами, можно выделить и определить как расширения. С помощью каждого расширения можно расширить любое количество других пользовательских ситуаций. Например, в системе технической поддержки пользователь, следуя пользовательской ситуации, может запрашивать помощь у оператора. Эта пользовательская ситуация, запрос помоши оператора, является расширением других пользовательских ситуаций, поскольку она представляет собой дополнительный или особый случай взаимодействия, основанный на альтернативной или второстепенной цели пользователя.

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

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

Хотя документация и справочные системы зачастую бывают упрощенными, они являются важными компонентами для обеспечения юзабилити систем — настолько важными, что самая большая глава в книге «Software for Use» (Constantine и Lockwood, 1999 [30]) целиком посвящена разработке справочных систем. Хорошая документация и правильно организованная, отзывчивая справочная система могут облегчить применение сложной системы; и наоборот, неадекватная, плохо организованная справочная система способна полностью испортить систему, которая во всех других отношениях разработана грамотно.

Организация документации и онлайновой помощи на основе сущностных пользовательских ситуаций — это новый и эффективный способ улучшения юзабилити программного обеспечения. Сущностные пользовательские ситуации представляют собой все возможные потребности пользователя и цели, которых можно достичь при помощи данной программы. Каждая сущностная пользовательская ситуация, написанная должным образом, является отдельной задачей, которая закончена и четко определена с точки зрения внешнего пользователя. Эта задача описана на языке пользователей с учетом данной предметной области. Вот почему сущностные пользовательские ситуации идеально подходят для организации справочной системы, ориентированной на задачи («how to…?»). При этом каждая ситуация имеет свой раздел и содержит набор инструкций для активизации данной пользовательской ситуации. Даже взаимосвязи внутри карты пользовательских ситуаций — расширение, конкретизация и объединение — могут быть уместно и естественно отображены в документации и справочной системе в виде связей и перекрестных ссылок.

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

По материалам журнала Object Magazine, июнь 1997 г.

Проектирование основано на измерении. Мост должен быть достаточно длинным, чтобы соединить берега, и достаточно крепким, чтобы выдержать заданную статическую нагрузку. Он должен обладать структурной стабильностью, чтобы выдерживать предполагаемую максимальную скорость ветра и сохранять устойчивость при землетрясениях определенной силы. Измерение не менее важно и в проектировании программного обеспечения, однако метрика программного обеспечения до сих пор часто воспринимается как углубленный и эзотерический предмет, в основном представляющий интерес для теоретиков, которые стремятся получить исследовательские гранты, или для подрядчиков военных ведомств, которые стараются попасть в правительственные квоты.

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

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

Для разработчиков количественные измерения качества проектирования потенциально являются более важными, чем простые измерения количества кода. Проектная метрика основана на исчисляемых и измеряемых аспектах проекта, которые описывают важные стороны законченного продукта — все, что интересует разработчиков с точки зрения предполагаемого метода реализации, работы и обслуживания данного программного обеспечения. Например, компонентное сцепление и межкомпонентное связывание, два известных измеримых параметра проектирования, описывают, насколько легко можно будет модернизировать или расширить программу с помощью частичной декомпозиции на взаимосвязанные элементы. Термины «сцепление» и «связывание», впервые появившиеся в раннюю эпоху структурного проектирования (Yourdon и Constantine, 1979 [70]), со временем перешли в объектно-ориентированное проектирование в виде мер сцепления классов и межклассового связывания. Формы этих мер были широко исследованы — как классическая, так и объектно-ориентированная (Henderson-Sellers, Constantine и Graham, 1996 [39]).

В ответе на основной вопрос «лучше ли этот проект, чем тот?» измерение проектных параметров дает ряд ощутимых преимуществ для разработчиков и дизайнеров. Эти измерения позволяют сравнивать разные подходы и определять наилучшее решение, не прибегая к постановлениям руководства или бросанию летающих тарелок с 30 шагов. Уже на ранних этапах разработки они позволяют узнать, идет ли она по правильному пути и на каком повороте могут возникнуть серьезные трудности. В процессе проектирования или последовательной доработки они позволяют нам оценить, изменяется ли проект в лучшую сторону или просто изменяется. Правильные измерения, выполненные в правильный момент, могут сказать нам о том, насколько совершенным является наш проект в некотором абсолютном смысле. Является ли эта версия достаточно близкой к оптимальной или к оптимуму еще нужно проделать долгий путь? Принесут ли какую-нибудь существенную пользу дополнительные испытания или доработки?

В разработке программного обеспечения измерения играют и стратегическую роль — с точки зрения бизнеса. Цифры обладают таким влиянием, которое может отсутствовать в простых словах — особенно сейчас, когда ценность слов была уменьшена многолетними безосновательными утверждениями и пустыми обещаниями. В условиях жесткой конкуренции, сокращения расходов и отсева разработчики программного обеспечения и прикладных программ все чаще вынуждены оправдывать свое существование, причем с приведением весомых аргументов. Измерения позволяют сравнить производительность с индустриальными стандартами и наилучшими достижениями. Измерения позволяют документировать постепенные улучшения производительности и качества работы. Измерения позволяют продемонстрировать конкурентное преимущество внутреннего знания или внешней независимости. Руководителям бизнеса мало что говорит более красноречиво, чем цифры. Легко заявлять о простоте использования и повышенном удобстве программного обеспечения, однако количественные сравнения могут сделать эти утверждения более убедительными. Сокращение избыточности данных на 37 % и повышение производительности транзакций на 28 % может быть наиболее убедительным аргументом в поддержку нового продукта.

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

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

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

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

Пользовательские интерфейсы должны упорядочивать различные визуальные объекты на экранах и в диалоговых окнах. В хороших интерфей-сах организация визуальных объектов соответствует задачам, выполняемым пользователями. Как говорит специалист по пользовательским интерфейсам Алан Купер (Alan Cooper), экраны, окна и диалоговые элементы подобны разным комнатам (Cooper, 1995 [31]). Большинство людей предпочитает выполнить всю задачу в одной комнате, не переходя в другие в поисках необходимых инструментов и материалов. Они не делят работу на части, выполняемые в разных комнатах. Каждый раз, когда программное обеспечение вынуждает пользователей менять контекст взаимодействия, переключать экраны или переходить к другому диалоговому окну, ход их мыслей и работа прерываются. С каждым таким прерыванием пользователи не только работают все медленнее, но и делают больше ошибок. Хороший пользовательский интерфейс позволяет «пройти» пользовательскую ситуацию с меньшим количеством изменений контекста взаимодействия — с точки зрения общей сложности данной пользовательской ситуации. Поскольку в таких интерфейсах необходимые данные и функции объединены, эти интерфейсы не только проще применять, но и (в первую очередь) легче изучить.

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

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

Одной из привлекательных сторон математики является то, что все, кто правильно извлекает квадратный корень из 9, получают один и тот же результат. К сожалению, не все измерения программного обеспечения происходят таким же образом. Разные люди, выполняющие функциональную оценку, могут получить совершенно разные результаты. Для получения повторяющихся результатов необходимо тщательно разработать правила подсчета, а аналитики должны быть хорошо подготовлены и, желательно, сертифицированы.

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

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

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

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

Что делает тот или иной предмет легким для понимания? Что делает тот или иной предмет простым в использовании? Что превращает совокупность объектов — не отдельных, а представленных в определенном контексте — в набор рабочих инструментов? Возьмем объекты, взаимосвязанные внутри программного обеспечения, или визуальные объекты, отображаемые в графическом пользовательском интерфейсе. Что делает их понятными? Что делает их удобными?

Эти главные вопросы знакомы всякому, кто когда-нибудь пробовал готовить на чужой кухне. Чтобы разобраться, где что находится, нужно несколько минут, и все равно придется спрашивать, где находится нож для чистки овощей или дуршлаг. Тем не менее постепенно, по мере того как вы обнаруживаете разные наборы предметов, вы начинаете замечать определенную логику в их размещении, и вскоре все становится на свои места.

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

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

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

Некоторые из современных пользовательских интерфейсов имеют приблизительно такую же степень хаоса. Форматирование абзаца и строки располагается в меню Формат, форматирование колонтитулов — в меню Вид, а форматирование страницы — в меню Файл. Человеческий мозг обладает такой способностью к приспособлению, что со временем может изучить почти любую схему расположения, какой бы хаотичной она ни была. Однако разумные схемы делают процесс изучения быстрее, а приготовление пищи — и работу с текстом — намного проще.

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

С другой стороны, некоторые виды категоризации (например, по материалам, из которых изготовлены предметы) являются более разумными и практичными, чем может показаться на первый взгляд. Собирать предметы из стекла, или серебра, или фарфора в одном месте разумно и удобно — отчасти потому, что такие наборы зачастую объединяют предметы не только по схожести материала, но и по схожести функционального назначения. Другой эффективный способ группирования — собирать предметы, которые обычно применяются вместе. Например, в одном шкафу можно хранить инструменты для выпечки: миксерные чашки, миксеры, изме-рительные стаканы и т. п. Т amp;кжб могут быть и промежуточные варианты: вилки обычно хранятся рядом с другими приборами, но каждый столовый набор, состоящий из ножа, вилки и ложки, обычно не хранится в виде отдельных комплектов, разве что в кухнях на самолетах.

Таким образом, качество организации кухни или компоновки пользовательского интерфейса зависит от того, как объекты связаны друг с другом и с выполняемой задачей. Целостность задач (см. главу 47) является мерой качества интерфейсов. Она оценивает степень, с какой данный дизайн интерфейса объединяет в одном пространстве элементы, которые применяются вместе в обычной задаче — в одной пользовательской ситуации. В этой главе речь пойдет о визуальном сцеплении. Это мера, с помощью которой можно оценить качество организации интерфейса в показателях объединения связанных между собой объектов и разделения несвязанных.

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

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

Разумная объектно-ориентированная архитектура начинается с разумных объектных классов, построенных на устойчивой концептуальной основе, — с таких классов, которые объединяют в себе те методы и атрибуты, которые составляют связанное целое. Этот принцип связанности воплощается в одном из основных критериев качества программного обеспечения — сцеплении. Показатель сцепления известен давно. Впервые он был представлен как одно из ключевых понятий в структурном проектировании (Yourdon и Constantine, 1979 [70]), а затем стал одним из основных элементов современного проектирования программного обеспечения. Этот критерий применялся в различных видах, в том числе и в хорошо известном и широко обсуждаемом методе LCOM (Lack of Cohesion of Methods, метрика отсутствия сцепления в методах) (Chidamber и Kemerer, 1994 [7]; Henderson-Sellers, Constantine и Graham, 1996 [39]). Позднее критерий сцепления был доработан и расширен для того, чтобы лучше оценивать качество объектно-ориентированных проектов.

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

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

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

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

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

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

Другое дело смысловые группы, которые невидимы и неощутимы. К счастью, здесь может помочь хорошая модель предметной области. Предметные классы, их методы и атрибуты определяют один из аспектов смысловой организации, связанной с данным приложением. С помощью простого упорядочивания основных понятий, воплощенных в приложении, мы можем определить группы взаимосвязанных понятий. В основном (но не всецело) такие группы базируются на модели предметных классов.

После этого легко вычислить значение параметра визуального сцепления. Необходимо только рассмотреть каждую пару визуальных компонентов в каждой визуальной группе и подсчитать количество пар, в которых оба визуальных компонента связаны с одной и той же смысловой группой. Визуальное сцепление — это просто количество пар, в которых оба объекта связаны с одной смысловой группой. Обычно это количество выражается в процентах от всего количества возможных пар. Вычисление можно продолжить рекурсивно, чтобы учесть группы групп и оценить визуальное сцепление пользовательского интерфейса в желаемом масштабе (Constantine, 1996 [27]).

Теоретически критерий визуального сцепления может показаться превосходным, но вряд ли можно сказать, что на практике он является самоочевидным. К счастью, тема визуального сцепления была хорошо изучена. В одном из исследований (Constantine, 1996 [27]) были старательно сконструированы три различные версии квазистандартного диалогового окна печати. Все три версии имели реалистичный (с виду) дизайн и содержали одинаковое количество визуальных компонентов и визуальных групп. Все они были скомпонованы в соответствии с одинаковыми эстетическими принципами. Различалась только степень визуального сцепления. Один из проектов, так называемая «структурированная» версия, был высокоорганизованным, а его показатель визуального сцепления составлял 62 %. Другой проект, похожий на обычное диалоговое окно печати Windows, имел промежуточный показатель визуального сцепления, равный 42 %. Наибольшую сложность представлял внешне правдоподобный, но концептуально хаотичный вариант дизайна. Показатель визуального сцепления этой «беспорядочной» версии составлял 29 % несмотря на ее разумный внешний вид.

Для оценки проектов привлекались профессиональные разработчики и дизайнеры интерфейсов из Соединенных Штатов и Австралии. Каждый вариант дизайна рассматривался по различным сценариям задач. Критериями служили легкость понимания, изучения и применения. Если не говорить об одном или двух ляпах, которые случаются в любых реальных проектах, результаты во многом соответствовали ожидаемым. Варианты дизайна с большим значением показателя визуального сцепления были признаны более простыми в понимании, изучении и практическом применении. Такими они и были на самом деле.

Дело всего лишь в том, что хорошая визуальная организация имеет значение.

По материалам журнала Object Magazine, март 1997 г.

Примечания:

3

Число, выведенное в 1956 году психологом Джорджем Миллером, относится к возможности человека обрабатывать в кратковременной памяти только от пяти до девяти элементов.

4

После смерти (лат.).

39

Разумное основание, смысл (фр.)

40

Острый овечий сыр (ит.).

41

Going places with use cases for user interfaces

42

Из ничего (лат.)