Текст книги "Шаблоны проектирования веб-приложений"

LANGUAGE SELECTOR (ВЫБОР ЯЗЫКА)

Проблема

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

Решение

Покажите пользователям доступные варианты языка и дайте им возможность изменить язык контента страницы. Чтобы упростить пользователям процесс выяснения, входит ли предпочитаемый ими язык в число доступных, покажите выбор языков в их родном написании, т. е. при просмотре приложения на испанском языке следует предложить выбор английского языка как «English», а не «Ingles» (рис. 10.32).

Рис. 10.32. Google India предлагает пользователям несколько вариантов языков и отображает каждый язык в его собственном написании

Зачем

В таких странах, как Канада и Индия, где приложение могут использовать люди с разными языковыми предпочтениями и являющиеся представителями разных этнических групп, выгодно позволить пользователям переходить на другой язык, поскольку они могут чувствовать себя более комфортно, просматривая контент на родном языке. Кроме того, предоставление языков на выбор в их собственном написании позволяет пользователям легко понять доступные варианты. Это сродни многим интерактивным приложениям с голосовым управлением в Соединенных Штатах, где для выбора испанского языка предупреждают пользователей на испанском языке (например, «para continuar en espanol, oprima el nueve»), а не на английском («To continue in Spanish, press nine»).

Как

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

Рис. 10.33. WordPress предоставляет выбор языков, как будто бы пункты меню написаны носителями этих языков

Рис. 10.34. Blogger показывает варианты в их собственном написании и на их языке, также как и выбранный в настоящее время язык

Откажитесь от использования флагов для обозначения языков

Несмотря на то что использование флагов для обозначения стран приемлемо, при использовании их для обозначения языков возникает несколько проблем. Прежде всего флаги представляют страны, а не языки. На определенных языках говорят во многих странах, а в некоторых странах говорят на нескольких языках. Например, использование флага США для английского языка было бы неуместно, поскольку на английском говорят в Соединенных Штатах, Канаде, Великобритании, Австралии, Новой Зеландии и ряде других стран.

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

Предоставьте пользователям возможности изменять первоначально выбранный язык

Независимо от первоначального выбора языка пользователями, предоставьте им возможность изменить его позже.

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

Рис. 10.35. Языки предложены на выбор в виде набора ссылок в нижней части колонтитула

Сохраняйте местонахождения пользователей на той же странице

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

Рис. 10.36. При изменении языка Blogger оставляет пользователей на той же странице, но отображенной на вновь выбранном языке

Запоминайте выбранный пользователем язык

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

Связанные шаблоны проектирования

Поддержка нескольких языков, как правило, требует приспособиться к расширению текста, повышая важность и актуальность лучших методов, предложенных в шаблоне EXTENSIBLE DESIGN. Кроме того, выбор языка часто предоставляется при первом посещении пользователем приложения и может быть представлен как часть шаблона GLOBAL GATEWAY.

Глава 11
Доступность

Введение

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

При разработке доступных веб-приложений важно следовать принципу прогрессивного улучшения (PROGRESSIVE ENHANCEMENT). Он состоит в проектировании веб-страницы послойно так, чтобы основной контент и функциональность были доступны для всех, а более интерактивные (т. е. улучшенные) опции – в зависимости от поддержки браузеров и/или устройств, способных взаимодействовать с более совершенной версией приложения. Для осуществления «прогрессивного улучшения» важно, что бы на прикладных страницах использовались семантическая разметка (SEMANTIC MARKUP,), ненавязчивые таблицы стилей (UNOBTRUSIVE STYLE SHEETS) и «ненавязчивый» JavaScript (UNOBTRUSIVE JAVASCRIPT). Поскольку взаимодействие пользователя с веб-приложениями происходит через формы, важно, чтобы и они были доступными (ACCESSIBLE FORMS). Кроме того, остальной контент, представленный на страницах, также должен иметь максимальную доступность (ACCESSIBLE IMAGES, ACCESSIBLE TABLES, ACCESSIBLE NAVIGATION).

