46 Полезные ситуации

46

Полезные ситуации

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

Ряд ведущих специалистов-практиков также пришли к заключению, что пользовательские ситуации полезны при разработке пользовательских интерфейсов (см. главу 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 г.

Данный текст является ознакомительным фрагментом.