Джефф Джонсон: Концептуальная модель – первый важный шаг в проектировании пользовательского интерфейса
Разработка концептуальной модели, ориентированной на конкретные задачи, до начала стадии проектирования пользовательского интерфейса позволяет создать приложение, которое является простым, последовательным, единообразным по внутреннему содержанию и необременительным с точки зрения излишних возможностей. Короче говоря, приложение получается более понятным для изучения и использования.
Определение концептуальной модели
В двух словах, концептуальная модель приложения – это модель, которую проектировщик хочет довести до понимания пользователя. Используя приложение и читая документацию к нему, пользователь выстраивает в голове модель функционирования системы. Хорошо, если модель, возникшая в голове пользователя, и модель, задуманная проектировщиком, совпадают. Шансы на это выше, если проектировщик предварительно создаст четкую концептуальную модель.
Концептуальная модель – это еще не пользовательский интерфейс. Она абстрактно (в терминах задач, нажатий на клавиши, манипуляций мышью или экранной графики) описывает, что именно пользователь должен делать с системой, и какие концепты ему необходимо знать.
Основная идея заключается в том, что тщательная разработка подробной концептуальной модели, на основе которой потом проектируется пользовательский интерфейс, делает приложение более простым и понятным для понимания. При этом необходимо, во-первых, сделать концептуальную модель максимально простой, с использованием минимального количества концептов для обеспечения необходимой функциональности. Во-вторых, надо максимально ориентировать концептуальную модель на конкретные задачи, то есть исключить или ограничить работу пользователя с концептами, не фигурирующими в данной области задач.
Важным компонентом концептуальной модели является анализ объектов и действий – список всех видимых пользователю объектов приложения и действий, которые пользователь может совершать над каждым объектом. В реализации системы могут присутствовать и другие объекты, но предполагается, что они будут невидимыми для пользователя. В частности, в состав концептуальной модели не могут входить чисто имплементационные объекты.
Объекты концептуальной модели приложения могут образовывать структурную иерархию, в которой дочерние блоки будут перенимать действия родительских. В зависимости от приложения объекты могут также образовывать иерархию включения, в которой некоторые объекты включают в себя другие. Использование двух этих типов иерархии в концептуальной модели значительно облегчает проектирование и разработку связного и понятного пользовательского интерфейса.
Подобный анализ объектов и действий помогает управлять реализацией системы, поскольку он указывает наиболее удобный вид иерархии объектов, а также методы работы, которые предусматривает каждый вид. Он также облегчает структуру команд приложения, т.к. позволяет разработчику увидеть, какие действия применимы к разным объектам и могут быть спроектированы как обобщенные. В свою очередь, это делает структуру команд более легкой для изучения пользователем: вместо того, чтобы осваивать большое количество объектно-ориентированных команд достаточно изучить несколько обобщенных, применяемых к разным объектам.
Пример: Бухгалтерские программы
К примеру, если бы наше приложение было программой, помогающей человеку управлять своим банковским счетом, концептуальная модель включала бы такие объекты, как проверки, счета, суммы денег и такие действия как размещение, отзыв, аннулирование, запрос баланса. Концептуальная модель должна исключать все объекты, не входящие в данную область задач (например, буферы, диалоговые окна, состояния, базы данных, строки), а также действия: нажатие клавиш, резервное копирование баз данных, очистка буфера обмена.
Поскольку компьютерная бухгалтерия иногда имеет свойства, не присущие бумажной, некоторые дополнительные функции могут попасть в концептуальную модель (например, такой объект как «шаблон операции» и такое действие как «определение шаблона»). Однако следует понимать, что каждый дополнительный концепт, добавленный в область задач, может создать две проблемы: 1) пользователи, знающие область задач, не распознают новый концепт, следовательно, его придется изучать дополнительно; 2) в геометрической прогрессии возрастет сложность приложения, поскольку каждый добавленный концепт начинает взаимодействовать с многочисленными другими концептами приложения. Вот почему следует строго ограничивать количество дополнительных концептов. Отсюда девиз разработчика пользовательского интерфейса: «Чем меньше, тем лучше».
После разработки концептуальной модели необходимо написать сценарий, описывающий работу пользователя с приложением. При этом нужно использовать лишь терминологию из области задач. К примеру, в случае с банковским приложением следовало бы написать следующий сценарий: «Джон использует программу для проверки баланса своего текущего счета. Он кладет деньги на текущий счет, а потом переводит их с текущего счета на сберегательный». Следует отметить, что этот сценарий ссылается только на объекты и действия области задач, а не на свойства пользовательского интерфейса.
В процессе разработки пользовательского интерфейса абстрактные концепты концептуальной модели переводятся в конкретные представления и действия пользователя. Для достижения оптимальных результатов пользовательский интерфейс проектируется после разработки концептуальной модели. Сценарии при этом могут быть переписаны на уровне пользовательского интерфейса.
Преимущества концептуальной модели
Разработка концептуальной модели как первая стадия проектирования пользовательского интерфейса имеет ряд преимуществ:
- Разделение области задач на объекты и действия позволяет определить действия, одинаковые для нескольких объектов. Впоследствии один и тот же пользовательский интерфейс может быть использован для работы с разными объектами. Например, если в хорошо продуманном приложении пользователь может использовать объекты А и Б, и он хочет создать объект А, но умеет создавать только Б, он сумеет создать и А, поскольку это действие происходит единообразно для двух данных объектов. (Как впрочем, и копирование, перемещение, удаление, редактирование, печать и т.д.) Это в свою очередь делает пользовательский интерфейс более простым и последовательным, а значит, и более удобным в изучении и использовании.
- Даже если не брать в расчет упрощение, вызванное существованием обобщенных действий, при проектировании пользовательской модели разработчики должны признать относительную важность концептов, их значимость для области задач (в противоположность технической области), типовую иерархию и иерархию включения объектов. Все эти явления в значительной степени облегчают проектирование пользовательского интерфейса.
- Концептуальная модель представляет собой начальный этап разработки терминологии программного продукта, то есть словаря терминов, которые будут использоваться для идентификации каждого объекта и действия, реализованного в программе. Это способствует сохранению устойчивости терминологии не только в самой программе, но и в сопутствующей документации. Недостатками программы, разработанной без такой терминологии, являются: 1) использование многочисленных терминов для определения одного концепта; 2) использование одного термина для определения разных концептов.
- Наконец, разработка концептуальной модели представляет собой первоначальный вид объектной модели (по крайней мере, для объектов, необходимых пользователю), которую разработчики могут в дальнейшем использовать при реализации программного обеспечения. Это особенно актуально если разработчик пишет программу на объектно-ориентированных языках, таких как Java или С++.
Риск отказа от использования концептуальной модели
Если программный продукт, приложение или оперативное обслуживание не строятся на базе связной, ориентированной на конкретные задачи концептуальной модели, пользователи описывают их как:
- Несвязные, произвольные, нелогичные, «не имеющие смысла»;
- Незавершенные, непродуманные, неразработанные, наспех скомпонованные, фрагментарные, «создающие впечатление старой фермерской усадьбы, комнаты которой в разные годы строились и декорировались разными владельцами»;
- Ненадежные, сложно запоминающиеся, «заставляющие заниматься гаданием»;
- Идиотские, состоящие из сухой технической терминологии, сконцентрированные на реализации, «предполагающие, что мы – компьютерные гении».
К примеру, компания имеет веб-сайт, который внешние сотрудники используют для регистрации рабочих часов. Базируется ли их пользовательский интерфейс на концептуальной модели, ориентированной на конкретную задачу? Судите сами:
- Для регистрации количества рабочих часов за неделю сотрудник нажимает «Создать запись» вместо того, чтобы нажать «Зарегистрировать часы» или «Зарегистрировать новую неделю». Почему именно «Создать запись»? Поскольку для сохранения новой информации в базе данных надо сделать в ней новую запись.
- Если пользователю удается зарегистрировать количество рабочих часов в неделю, система генерирует сообщение «Операция прошла успешно: новая строка добавлена». О чем это вообще?! Это сообщение не только не имеет никакого отношения к регистрируемым часам, но даже и не относится к функциональному термину программы «Создать запись».
- Если сотрудник вдруг забудет, что он уже регистрировал свои рабочие часы за определенную неделю и попытается сделать это еще раз, система выдаст сообщение об ошибке «ORA-00001: ограничение (CLEATS. PA_REPORT_HEADERS_U!) нарушено», информирующее пользователя, что какое-то внутреннее программное ограничение было им нарушено. И все это вместо понятной записи «Регистрация часов за эту неделю уже была внесена».
- Функция изменения пароля предполагает введение любой последовательности букв в качестве нового пароля, а буквенный логин наоборот неприемлем. Таким образом, паролем может служить комбинация, которую функция Логин сочтет ошибочной.
От редакции:
Джеф Джонсон на UserExperience ‘08
[изображение]
Normal 0
false false false
RU X-NONE X-NONE
MicrosoftInternetExplorer4
/* Style Definitions */ table.MsoNormalTable {mso-style-name:“Table Normal”; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:"Times New Roman";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}Джеф Джонсон (
Впервые опубликовано в «Юзабилити Бюллетень, выпуск 24».