Читать онлайн «Идеально! Как создать и переделать свой сайт. Правильный подход и передовые техники разработки». Страница 61

Улучшение опыта взаимодействия против ключевых сценариев

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

Значит ли это, что улучшения несерьезны и не важны? Конечно же, нет.

Возьмем, к примеру, простое приложение для списка дел. Цель такова – сделать приложение используемым независимо от платформы; браузер должен только поддерживать HTML, включая основные функции для форм. Спору нет, что приложение списка дел должно позволять пользователю совершать по крайней мере несколько вещей:

• добавлять пункты дел,

• редактировать текущие пункты,

• отмечать пункты как выполненные,

• архивировать и удалять старые пункты.

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

Одним словом, без JavaScript мы отображаем форму, которая содержит одно или несколько текстовых полей, куда пользователь может вводить один или несколько пунктов, а также клавишу для подтверждения. Содержимое формы посылается на сервер, перед пользователем появляется новая страница с их пунктами дел. Каждый пункт может иметь пару опций (возможно, в виде чекбоксов), и вы можете выполнять действия кликом на клавишу. Еще одно – данные должны передаваться на сервер и обратно, но по крайней мере это будет работать.

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

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

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

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

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

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

Нам надо понять, где и когда представлять определенный контент и размещение. Я пользуюсь визуальным инструментом, который называю графиком точек прерывания. Он помогает мне отметить, где контент и дизайн могут изменяться.

Раньше мы рассматривали три вещи, которые хотели бы изменить по возможности для определенных классов устройств и/или размеров экранов:

• дизайн и расположение,

• функциональность и свойства,

• контент.

Точки, где эти изменения имеют место, называются точками прерывания. Они очень часто устанавливаются в отношении ширины окна просмотра в пикселях, в таких случаях они обычно вводятся в медиазапросы CSS и/или JavaScript. Например, вы могли бы сказать, что когда окно просмотра шире, чем 600 пикселей, обратитесь к макету X.

Точки прерывания не ограничиваются шириной окна просмотра. Любая характеристика класса устройства может быть точкой прерывания: GPS (против отсутствия GPS), камера (против устройства без камеры) и т. п. Мы можем отметить эти точки на графике точек прерывания[124].

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

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

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

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

То, что мы здесь делаем, – это планируем прогрессивное улучшение. Цель такова: обеспечить как можно лучший опыт взаимодействия в контексте каждого устройства. Мы осуществляем это с помощью обеспечения самого основного опыта на самых основных устройствах (в некоторых случаях просто с HTML) и расширяем опыт через свойства, так как все больше и больше навороченных устройств и браузеров поддерживает их. Прогрессивное улучшение сводит до минимума риск, что продукт не будет вообще работать на основных классах устройств. Не все пользуются iOS. Такое планирование дизайна важно. Оно дает ценную информацию дизайнерам и разработчикам и шанс испытать удовольствие от свободы и скорости создания отзывчивого прототипа.

Рисунок 10.13. График точек прерывания для «Трех маленьких прямоугольников»

Вы могли слышать о практике проектирования в браузере. Должно быть, вы подумали, как и я: «Звучит великолепно, но только как я смогу сделать это быстро, когда дизайн еще не утвержден? Не похоже ли это на создание статических шаблонов на стадии разработки? Гораздо проще сделать макет в Photoshop». Но вот дилемма: мы хотим сделать что-то, что клиент может увидеть и одобрить, но мы не хотим начинать сейчас реальную разработку сайта.

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

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