Несмотря на то что данный вариант не является преимущественным, существуют ситуации, когда веб-приложения не могут быть полностью доступными в их текущей форме – в этом случае может появиться необходимость встраивания альтернативного дизайна, чтобы гарантировать наибольшую доступность (ACCESSIBLE ALTERNATIVE). Это наиболее актуально для богатых веб-приложений (RIA), имеющих существенные требования к доступности. Обращаясь к этой проблеме, Инициатива по доступности Сети (Web Accessibility Initiative, W3C-WAI) Консорциума W3C (World Wide Web Consortium) предложила перспективный план и рабочие черновые версии Доступных богатых веб-приложений (Accessible Rich Internet Applications, WAI-ARIA). В то время как вспомогательные технологии будут нагонять рекомендации W3C-WAI, разработчики, возможно, захотят включать предложенную разметку в свои проекты.

Шаблоны в этой главе помогут создать веб-приложения с расширенным доступом и поддержкой стандартов и правил расширенного доступа в Интернет (см. врезку «Стандарты и правила доступности Интернета»).

СТАНДАРТЫ И ПРАВИЛА ДОСТУПНОСТИ ИНТЕРНЕТА

Некоторые страны приняли различные законы и стандарты, что бы обеспечить доступность Интернета. В Соединенных Штатах принятые стандарты и правила включают: Акт о правах американских граждан-инвалидов (Americans with Disabilities Act, ADA), Акт об образовании лиц с ограниченными возможностями (Individuals with Disabilities Education Act, IDEA), а так же статью 508 Закона о реабилитации от 1973 г. Пожалуй, самыми важными и всеобъемлющими рекомендациями были признаны Указания по обеспечению доступности Веб-контента

1.(Web Content Accessibility Guidelines 1.0, WCAG 0.1) и WCAG 0.2 от W3C-WAI[23]23
  WAI – это организация внутри Консорциума W3C, создающего стандарты для сети Интернет. Более подробную информацию ищите на www.w3.org/WAI.


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

Воспринимаемость. Информация и компоненты интерфейса должны быть представлены пользователю в тех формах, которые он способен воспринять.

Осуществимость. Пользователь должен иметь возможность воспользоваться компонентами интерфейса и навигацией.

Ясность. Информация и работа пользовательского интерфейса должны быть понятными.

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

Дополнительную информацию по стандартам и правилам можно найти на сайте «Правительственные законы, правила, политика, стандарты и поддержка»: www.uiaccess.com/access_links.html#government_laws_regs_policies.

Эта глава посвящена увеличению доступности при помощи вебтехнологий (т. е. HTML, CSS и JavaScript) и не имеет отношения к проблемам доступности, связанным с Flash и PDF. Читатели, желающие узнать больше об увеличении доступности при помощи Flash и PDF, могут посетить следующие ресурсы:

• рекомендации по увеличению доступности Adobe Flash проектирования: www.adobe.com/accessibility/products/flash/best_practices.html;

• увеличение доступности Adobe Acrobat: www.adobe.com/products/acrobat/solutionsacc.html.

Примечание

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

PROGRESSIVE ENHANCEMENT (ПРОГРЕССИВНОЕ УЛУЧШЕНИЕ)

Проблема

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

Решение

Проектируйте веб-приложения по принципу «прогрессивного улучшения». Другими словами, помогите пользователям, у которых установлены устаревшие браузеры или вспомогательные программы, получить доступ к контенту и функциональным возможностям веб-приложения, в то же время предлагая обладателям новых браузеров и более передовых технологий испытать улучшенные (так назывемые более интерактивные) возможности веб-приложения (Champeon, 2003a, 2003b).

Зачем

Использование «прогрессивного улучшения» открывает для вебприложений широкую возможность использования различных элементов устройств, браузеров и вспомогательных технологий. Кроме того, в послойном улучшении, где слои не зависят друг от друга, дизайнеры могут избежать создания отдельной версии с расширенным доступом (см. шаблон ACCESSIBLE ALTERNATIVE далее в этой главе), так как пользователи смогут достичь своих целей независимо от технологии, поддерживаемой браузером и/или вспомогательной программой.

Как

