Элиот Стокс - Идеально! Как создать и переделать свой сайт. Правильный подход и передовые техники разработки

Но у нас серьезная проблема. На момент написания этой книги новейшие спецификации Flexbox поддерживаются только в Chrome Canary [123], который ограничивает наши возможности работы с многочисленными устройствами. Если бы это был реальный сайт, мы бы столкнулись с тяжелым выбором. Предположим, мы не хотим создавать механизм разметки Flexbox в JavaScrip, мы застряли в Chrome Canary – единственном браузере, в котором будет исполняться код для задания.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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