Шаблоны проектирования веб-приложений Вора Паван

Введение

Все чаще компьютерные приложения разрабатываются на основе веб-технологий, и к ним можно получить доступ с помощью веббраузеров (например, Internet Explorer, Firefox, Safari и Opera). Обычно такие приложения называются веб-приложениями, или размещаемыми приложениями (hosted applications) – приложениями, в основе которых лежит модель программного обеспечения как услуги (SaaS)[1] или облачные вычисления (cloud computing)[2]. Эти веб-приложения отличаются от более традиционных веб-сайтов в том смысле, что их предназначение – помочь пользователям в выполнении таких задач, как отправка электронных писем, бронирование авиабилетов, поиск домов, оплата счетов, перевод денег, покупка продуктов, рассылка приглашений и т. п. (рис. 1.1–1.4). Веб-сайты, напротив, ориентированы на контент и разрабатываются для поиска и ознакомления с достаточно статической информацией (рис. 1.5).

Рис. 1.1. Пользователи могут настроить свою электронную почту как в этом примере с Yahoo! Mail, и то же самое можно сделать и в таких клиентских приложениях, как Microsoft Outlook, Mozilla Thunderbird и Eudora

Рис. 1.2. Пользователи могут искать варианты туристических путевок и осуществлять бронирование билетов с помощью веб-приложений, таких как Expedia

Рис. 1.3. Пользователи могут найти продающийся дом, узнать его стоимость и увидеть, какие еще дома выставлены на продажу в этом районе. Все это можно сделать на таких сайтах, как Zillow.com

Рис. 1.4. Пользователи могут совершать покупки на таких сайтах, как Buy.com

Рис. 1.5. Ознакомиться со статической информацией о компании Ultragrain и ее товарах можно на сайте этой компании (www.ultragram.com)

Достоинства веб-приложений

Популярность веб-приложений объясняется тем, что они обладают рядом достоинств. Эти достоинства описаны в данном разделе (Baxley, 2003; Turnbull, 2006).

В большинстве случаев единственный вид программного обеспечения, который необходим для того, чтобы получить доступ и пользоваться веб-приложениями, – это браузер, такой как Internet Explorer, Firefox, Safari и Opera. Чтобы пользоваться веб-приложениями, пользователям не нужно скачивать и устанавливать дополнительное программное обеспечение, хотя в некоторых случаях все же приходится загружать вспомогательные приложения или плагины, такие как Adobe Flash, Java, Microsoft Silverlight и т. д., чтобы получить доступ ко всем частям веб-приложения.

Более того, так как и приложение, и информация хранятся на серверах поставщика, а не на пользовательских компьютерах, пользователи могут получить доступ к веб-приложениям из практически любого места, где есть подключенный к Интернету компьютер, на котором установлен браузер. Благодаря удаленному хранению данных, пользователи могут делиться информацией и сотрудничать друг с другом; например, они могут совместно пользоваться закладками приложений, такими как Delicious (www.delicious.com) и Furl (www.furl.net), и удаленно совместно работать над одними и теми же документами, применяя повышающие эффективность работы приложения, такие как Google Docs and Spreadsheets (docs.google.com) и Zoho (www.zoho.com).

Веб-приложения также популярны среди бизнесменов и разработчиков программного обеспечения, поскольку их можно дорабатывать, обновлять и отлаживать удаленно, при этом пользователям не приходится их устанавливать (или переустанавливать). С этим связано очередное достоинство веб-приложений – их поведение не зависит от операционной системы, установленной на компьютере пользователя. Один и тот же вариант приложения может использоваться практически любым пользователем, вместо того, чтобы создавать отдельные версии приложения для Windows, Macintosh OS X, GNU/Linux и других операционных систем.

Развитие и распространение Интернета (от 16 миллионов пользователей в декабре 1995 года до почти 1,5 миллиардов пользователей в июне 2008 года согласно данным сайта Internet World Stats www.internetworldstats.com) способствовало тому, что взаимодействие в сети Интернет стало привычным для огромного количества пользователей. Большинство пользователей Интернета сейчас знакомы с терминологией веб-браузеров, например, домашняя страница, назад, вперед, избранное, гиперссылки, кнопки подтверждения и т. д. Принимая во внимание все это и учитывая тот факт, что для пользования веб-приложениями не нужны замысловатые установки, осталось очень мало преград для их использования (или, по крайней мере, для того, чтобы хотя бы с ними ознакомиться). Более того, многими популярными веб-приложениями теперь можно пользоваться бесплатно или бесплатно с ними ознакомиться.

Раньше существенным препятствием для развития веб-приложений являлась ненадежность связности сети и очень нестабильная поддержка веб-стандартов – а именно, HTML, CSS и JavaScript – в веббраузерах. Теперь ситуация изменилась. Поддержка веб-стандартов становится все существеннее, а их несовместимость с браузерами, доводившая раньше разработчиков до отчаяния, уменьшается. Кроме того, связность сети и широкополосный доступ становятся все надежнее, все распространеннее и дешевле в использовании. Согласно результатам исследования Website Optimization, процент домов в США, имеющих широкополосный доступ в Интернет, в марте 2008 года вырос до 57 %, а для активных пользователей сети Интернет он составил 90 % (www.websiteoptimization.com/bw/0807/). Это послужило надежной основой для появления визуальных средств разработки и инфраструктур, способствующих развитию веб-приложений.