Прежде всего сделайте контент веб-приложения доступным при использовании веб-стандартов разметки и структуры содержимого страницы, а так же функциональности, не требующей со стороны клиента знания таких технологий, как JavaScript (см. шаблоны SEMANTIC MARKUP и ACCESSIBLE FORMS далее в этой главе). Как только контент и функциональность веб-приложения станут доступными максимально возможной аудитории, следующим шагом станет повышение качества отображения при помощи таблиц стилей. Однако приложите все усилия, чтобы гарантировать, что введение таблиц стилей не поставит под угрозу удобство и доступность для пользователей, чьи браузеры не поддерживают таблицы стилей (см. шаблон UNOBTRUSIVE STYLE SHEETS далее в этой главе). Последний слой будет являть собой комплексное сочетание методов выполнения сценариев с клиентской стороны (например, JavaScript), которое сможет сделать приложение более чувствительным и эффективным при помощи поддержки функции перетаскивания, сортировки информационного наполнения таблицы, проверки на валидность основных форм без необходимости отправления данных на сервер и т. д. Как в случае с таблицами стилей, добавленная интерактивность не должна помешать пользователю получить доступ к контенту веб-приложения или его функциональности (см. шаблон UNOBTRUSIVE JAVASCRIPT далее в этой главе). Наконец, обеспечьте работу веб-приложений, использующих Ajax[24]24
  Ajax, или Asynchronous JavaScript and XML (Асинхронный JavaScript и XML), представляет собой комбинацию таких технологий, как JavaScript, каскадные таблицы стилей (CSS), объектная модель документа (DOM) и XMLHttpRequest, позволяющих создать у пользователя самые яркие впечатления, которые можно сопоставить разве что с использованием настольных приложений (см. главу 8).


[Закрыть], даже если JavaScript не доступен. Это можно сделать, применив метод HIJAX следующим образом (Keith, 2007):

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

• Используйте метод создания сценариев DOM (см. шаблон UNOBTRUSIVE JAVASCRIPT далее в этой главе), чтобы прервать (т. е. «hijack», как образно называют метод HIJAX) выполнение ссылок и форм, запрашивающих и отправляющих информацию на сервер. Направьте эти запросы через Ajax, и сервер будет посылать только обновленную часть страницы, вместо того чтобы посылать ее всю.

Связанные шаблоны проектирования

Введение «прогрессивного улучшения» (PROGRESSIVE ENHANCEMENT) требует, чтобы веб-страницы были размечены семантически (SEMANTIC MARKUP), а затем улучшены применением шаблонов UNOBTRUSIVE STYLE SHEETS и UNOBTRUSIVE JAVASCRIPT.

SEMANTIC MARKUP (СЕМАНТИЧЕСКАЯ РАЗМЕТКА)

Проблема

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

Решение

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

Это значит, что веб-дизайнеры должны обеспечить связь элементов страницы посредством заголовков и списков (т. е. <h1>, <h2>, <h3>, <h4>, <ul >, <ol> и т. д.), теги <table> не используются для процесса разметки, поэтому аспекты отображения страницы не включены в разметку. Например, дополнительное пространство между абзацами контента создается не при помощи разметки, подобной этой <p>&nbsp;</p>, и она не включает теги <ul> или <blockquote>, чтобы выделить абзац отступами.

Зачем

С семантической разметкой пользователи, работающие в веб-приложении и использующие экранные дикторы, а также браузеры с ограничениями, отсутствием поддержки таблиц стилей или языков сценариев, смогут понять структуру контента, связи между элементами страницы, а также характер контента внутри элемента. Это чрезвычайно важно для пользователей с экранными дикторами, игнорирующими таблицы стилей и использующими навигацию через структурную разметку – например, программа JAWS для Windows, позволяющая перемещаться по заголовкам страницы нажатием клавиши H. При отсутствии разметки навигация по элементам страницы и доступ к соответствующим разделам в ее пределах могут стать чрезвычайно трудными. Использование семантической разметки наряду с ненавязчивыми таблицами стилей (UNOBTRUSIVE STYLE SHEETS) облегчает четкое разграничение структуры и отображения, а так же предоставляет наибольшую совместимость, поддерживая широкий ряд браузеров и устройств. Кроме того, работа со структурой страницы без ее отображения упрощает дизайн и позволяет легко адаптировать и оптимизировать отображение для различных устройств и технологий.

Как

В разметке семантика связана со значением элемента и с тем, как этот элемент описывает содержащийся в нем контент.

Молли E. Хольцхалг (2005)

