Если вы похожи на меня, то у вас есть как минимум три пульта дистанционного управления: один для телевизора, один для DVD-плейера и еще один для видеомагнитофона. Конечно, можно купить какой-нибудь модный универсальный пульт, чтобы управлять всей бытовой техникой, но у вас нет лишних денег или вам не хочется тратить три месяца на то, чтобы научиться им пользоваться. Разве не лучше было бы, если бы эти три пульта дистанционного управления хотя бы воплощали в себе единую реализацию модели действий пользователя? Насколько проще было бы с ними работать, если бы кнопки однотипных действий были расположены на тех же местах, так же выглядели и воспринимались? Хорошо было бы также, если бы все они работали от батареек одного размера, что существенно упростило бы обслуживание. Затем, наконец, придет день, когда вы купите тот TiVo, который давно вам приглянулся. Если его пульт дистанционного управления будет принадлежать к семейству той же модели действий пользователя, что и другие три пульта, жизнь покажется вам безоблачной.

Жизнь может быть прекрасной и в рабочем кабинете, благодаря приложениям, которые используют унифицированную модель действий пользователя. Переключаясь с Microsoft® Word® на Excel®, а затем на PowerPoint®, вы используете унифицированную модель действий пользователя Microsoft Office® . Для каждого приложения характерен уникальный набор функций, но общие действия и реакции выполняются одним способом. Во всех приложениях Office вы обращаетесь к функциям через главное меню, состоящее из меню File (Файл) | Edit (Правка) | View (Вид)| Insert (Вставка) | Format (Форматирование)| Tools (Сервис)| Window (Окно) | Help (Справка). Изучив одно приложение, вы получаете основные навыки работы, которые можно применить и к другому приложению. Вы тратите все меньше времени на то, чтобы научиться работать с каждым новым приложением, к которому вы обращаетесь, и все больше времени у вас остается на то, чтобы изучить его уникальные функции.

Большая счастливая семья

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

В глобальной семье есть несколько более тесных семейных групп - групп приложений, у которых еще больше общего. Web-приложения особенно пригодны для унификации по одной или более из множества граней модели действий пользователя, в том числе, по структуре сайта, структуре страницы, структуре элементов и внешнему виду (см. рисунок 1).

• Структура сайта: Архитектура информационных ресурсов приложения, которая определяет подачу страниц;
• Структура страниц: Макет страницы приложения, который определяет разделы страницы и информации, а также функции, которые соответствуют каждому разделу;
• Структура элемента: Такие элементы интерфейса пользователя, как вкладки, заголовки и таблицы, которые определяют взаимосвязи, дизайн и структуру сайта;
• Внешний вид: Фирменное оформление приложения, в том числе, логотипы, семейства шрифтов и цветовая гамма.

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

Так что дает унифицированная модель действий пользователя на web-сайте IBM лично вам как пользователю? Вы можете пользоваться сайтом с большей легкостью, поскольку познакомившись с одной страницей, сможете работать со всеми 10 000 страниц. Вы знаете, как перемещаться по сайту, где лучше всего искать конкретную информацию и какие виды информации, скорее всего, будут доступны. Поскольку все выглядит единообразным, вы подсознательно делаете вывод, что взаимосвязи, которые вы изучили в одном разделе, будут применяться на всем сайте.

По существу, познавательная нагрузка, необходимая для использования сайта, уменьшается, следовательно, у пользователя остаются познавательные ресурсы, которые можно использовать для решения задачи. Вашему мозгу больше не нужно уравинвать нагрузку на то, чтобы 1) понять, как пользоваться web-сайтом IBM и 2) больше узнать о методиках Rational®, унифицированная модель действий пользователя этого web-сайта позволит вам сконцентрироваться на последнем.

В начало

Результирующая формула удобства и простоты использования (usability)

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

Общая результирующая практичность нескольких систем по отношению к индивидуальной практичности способна вызвать удивление. В таблице 1 показаны возможные сценарии по шкале от 1 до 10 (10 - лучший показатель).

Таблица 1. Результирующая практичность

Предположим, например, что сотруднице, занимающейся гарантийным обслуживанием, необходимо обратиться к приложению 1 за информацией о клиенте. Ей нужно также обратиться за информацией о претензии к приложению 2. Чтобы обработать заявление на гарантийное обслуживание, она должна сначала воспользоваться приложением 1, чтобы найти клиента и сгенерировать номер заявления, а затем использовать приложение 2, чтобы получить доступ к сгенерированному номеру заявления, ввести информацию о заявлении и передать заявление для дальнейшей обработки. Если оба приложения имеют унифицированную модель образа действий пользователя (UUE), то сотрудница сможет переходить между двумя приложениями гораздо проще, чем в том случае, если бы они не имели общего механизма. При работе с этими двумя разными приложениями она не должна ощущать разницы в работе.

В начало

Осмотрительность в прменении унифицированной модели действий пользователя UUE

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

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