Трудности в разработке интерфейсов для веб-приложений

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

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

Загрузка каждой новой страницы или обновление страницы сопровождается приемлемыми задержками, связанными с необходимостью установить соединение, отправкой ответа на запрос, получением страницы и перезагрузкой страницы в браузере. Все это может показаться пользователям веб-приложений довольно скачкообразным и нестабильным. Например, пользователю, который просматривает данные, структурированные в виде иерархического дерева, возможно, придется ждать после каждого клика, пока узел отсчета будет дополнен или удален на перезагружаемой странице и можно будет увидеть изменения. Хотя эта проблема в большей степени связана с применением технологий создания сценариев, такими как JavaScript и богатые веб-приложения (Rich Internet Applications, см. главу 8), с ней часто сталкиваются пользователи при работе с большинством веб-приложений.

В текущей версии стандарта HTML (версия 4.01) поддержка средств управления ограничивается текстовыми окнами, зависимыми клавишами, флажками, раскрывающимися списками и командными или управляющими кнопками. Эта версия не поддерживает сложные взаимодействия, типичные для клиентских приложений, таких как регуляторы прокрутки, календари, экспертные системы, закладки, панели инструментов, перетаскивание, плавающие панели, диалоговые окна, контекстно-зависимые меню и т. д., которые встречаются даже в базовых клиентских приложениях. Хотя подобные элементы управления можно разработать с помощью сценариев JavaScript и каскадных таблиц стилей (Cascading Style Sheets, CSS), недостаток изначальной поддержки привел к появлению разнообразных способов их реализации, обладающих неполным функционалом.

Как базовая технологическая архитектура Интернета, так и ограниченный набор доступных элементов управления затрудняют создание таких способов взаимодействия пользователя с веб-приложением, которые были бы на уровне со способами взаимодействия в клиентских приложениях. Кроме этого поскольку большинство веб-приложений разработано так, чтобы с ними можно было работать через браузер, способы взаимодействия и оформление нельзя спроектировать так, чтобы они подходили ко всем операционным системам; например, закладки в интерфейсе Macintosh OS X Aqua внешне выглядят совершенно иначе, нежели закладки в интерфейсе Windows Vista (рис. 1.6).

(а)

(б)

Рис. 1.6. Закладки в интерфейсе Macintosh OS X Aqua (a) и в интерфейсе

Хотя сравнительно свободная среда проектирования Интернета предоставляет разработчикам простор для творчества, она также приводит к многообразию и неоднородности пользовательских интерфейсов и способов, что во многих случаях вызывает определенные трудности для пользователей. Сложности связаны с тем, что пользователи сталкиваются с различными вариантами интерфейсов и способов взаимодействия, каждый из которых обладает собственной терминологией для названия объектов, действий и изображений, объединенных в одном и том же приложении (см. Тидвелл, 2008). На рисунке 1.7 показан пример изменения названия закладки в Zoho Notes (веб-приложение для записей, похожее на Microsoft OneNote) и Zoho Sheet (веб-приложение для работы с таблицами, похожее на Microsoft Excel). Чтобы изменить название закладки в Zoho Notes, пользователи должны дважды щелкнуть по названию закладки, после чего появится диалоговое окно Rename (Переименовать). Чтобы изменить название закладки в Zoho Sheet, пользователи должны щелкнуть правой кнопкой мыши по закладке и выбрать пункт Rename (Переименовать), который откроет всплывающее окно, позволяющее пользователю сменить имя; при этом с помощью двойного щелчка мыши можно выделить текст и заменить его своим.

(a)

(б)

Рис. 1.7. Два различных способа взаимодействия пользователя с системой для смены названия закладки в Zoho Notes (a) и в Zoho Sheet (б)

Примечание

HTML5 будет поддерживать дополнительные элементы формы, которые на данный момент входят в спецификацию Web Forms 2.0, разработанную консорциумом World Wide Web Consortium (W3C) (www.w3.org/TR/web-forms-2/). Эта новая версия предоставит дополнительные элементы управления (например, элемент <datalist> для создания комбинированных окон и элемент <output> для того, чтобы показывать значения, производные от других элементов управления), а также в ней появятся расширения для существующих элементов управления (например, <inputtype="date"/>, <input type="email"/> и др.), что немного облегчит разработку вебприложений. Браузер Opera (версия 9 и выше) сегодня поддерживает Web Forms 2.0 и предоставляет хорошую базу для разработки интерактивных прототипов.

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