На начальном уровне, используя семантическую разметку, требуется выбрать и применить HTML-теги, соответствующие заданному структурному значению элементов страницы, не надеясь на то, как будет интерпретироваться браузерами отображение результата. Например, тег <blockquote> предназначен, чтобы цитировать текст из внешнего источника, а не для того, чтобы сделать отступ текста, содержащегося в пределах данного тега. Аналогично, чтобы подчеркнуть текст, должен использоваться тег <em>, вместо <i>, а тег <strong> – вместо <b>. Хоть теги <i> и <b> нежелательны даже в последних версиях HTML и XHTML, все же использование тегов <em> и <strong> является наиболее подходящим для акцентирования слов и фраз. Экранные дикторы, встречаясь с таким выделением текста, могут использовать другую интонацию или акцент.

Точно так же заголовки, абзацы и списки в пределах страницы должны быть выделены доступными тегами разметки HTML, такими как <h1>, <h2>, <p>, <ul>, <ol> и т. д., а не тегами вроде <div> и <span>, не имеющими значений по умолчанию.

Структурные документы, использующие заголовки и списки

Озаглавьте веб-страницы тегами <h1>, <h2>, <h3> и т. п. Теги заголовков устанавливают информационную структуру страницы и помогают пользователям распознать ее иерархию. Пользователи с экранными дикторами и другими вспомогательными технологиями могут так же использовать структуру страницы для навигации (см. шаблон ACCESSIBLE NAVIGATION далее в этой главе). Они могут перепрыгивать с заголовков первого уровня (т. е. <h1>) на заголовки второго, третьего и далее уровней (<h2>, <h3> и т. д.).

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

Аналогично меню навигации, подменю и списки в пределах страниц должны быть размечены при помощи тегов (<ol>, <ul>, <dl> и т. д.). Необходимо взять за правило использовать упорядоченные списки (<ol>) для списков, предлагающих какую-либо форму порядка или приоритета, базируемого на систематизации неупорядоченных списков (<ul>), элементы которых не имеют организации; списков определений (<dl>), элементы которых состоят из терминов (обозначаемых тегом <dt>), и определений этих терминов (тег <dd>).

Используйте таблицы стилей для разметки и отображения

Используйте CSS, чтобы контролировать отображение и разметку веб-страницы. Поместите все описания стилей в отдельный файл, что бы их было легко исправлять (см. шаблон UNOBTRUSIVE STYLE SHEETS далее в этой главе). Не внедряйте связанную со стилем разметку, используя теги <font>, <b>, <i> и т. п. Кроме того, не используйте нежелательные HTML-теги, более не являющиеся частью спецификации HTML. Справочник Ultimate HTML Reference (Lloyd 2008) перечисляет следующие нерекомендуемые элементы: <applet>, <basefont>, <center>, <dir>, <font>, <frame>, <frameset>, <iframe>, <isindex>, <menu>, <noframes>, <s>, <strike>, <u> и <xmp> (см. не рекомендуемые элементы для HTML 4.0: www.w3.org/TR/REChtml40/index/elements.html).

Не используйте таблицы стилей, чтобы моделировать структурную разметку

Не используйте CSS, чтобы придать визуальный вид таким структурным элементам, как заголовки, абзацы и списки, тегами <span> и <div> (рис. 11.1).

Рис. 11.1. Заголовок страницы на сайте YouTube размечен тегами <div> вместо <h1>Rihanna – Disturbia</h1> или <h2>Rihanna – Disturbia</h2>, что мешает пользователям экранных дикторов управлять страницей

Экранные дикторы и другие вспомогательные технологии полагаются на структурную разметку, чтобы сообщить структуру страницы их пользователям. Если элемент является заголовком первого уровня, но не будет обособлен тегом <h1>, то будет представлен пользователям вспомогательной технологии как обычный текст. Поэтому:

• Правильный вариант: <h1>Heading 1</h1>

• Нерекомендуемый вариант: <div class="heading1">Heading1</div>

Несмотря на то что оба из этих методов – стили и отображаются одинаково, значение заголовка первого уровня потеряно без тега <h1>.

Связанные шаблоны проектирования

Как только страница размечена с использованием структурных тегов, к странице могут быть присоединены таблицы стилей, чтобы сделать их визуально привлекательными. Однако делайте таблицы стилей ненавязчивыми (UNOBTRUSIVE STYLE SHEETS), чтобы обеспечить их широкую доступность.