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

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

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

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

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

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

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