Однако применить эти принципы для разработки удобных в использовании веб-приложений не так уж и просто. Принципы разработки обладают ограниченной эффективностью, поскольку они часто предлагают высокоуровневые принципы (например, сделать видимым системный статус; использовать распознавание вместо повторного вызова; предотвращение ошибок) или предоставляют очень узкоспециализированные инструкции (например, выровнять заголовки таблиц относительно выравнивания данных в таблице). С другой стороны, руководства по стилю оформления фокусируются на создании имиджа и аспектах визуального проектирования и обычно предназначены для определенной платформы (например, Macintosh OS X Aqua и Windows Vista) или для приложений, разработанных определенной корпорацией (например, руководство по графическому пользовательскому интерфейсу браузера от компании Oracle: «Oracle Browser Look and Feel [BLAF] Guidelines», 2004), и вовсе необязательно предоставляют подробные инструкции для разработки удобных средств взаимодействия.

Руководства по разработке и стилю оформления обычно довольно объемные и сложные в использовании, поскольку для реализации одного способа взаимодействия обычно необходимо, чтобы разработчики пользовательского интерфейса ознакомились с несколькими пунктами документа. Например, руководство по проектированию пользовательских интерфейсов от компании Apple: «Human Interface Guidelines» – документ объемом почти в 400 страниц, и чтобы создать диалоговое окно с элементами управления, разработчику пришлось бы ознакомиться с несколькими пунктами части номер 3, называющейся: «Part III: The Aqua Interface» (рис. 1.8), которая содержит примерно 250 страниц, посвященных этому вопросу.

Рис. 1.8. Раздел «Часть III: Аквавзаимодействие» в «Руководстве по проектированию пользовательских интерфейсов» от компании Apple составляет примерно 250 из 400 страниц документа

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

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

Шаблоны проектирования

Упоминание о шаблонах впервые появилось применительно к архитектуре в работах Кристофера Александра и его коллег: «Язык шаблонов» (Alexander et al., 1977) и «Извечный путь строительства» (Alexander, 1979). Они объясняют суть шаблонов следующим образом:

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

Alexander et al., 1977, стр. x

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

В последнее время шаблоны все чаще стали применяться разработчиками пользовательских интерфейсов и программного обеспечения[3], которых привлекают следующие преимущества.

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

• Усовершенствованный процесс проектирования. Определение шаблонов проекта и их каталогизация может помочь разработчикам пользовательского интерфейса увеличить производительность, сократив время, которое тратится на «изобретение велосипеда». Более того, если элементы пользовательского интерфейса используются в качестве шаблонов и представлены в виде библиотеки шаблонов проектов (см. главу 13), проекты можно разрабатывать, тестировать и дорабатывать довольно быстро, а также можно сократить цикл выпуска.

• Возможность многократного применения и согласованные интерфейсы. Формирование библиотеки допускающих многократное применение элементов пользовательского интерфейса также может способствовать разработке согласованных интерфейсов приложений. Особенно это удобно для больших корпораций, в которых много рассредоточенных проектных групп, где решения для одной и той же проблемы могут применяться различными проектными группами, что приводит к несогласованности интерфейсов, разработанных одной и той же компанией. Благодаря каталогизации и обмену информацией о шаблонах проекта, группы могут повысить согласованность, предсказуемость, простоту и удобство использования своих проектов (Leacock et al., 2005) и могут сформировать корпоративную память об опыте проектирования (Borchers, 2001).

• Общий, совместно используемый язык. Шаблоны помогают поддерживать и совершенствовать обмен информацией между членами команды с различной специализацией благодаря развитию общего языка или терминологии при объяснении и обсуждении проектных решений (Borchers, 2001; Erickson, 2000). Это очень важно, поскольку проектировщики пользовательского интерфейса часто работают в междисциплинарных группах, в состав которых входят также разработчики, специалисты в прикладных областях и пользователи или представители пользователей, а в этих группах обычно отсутствует общая терминология для обмена идеями и мнениями по поводу проекта.

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

• Удобные в применении веб-приложения. В конечном итоге, поскольку шаблоны основаны на успешном опыте применения, их использование может сделать веб-приложения удобными в применении, потому как способы взаимодействия, лежащие в основе шаблонов, знакомы пользователям.

Документирование шаблонов

Важно, чтобы шаблоны были документально оформлены, чтобы из этой документации можно было понять, что они собой представляют, почему они работают и как они должны применяться для решения проблемы проектирования, чтобы получить вышеупомянутые преимущества. Однако интересен тот факт, что не существует какого-либо «шаблона» для документирования шаблонов (см. главу 13). Авторы шаблонов применяют различные подходы, начиная с тех, кто основывается на более описательном повествовании в духе Кристофера Александра (Borchers, 2001; Graham, 2003; van Duyne et al., 2002, 2006), заканчивая теми, кто следует более структурированному, хотя и минималистическому, подходу (Laasko, 2003); Тидвелл, 2008; www.welie.com) [4].

В этой книге представлен довольно краткий обзор шаблонов. В частности, в описание каждого шаблона входит:

• Название шаблона. Короткий заголовок, описывающий проектное решение. По примеру других наборов шаблонов названия шаблонов написаны ЗАГЛАВНЫМИ БУКВАМИ, чтобы они выделялись среди остального текста. В тексте приведены названия шаблонов на английском языке, а в конце книги вы найдете список всех шаблонов на английском языке и смысловой перевод в скобках (русские названия шаблонов не утверждены).

• Проблема. Краткое описание проблем(ы) проектирования, которую решает шаблон, и описание сопутствующих трудностей проектирования и альтернативных вариантов, с которыми сталкиваются проектировщики пользовательских интерфейсов.

