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

44 Абстрактные объекты

44

Абстрактные объекты

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

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

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

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

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

Появление превосходных и мощных инструментов визуального проектирования, таких как 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 г.

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