Применяя общие стандарты к нескольким приложениям, вы эффективно создаете сингулярную зависимость. Прекрасно, если все стандарты хорошо разработаны. Но что получится, если представить себе, что один из стандартов разработан неадекватно? Вы будете должны значительно изменить каждое приложение, к которому он будет применяться. Существуют эффективные способы разработки приложений, позволяющие легко выполнить откат некоторых изменений, в том числе, каскадные таблицы стилей (Cascading Style Sheets, CSS) и модульные фрагменты кода. Однако вы не можете реализовать такие изменения, как перепроектирование архитектуры информации, путем нажатия одной кнопки. Очень важно определить хорошо продуманные стандарты UUE, потому что их можно внедрить во многие приложения.

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

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

В начало

Стандартизованная, но модульная

Внедрить одну модель UUE во множество приложений - это все равно, что положить все яйца в одну корзину. Как можно быстро заменить корзину, не разбив яйца? Ответ - модульное проектирование. Вы можете эффективно отделить контент (яйца) от его представления (корзина) и независимо управлять представлением через комбинацию связанных файлов шаблонов, фрагментов, CSS и JavaScript. Модульное проектирование позволяет полностью изменить внешний вид, структуру и даже аспекты поведения взаимосвязей, изменив небольшое количество связанных файлов.

Наблюдая общие закономерности в web-приложении, вы сможете обнаружить те части приложения, которые можно спроектировать в виде модулей. Распространенный набор шаблонов для большинства web-приложений связан с функциями создания, чтения, обновления, удаления (функции CRUD). Например, web-приложение может предоставлять доступ ко многим объектам, таким как клиенты, счета, продукты и обзоры. Для каждого объекта появляется общий шаблон действий - пользователь выполняет поиск, выделяет объект, просматривает страницу с подробным описанием и выполняет функции CRUD над объектом.

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

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

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

Язык программирования Java™ обслуживает многие механизмы создания шаблона с открытым исходным кодом, в том числе TeaServlet, WebMacro, FreeMarker и Velocity (см. раздел Ресурсы). Дополнительное преимущество использования шаблонов с этими инструментами состоит в том, что можно добиться разделения труда между üтехническим персоналом с большей или меньшей квалификацией, разделив контент и его представление.

Давайте внимательнее посмотрим, скажем, на Velocity, чтобы понять, как можно разделить проект на модули и отделить контент от структурного представления. При помощи языка шаблонов Velocity Template Language (VTL) можно создавать ссылки (references) для контекстного доступа к объектам. Они обращаются к данным. Один и тот же набор ссылок можно использовать в нескольких шаблонах. Используя директивы (directives), которые предназначены для управления и действий, можно использовать один шаблон и в зависимости от контекста интерпретировать конкретные ссылки

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

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

Наконец, в Velocity имеются макросы Velocimacros, которые позволяют определить фрагмент кода VTL и передать ему параметры. Их можно расценивать как мини-шаблоны. Например, можно определить макрос Velocimacro структуры таблицы и передать ей класс CSS, идентификатор и источник данных:

 #macro( dataTable1 $cssClass $id $memberlist )
    <table class=$cssClass id=$id >
    #foreach( $member in $memberlist)
<tr><td>
$member
</td></tr>
    #end
    </table>
  #end

Если дизайнеру нужно включить таблицу в шаблон страницы Velocity, он может просто ввести в командной строке следующее выражение с соответствующими параметрами:

#dataTable1 ( "gridLayout" "fanbaseInfo" $fanclub )

Предположим, что спустя месяц после этого, все такие таблицы должны заканчиваться пустой строкой. Вам придется изменить только описание макроса Velocimacro, и изменение затронет все экземпляры:

 #macro( dataTable1 $cssClass $id $memberlist)
    <table class=$cssClass id=$id >
    #foreach( $member in $memberlist)
<tr><td>
$choice
</td></tr>
    #end
<tr><td>&nbsp;</td></tr>
    </table>
  #end 

Шаблоны связывают закономерности структуры страниц на высоком уровне, а CSS может решать элементарные проблемы представления модульным способом. Вы можете описать стили для любых элементов, от шрифта страницы до рамки таблицы. Определив класс CSS в связанном файле и применив этот класс к элементу в HTML, вы сможете в дальнейшем разъединить контент и представление. В макете, который полностью построен на CSS, можно просто заменить таблицу стилей и изменить представление для традиционного ПК на представление для сотового телефона. Аналогично можно изменить весь фирменный стиль web-приложения. Попробуйте поработать с программой CSS Zen Garden, чтобы увидеть ее в действии (см. раздел Ресурсы).

Наконец, можно придать модульный характер не только способу представления информации, но и интерактивным действиям. Интерактивные элементы и действия, такие как ползунки, календари, автозаполнение и "drag and drop" доступны для использования на многих ресурсах, в том числе, Yahoo!, Google, Dojo, Rico и script.aculo.us (см. раздел Ресурсы). Благодаря распространению Asynchronous JavaScript с XML (Ajax), вы можете добиться, чтобы многие из этих утилит независимо взаимодействовали с данными, не нуждаясь в обновлении всей страницы.