• Решение. Ключевое проектное решение проблемы. Это краткое описание решения (т. е. шаблона), которое сопровождается примером (т. е. наглядным изображением), иллюстрирующим его применение для веб-приложения.

• Зачем. Логическое обоснование эффективности проекторного решения.

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

• Связанные шаблоны проектирования. Поскольку очень часто происходит так, что несколько шаблонов вместе применяются для создания удобного проектного решения, в этом разделе указаны смежные шаблоны, которые могут пригодиться проектировщикам либо потому, что они применяются совместно с данным шаблоном, либо потому, что они влияют на применение данного шаблона.

Структурирование шаблонов в этой книге

Шаблоны в этой книге структурированы по главам следующим образом.

Глава 2: Формы. Формы являются отличительной чертой вебприложений. Именно с помощью элементов формы, таких как текстовые окна, раскрывающиеся меню, зависимые кнопки, флажки и прочие, пользователи вводят информацию и взаимодействуют с веб-приложениями. В этой главе рассказывается о шаблонах, связанных с разработкой форм для веб-приложений и обеспечивающих заполнение формы таким образом, чтобы оно не было трудоемким занятием, а также чтобы эти формы помогали пользователям достигать своих целей. Это такие шаблоны, как CLEAR BENEFITS, SHORT FORMS, LOGICAL GROUPING, LABEL ALIGNMENT, REQUIRED FIELD INDICATORS, SMART DEFAULTS, FORGIVING FORMAT, KEYBOARD NAVIGATION, INPUT HINTS/ PROMPTS, ACTION BUTTONS и ERROR MESSAGES.

Глава 3: Аутентификация пользователя. Веб-приложения осуществляют взаимно однозначное взаимодействие с пользователями и сохраняют информацию о конкретных пользователях. Для этого требуется, чтобы пользователи создавали учетную запись и получали к ней доступ с помощью уникальных учетных данных. В этой главе описываются шаблоны проектов, имеющие отношение к доступу и завершению работы с веб-приложениями, включая REGISTRATION, CAPTCHA, LOG IN, LOG OUT, AUTOMATIC LOGOUT и FORGOT USERNAME/ PASSWORD.

Глава 4: Главная страница приложения. Важный для проектировщиков вопрос – что пользователь увидит или на какую страницу будет направлен, когда он входит в свою учетную запись в приложении? В этой главе описаны шаблоны, которыми могут воспользоваться проектировщики при направлении посетителей на эту «главную» страницу приложения, сюда относятся INBOX, CONTROL PANEL, DASHBOARD, PORTAL, PERSONALIZATION, CUSTOMIZATION и BLANK SLATE.

Глава 5: Навигация. Навигация – это то, как пользователи работают с веб-приложением. Если процесс навигации спроектирован удачно, он становится прозрачным (т. е. незаметным для пользователя) и пользователи могут быстро осуществить свои задачи, не прибегая к ненужному поиску с возвратом. В центре внимания этой главы – шаблоны проектирования навигационных систем, такие как PRIMARY NAVIGATION, SECONDARY NAVIGATION, UTILITY NAVIGATION, FACETED NAVIGATION, SUPPLEMENTARY NAVIGATION, TAG CLOUDS, BREADCRUMBS и WIZARDS.

Глава 6: Поиск и фильтрация. Для большинства веб-приложений получение информации только с помощью навигационных систем может быть затруднительным и нанести ущерб удобству и простоте использования. По этой причине информация в веб-приложении доступна для поиска, чтобы пользователи могли быстро и эффективно найти то, что им нужно. Кроме тех случаев, когда критерии поиска очень особые, пользователи, скорее всего, получат большое количество результатов. Проектировщики должны предоставлять пользователям возможность с помощью механизмов фильтрации сократить список результатов до удобного в обработке набора вариантов. В этой главе рассказывается о шаблонах проектирования, связанных с поиском и фильтрацией информации в веб-приложениях, сюда относится SIMPLE SEARCH, PARAMETRIC SEARCH, ADVANCED SEARCH, SEARCH TIPS, SEARCH RESULTS, SORTING, PAGINATION, CONTINUOUS SCROLLING, FILTERING, FACETED SEARCH и SAVED SEARCHES.

Глава 7: Списки. Списки применяются для того, чтобы представить пользователям несколько элементов. Способ этого представления может быть различным, в зависимости от того, какие именно элементы должны быть представлены. В этой главе рассказывается о шаблонах проектирования для различных типов списков, а именно SIMPLE LIST, TABULAR LIST, HIERARCHICAL LIST, EVENT LIST, TIMELINES, IMAGE LIST/ GRID, MAPS, LIST ACTIONS и LIST UTILITY FUNCTIONS.

