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

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

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

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

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

Концепция контекста

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

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

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

Жалкий прототип

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