Чтобы убедиться в эффективности модульных действий в разработке стандартизованной модели образа действий пользователя (UUE), рассмотрим знакомые всем функции просмотра нескольких записей. Большинство приложений выполняет эту задачу, отображая на странице фиксированное количество записей и номера страниц, которые представляют собой ссылку на каждую такую страницу. Безусловно, вы можете реализовать это при помощи шаблона для страницы результатов и фрагмента кода для механизма деления на страницы. Но в различных приложениях могут возникнуть вопросы. Сколько результатов следует отображать на одной странице? Нужны ли номера страниц и ссылки вперед/назад? Следует ли использовать текстовое поле, чтобы пользователи могли перескакивать на нужный номер страницы? Если да, то следует ли предусмотреть кнопку Go! или достаточно предположить, что пользователи нажмут клавишу Enter?

Обо всем этом может позаботиться виджет Ajax. Благодаря тому, что все результаты отображаются в ограниченной области окна, пользователи могут просмотреть все записи при помощи обычной прокрутки. Функция Ajax показывает только записи, чтобы не нужно было разбирать все на месте. Вы легко можете использовать этот виджет во многих приложениях. Поскольку все приложения могут использовать один исходный код через ссылку на исходный файл JavaScript, можно легко провести любую настройку их поведения. Это действие можно увидеть у Rico (см. раздел Ресурсы).

В начало

Заключение

Мы живем в мире, которым правят стандарты. Красный сигнал означает "стоп", зеленый - "вперед". Адрес состоит из номера дома, названия улицы, города, государства и почтового индекса. Стандарты обеспечивают зависимую от контекста инфраструктуру, которая позволяет с большей легкостью обрабатывать информацию. То же самое они могут делать в отношении web-приложений. Но поскольку стандарты служат исходным ядром, которое распределяется по многим экземплярам, пользователь может столкнуться с проблемами, когда придет время обновить стандарт. К счастью, для web-приложений можно легко приспособить эти глобальные изменения при помощи соответствующего планирования и реализации шаблонов, CSS, JavaScript и действий Ajax.

Ресурсы

Научиться

• Оригинал статьи Unify your Web apps with UUE;
  
  
• Раздел дизайна web-сайта IBM Ease of Use (Простота применения): ознакомьтесь с этими прекрасными исходными рекомендациями по разработке интерфейсов пользователей;
  
  
• Client and server-side templating with Velocity (Создание шаблонов на стороне клиента и сервера при помощи Velocity) (Шин Ли (Sing Li), сайт developerWorks, февраль 2004 г.): получите дополнительную информацию о разработке шаблонов при помощи утилиты Velocity и о том, как интегрировать ее средства обработки шаблонов в ваше клиентское автономное приложение, серверное web-приложение или web-сервис;
  
  
• Build apps using Asynchronous JavaScript with XML (Ajax) (Создание приложений при помощи технологии Asynchronous JavaScript with XML (Ajax)(Навин Балани (Naveen Balani) и Раджив Хатхи (Rajeev Hathi), сайт developerWorks, ноябрь 2005 г.): В этом практическом руководстве мы создадим динамичную, асинхронную web-среду при помощи приложений на основе технологии AJAX без обновления страницы полностью, дополненную механизмом проверки корректности в реальном времени;
  
  
• Zen Garden: изучите и узнайте о преимуществах разработки CSS;
  
  
• TeaServlet:: познакомьтесь с механизмом создания шаблонов, который работает с языком шаблонов Tea;
  
  
• WebMacro: дополнительная информация о системе создания шаблонов на Java;
  
  
• Dojo: узнайте об инструменте JavaScript с открытым исходным кодом;
  
  
• Rico: получите дополнительную информацию о библиотеке JavaScript с открытым исходным кодом;
  
  
• script.aculo.us: познакомьтесь с библиотеками интерфейса пользователя для разных браузеров JavaScript;
  
  
• Раздел web-зона сайта developerWorks: повысьте свою квалификацию при помощи информации о web-архитектуре и разработке, будущих файлах для загрузки и продуктах, проектах с открытым исходным кодом, технических библиотеках, курсах и уведомлениях о событиях;
  
  
• Технические события и новые материалы на web-сайте developerWorks: оставайтесь в курсе событий благодаря техническим конференциям, которые организованы в стиле дружеского общения и способствуют быстрому получению знаний, а также повышают качество и результаты самых сложных проектов программного обеспечения пользователей.
  
  

Получить продукты и технологии

• Пробные продукты IBM для загрузки: cоздайте свой проект разработки с помощью пробного ПО IBM, которое можно загрузить непосредственно с сайта developerWorks.
  
  

Обсудить

• Примите участие в обсуждении материала на форуме.
  
  
• Примите участие в форуме по XML;
  
  
• Блоги developerWorks: присоединяйтесь к сообществу developerWorks.
  
  

Об авторе

Оценить эту статью

Комментарии

В начало

Содержание

• Большая счастливая семья
• Результирующая формула удобства и простоты использования (usability)
• Осмотрительность в прменении унифицированной модели действий пользователя UUE
• Стандартизованная, но модульная
• Заключение
• Ресурсы
• Об авторе
• Комментарии