Глава 8: Богатые веб-приложения. Богатые веб-приложения (RIA) предоставляют такую же ответную реакцию и интерактивность, что и настольные клиентские приложения, поскольку пользователям не приходится ждать, пока основные данные на странице обновляются и пока вносятся изменения в оформление; по этой причине результаты их действий можно увидеть немедленно. В этой главе рассказывается о часто применяющихся шаблонах проектирования для богатых веб-приложений, к которым относятся RICH-TEXT EDITOR, RICH FORM, AUTOSUGGEST/ AUTOCOMPLETION, EDIT-IN-PLACE, OVERVIEW-PLUS-DETAIL, DYNAMIC QUERYING, LIVE PREVIEW, DRAG-AND-DROP, SLIDER, ANIMATIONS/TRANSITIONS, DELAY/PROGRESS INDICATOR, SPOTLIGHT/YELLOW-FADE и CAROUSEL

Глава 9: Социальные приложения. Современная тенденция в сфере веб-приложений – это разработка социальных приложений, которые не просто способствуют тому, чтобы пользователи вносили свой вклад и выкладывали свой контент (например, фотографии, видео, закладки и т. д.), но также развивают взаимодействие и помогают создавать сообщества. В этой главе рассказывается о шаблонах проектирования, которые были созданы на основе подобных социальных приложений, включая ADD/UPLOAD CONTENT, TAGGING, RATING, REVIEWS, VOTE TO PROMOTE, USER PROFILE, REPUTATION, DISCOVER NETWORK MEMBERS, FRIEND LIST, GROUPS/SPECIAL INTEREST COMMUNITY, MESSAGING, PRESENCE INDICATOR, SHARING и COLLABORATION.

Глава 10: Интернационализация. Интернационализация вебприложений является важным шагом к локализации – в данном случае к адаптации этих приложений к определенному региону или языку. Это помогает сократить усилия, необходимые для последующей локализации, и избавляет от необходимости разрабатывать отдельные региональные и языковые версии приложений. В этой главе рассказывается о шаблонах проектирования, которые помогают сделать приложение в достаточной степени универсальным и адаптируемым на первых этапах разработки, сюда относятся EXTENSIBLE DESIGN, DATE FORMAT, TIME FORMAT, NUMBER FORMAT, CURRENCY AND CURRENCY FORMAT, GLOBAL GATEWAY и LANGUAGE SELECTOR.

Глава 11: Доступность. Шаблоны проектирования, о которых говорится в этой главе, помогают сделать веб-приложения доступными и поддерживающими рекомендации и правила доступности информации в Интернете, например, правила, сформулированные на консорциуме W3C; к этим шаблонам относятся PROGRESSIVE ENHANCEMENT, SEMANTIC MARKUP, UNOBTRUSIVE STYLE SHEETS, UNOBTRUSIVE JAVASCRIPT, ACCESSIBLE FORMS, ACCESSIBLE IMAGES, ACCESSIBLE TABLES, ACCESSIBLE NAVIGATION и ACCESSIBLE ALTERNATIVE.

Глава 12: Визуальное проектирование. Визуальное проектирование веб-приложений сильно влияет на то, насколько полезным пользователи считают это приложение. Эта глава посвящена тем шаблонам проектирования, которые определяют, как выглядят и какое впечатление производят веб-приложения; сюда относятся LIQUID-WIDTH LAYOUT, FIXED-WIDTH LAYOUT, PROGRESSIVE LAYOUT, GRID STRUCTURE, VISUAL HIERARCHY, HIGHLIGHT и ICONS.

Глава 13: Библиотеки шаблонов. Несмотря на популярность шаблонов и библиотек шаблонов, в настоящее время еще не достигнуто соглашения о том, как шаблоны должны документироваться, соблюдаться и распространяться. По этой причине в данной главе представлен «шаблон» библиотеки шаблонов и показаны ее ключевые элементы, а также предложены лучшие варианты ее расширения.

Глава 14: Помощь. Несмотря на то что при соблюдении основных принципов, процессов и шаблонов проектирования создается удобный и эффективный в применении интерфейс, необходимо предоставить помощь, доступную на каждом этапе взаимодействия пользователя с системой. В главе перечислены шаблоны проектирования, связанные с предоставлением помощи в веб-приложениях, к ним относятся CONTEXTUAL HELP, FREQUENTLY ASKED QUESTIONS, APPLICATION HELP, GUIDED TOURS, HELP WIZARDS, HELP COMMUNITY и CLICK-TO-CHAT.

Примечание

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

Применение шаблонов в этой книге

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

Рассматривайте шаблоны, описанные в этой книге, как рекомендации, а не как конкретные точные проектные решения, и применяйте их, если только они подходят для решения вашей проблемы. Не применяйте шаблон для решения проблемы, только чтобы его применить! Как обозначил Грэхэм (Graham, 2003): «Шаблоны – это абстрактные, ключевые решения проблем, которые возникают в различных контекстах… Практическое применение данного решения может приобретать различные формы в различных приложениях. Поэтому шаблоны не являются готовыми к применению решениями». Поэтому сосредоточьте внимание на сущности шаблона и затем подумайте, как этот шаблон может помочь решить проблему, поскольку шаблоны указывают не на одно-единственное решение, а скорее на стратегию решения проблемы.

Введение

Формы являются отличительной чертой веб-приложений. С помощью элементов формы (например, текстовые поля, раскрывающиеся и прокручиваемые списки, переключатели, флажки и управляющие кнопки) веб-приложения позволяют пользователям выполнять такие задачи, как покупка товаров и услуг, бронирование авиабилетов, поиск местоположения, загрузка и выкладывание фотографий и т. д. Чтобы пользователи могли успешно выполнить свои задачи, важно, чтобы формы не были сложными и были спроектированы так, чтобы:

• их цель была ясна (CLEAR BENEFITS);

• они запрашивали только минимальную необходимую релевантную информацию (SHORT FORMS);

• их структура четко передавала взаимоотношения между элементами формы (LOGICAL GROUPING);

• метки и соответствующие элементы формы были выровнены, чтобы усовершенствовать процесс просмотра (LABEL ALIGNMENT);

• они четко указывали, что должен сделать пользователь (REQUIRED FIELD INDICATORS, INPUT HINTS/PROMPTS);

• они сводили к минимуму объем данных, которые должен ввести пользователь, и не требовали от пользователей дважды вводить одну и ту же информацию (SMART DEFAULTS);

• процесс заполнения формы был результативным (SMART DEFAULTS, FORGIVING FORMAT, KEYBOARD NAVIGATION);

• они четко указывали, как выполнить задание (ACTION BUTTONS);

• они давали пользователям четкие инструкции в случае возникновения ошибки (ERROR MESSAGES).

Хотя выбор подходящих элементов (например, когда использовать флажки, а когда – переключатели) крайне важен для создания удобной в использовании формы, здесь мы об этом говорить не будем, поскольку уже существуют отличные источники, посвященные этому вопросу; например, работа Мейхью (Mayhew, 1991), Галитца (Galitz, 2002), «Руководство по проектированию пользовательских интерфейсов» от компании Apple (2007) и руководство по разработке интерфейса от Windows Vista («User Experience Guidelines», 2007).

Однако важно помнить, что веб-приложения создаются с помощью HTML и предоставляют не все способы управления, доступные для популярных платформ, таких как Windows или Macintosh. В частности, процесс взаимодействия в веб-приложениях ограничивается следующими элементами формы: текстовые поля (в одну строку или состоящие из нескольких строк), переключатели, флажки, раскрывающиеся списки, прокручиваемые списки, кнопки (включая кнопки с изображением) и особый элемент управления для просмотра файлов. К недостающим элементам управления относятся, например, управление прокруткой, комбинированное окно, элемент управления «дерево» и вкладки. Хотя эти элементы управления можно внедрить с помощью сложных комбинаций HTML, каскадных таблиц стилей CSS и сценариев JavaScript, это всего лишь обходные пути решения проблемы, поскольку в данном случае эти элементы не являются частью основного языка разметки.

CLEAR BENEFITS (ЧЕТКИЕ ПРЕИМУЩЕСТВА)

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

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

Рис. 2.1. Социальная сеть LinkedIn четко перечисляет преимущества регистрации в пункте LinkedIn helps you (LinkedIn поможет вам)

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

Пользователи должны быть осведомлены о преимуществах заполнения формы, даже если это форма содержит всего одно поле для заполнения, например как форма подписки на электронную новостную рассылку (рис. 2.2).

Рис. 2.2. Сайт UIE перечисляет преимущества подписки на свою электронную новостную рассылку, «UIEtips»

Объясняйте преимущества регистрации в регистрационных формах

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

Рис. 2.3. Сайт Blockbuster перечисляет преимущества регистрации на Blockbuster.com и предлагает «бесплатный» пробный период каждому регистрирующемуся

Объясняйте преимущества, прежде чем перенаправлять пользователей на форму

Во многих случаях пользователей приходится перенаправлять на форму. Если они не знают о преимуществах, они могут не щелкнуть по ссылке или кнопке, ведущей их к форме. Поэтому очень важно, чтобы преимущества заполнения формы были обозначены до того, как пользователи увидят саму форму. Один из способов это осуществить – это поставить информативные метки на ссылки, например «Перевести деньги» или «Оплатить счета», вместо стандартных меток, таких как «Узнать больше» или «Продолжить». Хотя преимущества могут быть пользователям и непонятны, это помогает сообщить им о том, какое действие будет следующим (рис. 2.4).

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

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

Рис. 2.5. Сайт Prosper (где можно дать или взять взаймы деньги) предоставляет информацию о том, как можно взять или дать деньги в долг с помощью ссылок How to borrow (Как взять в долг) и How to lend (Как дать взаймы)

Рис. 2.6. Помимо перечисления преимуществ ведения блога (описание своих мыслей, получение комментариев и т. д.) сайт Blogger предоставляет информацию о ведении блога с помощью функции Take a Quick Tour(Короткий тур)

Для многих сложных веб-приложений и тех, где пользователь должен внести предоплату, попробуйте предоставить пользователям возможность воспользоваться интерактивным чатом CLICK-TO-CHAT (см. главу 14), который позволит им задавать вопросы непосредственно квалифицированному представителю компании.

SHORT FORMS (КОРОТКИЕ ФОРМЫ)

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

Делайте формы как можно короче (рис. 2.7). Не выясняйте у пользователей информацию, которая «может пригодиться» в будущем. Если дополнительные поля могут предоставить полезную информацию и их нельзя убрать, сделайте их необязательными и соответствующим образом обозначьте (см. далее в этой главе шаблон REQUIRED FIELD INDICATORS).

Рис. 2.7. Для регистрации на сайте Crazy Egg пользователи должны заполнить всего три поля и принять условия использования и политику конфиденциальности. Более того, благодаря объединению формы с соответствующими преимуществами, пользователи точно знают, чего им ожидать

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

Рис. 2.8. В исследовании, проведенном Relevant Ads, показатель эффективности падал с увеличением количества полей в форме

Подумайте, насколько важен каждый элемент формы, и что будет, если не включать его в форму. Помимо этого подумайте, придется ли пользователям прилагать большие усилия, чтобы предоставить информацию. Если пользователям приходится задумываться о том, как ответить на вопрос в форме, рассматривайте это как препятствие заполнению формы, и позаботьтесь о том, чтобы убрать этот вопрос. Самая известная «простая» форма – это, вероятно, форма Google, которая находится на странице поиска и просто предоставляет поле для ввода текста и кнопку поиска (рис. 2.9).

Рис. 2.9. Форма поиска у Google самая простая и короткая. Хотя в нее входит кнопка I'm Feeling Lucky (Мне повезет!), большинство людей обычно вводят ключевые слова и щелкают по кнопке Google Search (Поиск в Google) или нажимают клавишу Enter на клавиатуре

Сервис Jottit предоставляет еще один пример самой короткой и, возможно, самой эффективной формы (рис. 2.10). Чтобы создать интернет-страницу, пользователи просто печатают в поле ввода то, что они хотят разместить на своей странице и щелкают по кнопке «Create a page».

(а)

(б)

Рис. 2.10. На сайте Jottit, чтобы создать веб-страницу, пользователи просто вводят текст и щелкают по кнопке Create a page (Создать страницу) (a). Тогда пользователи получают свою интернет-страницу и возможность ее редактирования (б)

Разделяйте объемные формы на несколько страниц с более короткими формами

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

Рис. 2.11. На сайте Meebo регистрационная форма разделена на несколько страниц. Самая важная часть формы располагается вначале, а на остальных страницах пользователи могут установить дополнительные настройки своей учетной записи и указать свои предпочтения

Разделение формы ускоряет процесс заполнения каждой страницы, и пользователям такая форма может показаться короче, чем если разместить ее целиком на одной странице.

Когда формы максимально сокращены, пусть они кажутся еще более простыми для заполнения. Это можно сделать, указав пользователям, какая информация обязательна (REQUIRED FIELD INDICATORS), сгруппировав и расположив в логическом порядке элементы формы (LOGICAL GROUPING) и сообщив пользователям о преимуществах заполнения формы (CLEAR BENEFITS). Помимо этого попробуйте применить шаблон WIZARDS в формах, которые разделены на несколько страниц (см. главу 5).

LOGICAL GROUPING (ЛОГИЧЕСКОЕ ГРУППИРОВАНИЕ)

Чтобы достичь результата, пользователям приходится заполнять довольно большие формы. Однако разработчикам хотелось бы, чтобы пользователям казалось, что форму легко заполнить и чтобы они охотно ее заполняли.

Группируйте элементы формы так, чтобы пользователям было понятно, какие данные нужно предоставлять в той или иной части формы (например, адрес доставки, платежная информация и т. д.; рис. 2.12).

Рис. 2.12. Yahoo! разделяет элементы регистрационной формы на логические группы, благодаря чему создается впечатление, что форму можно легко и быстро заполнить

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

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

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

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

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

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

LABEL ALIGNMENT (ВЫРАВНИЕ МЕТОК)

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

Существуют три неплохих варианта расположения меток по отношению к элементам формы: над элементом, с выравниванием левой границы метки относительно элемента; слева, с выравниванием левой границы метки относительно других меток; и слева, с выравниванием правой границы метки относительно других меток (рис. 2.15).

(а)

(б)

(в)

Рис. 2.15. Во многих случаях метки располагаются а) над элементами формы; б) выровнены по левому краю и в) выровнены по правому краю

Чем быстрее пользователи могут соотнести метку с соответствующим элементом формы, тем быстрее они смогут заполнить форму. Изучив движения глаз, Пензо (Penzo, 2006) обнаружил, что пользователям достаточно просто соотнести метку с элементом формы, если метки расположены любым из способов, показанных на рис. 2.15.

Однако результаты изучения движений глаз показали, что когда метки полей выровнены по левому краю, большие расстояния между некоторыми метками и соответствующими им полями ввода (возникающие, поскольку метки обладают различной длиной – например, сравните «Название компании» и «Город») приводят к тому, что у пользователей уходит больше времени на зрительное восприятие формы. По сравнению с выравниванием по левому краю, при выравнивании по правому краю общее количество исправлений в 2 раза меньше, что значительно сокращает усилия, которые должен приложить пользователь для заполнения формы.

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

Чтобы правильно соотнести метки с соответствующими элементами формы (для языков с письменностью в направлении слева направо), разместите метки либо слева, либо над элементами управления (Penzo, 2006; Wroblewski, 2008). При размещении меток полей слева от элементов формы выровняйте метки по правому краю так, чтобы они находились близко друг к другу (рис. 2.16).

Рис. 2.16. На сайте PriceGrabber метки расположены слева от элементов формы, но выровнены относительно них по правому краю

При размещении меток над элементами формы важно, чтобы визуально метка одного элемента формы находилась на достаточном расстоянии от предыдущего элемента (Penzo, 2006). Врублевски (Wroblewski, 2008) советует, чтобы расстояние составляло примерно 50 %-75 % высоты отдельного поля для ввода данных. Помимо этого Пензо (Penzo, 2006) советует применять метки с неформатированным шрифтом вместо меток с жирным шрифтом, поскольку жирный шрифт несколько сложнее воспринимать (рис. 2.17).

Рис. 2.17. На сайте Basecamp над полями расположены метки с неформатированным текстом

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

(а)

(б)

Рис. 2.18. На сайте Apple в поле поиска используются встраиваемые метки (a). Метка исчезает, когда пользователь щелкает по полю поиска или начинает вводить искомые слова (б)

Обычно в формах метки сопровождаются индикаторами обязательной к заполнению информации (REQUIRED FIELD INDICATORS).

REQUIRED FIELD INDICATORS (ИНДИКАТОРЫ ОБЯЗАТЕЛЬНЫХ ПОЛЕЙ)

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

Четко укажите обязательную информацию в форме, чтобы пользователи могли ее успешно ее заполнить и чтобы уменьшить вероятность появления сообщения «заполнены не все обязательные поля» (рис. 2.19).

Рис. 2.19. На сайте Dominos обязательные поля обозначены красными звездочками, так пользователю становится понятно, что номер мобильного телефона вводить необязательно. Также указано, какие преимущества пользователь получит, если укажет свой мобильный телефон

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

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

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

Совет

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

Расшифруйте значение индикаторов обязательных полей

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

Размещайте индикаторы обязательных полей одинаково во всех формах

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

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

Рис. 2.20. На сайте TravelPost указатели на обязательные поля находятся слева от меток, расположенных над элементами формы. Однако обратите внимание, что в метках используется полужирный шрифт, что не рекомендуется, поскольку выделенные жирным шрифтом метки увеличивают время на заполнение формы (Penzo, 2006)

Не указывайте дополнительные поля

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

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

Если вам необходимо получить личную информацию, например дата рождения пользователя, пол или раса, четко обозначьте, почему эта информация вам необходима. Кроме этого предоставьте ссылку на «Политику конфиденциальности», где пользователи смогут узнать, каким образом их информация будет использоваться.

Даже если в форме четко указаны обязательные поля, проектировщики все равно должны стремиться максимально сократить общее количество полей в форме – как дополнительных, так и обязательных (SHORT FORMS). Кроме того, если пользователь не заполняет обязательное поле, покажите ему сообщение на той же самой странице, на которой он не заполнил одно из обязательных полей (ERROR MESSAGES).

SMART DEFAULTS («УМНЫЕ» ЗНАЧЕНИЯ ПО УМОЛЧАНИЮ)

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

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

Рис. 2.21. В сервисе Basecamp по умолчанию задана сегодняшняя дата в поле When's it due? (Когда будет готово) и данные о зарегистрированном пользователе в поле Who's responsible? (Кто отвечает?), а также установлен флажок Email 48-hours before it's due (Напомнить мне по электронной почте за 48 часов до того, как срок истечет), чтобы упростить процесс добавления новой задачи

Применение соответствующих значений по умолчанию сводит к минимуму необходимость вводить или выбирать данные. Это сокращает общее время, необходимое для выполнения задания, и количество ошибок при вводе данных. В некоторых случаях, использование значений по умолчанию может устранить необходимость заполнять форму и сведет задачу пользователя просто к подтверждению информации. Например, в приложениях для электронной коммерции пользователям, которые ранее предоставляли информацию об адресе доставки и адресе выставления счета (и разрешили сохранить эту информацию), не нужно заново заполнять все поля на страницах оформления покупки. Вместо этого после нажатия кнопки «Сделать заказ» их можно направить на страницу предварительного просмотра/подтверждения. Поскольку у большинства пользователей адрес доставки и адрес выставления счета меняются нечасто, время оформления заказа сильно сокращается; однако у пользователей должна быть возможность внести изменения в эту информацию.

Значения по умолчанию выполняют еще одну функцию: у пользователей появляется пример, какие данные и в каком формате они должны вводить, что сокращает вероятность возникновения ошибки при вводе данных (van Duyne et al., 2006).

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

Настройки по умолчанию можно применить и к последовательности выполнения заданий; например, если пользователь выполнил задание А и, скорее всего, далее он приступит к выполнению задания Б, направьте пользователей непосредственно на страницу выполнения задания Б (рис. 2.22).

Рис. 2.22. В сервисе Basecamp для усовершенствования процесса смены заданий применяются настройки по умолчанию. Когда пользователи создают список заданий («To-do»), на странице отображается форма Enter a to-do item (Введите задание), и пользователям не приходится щелкать по элементу Add a To-Do (Добавить задание)