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

Рисунок 10.9. Простой структурированный контент. Это домашняя страница. «Три маленьких прямоугольника», которую я написал на Markdown. Преобразовать Markdown в HTML просто. Для этой цели я использовал Pandoc. Pandoc – это гибкий, универсальный конвертер: smashed.by/pandoc

В начальной точке создания прототипа, подумайте, как бы мы организовали наш контент, если бы не было никакой разметки, кроме линейной, той, что мы часто встречаем в мобильных версиях сайтов, когда один кусок контента располагается под другим. Эта философия «Сначала мобильные» («Mobile first»), которую популяризировал Люк Вроблевски, основывается на доступности и прогрессивном улучшении[122]. Вы можете сказать, что цель заключается в разработке основного отображения приложения, которое функционирует достаточно хорошо везде, где может быть отрендерен простой HTML.

Рисунки 10.10–10.12. Эти скриншоты показывают наш структурированый в HTML-контент в браузере. Иллюстрации (вверху слева и внизу) показывают стили браузера по умолчанию в Opera Mobile Emulator и Firefox на компьютере соответственно. В варианте справа вверху мы начали работать над типографикой

Задайте себе вопрос о том, какой контент должен идти первым, какой вторым, какой последним и как это может повлиять на порядок нашего исходного кода.

Дизайнер и разработчик Брайан Ригер постоянно работает над дизайном текста на ранней стадии разработки. Это, по сути, то, о чем мы здесь говорим: структурирование и определение приоритетов, как если бы мы создавали линейный документ.

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

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

Кстати, все это можно сделать в HTML и CSS. Если вы берете разметку в формате plain-text, такую как Markdown, и потом преобразуете ее в HTML, вы можете создать структурированный дизайн контента так же быстро, как и в текстовом редакторе. Таким способом вы также можете взять базовый HTML и CSS, чтобы использовать для запуска адаптивного (отзывчивого) прототипа.

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

Улучшаем опыт взаимодействия: специфика платформ и устройств, с учетом возможностей браузеров и устройств

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

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

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

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

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

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

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

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

Чуть ближе: классы устройств

Для сайта «Три маленьких прямоугольника» нам действительно нужно обратить внимание на классы устройств. Сайт будет образовательным и требует ввода кода пользователем, чтобы узнать, как он работает. Код будет интерпретироваться в браузере, а результат воспроизводиться на экране.

Давайте реально смотреть на вещи: провернуть все это на большинстве мобильных телефонов невозможно. В общем, вот классы устройств, с которыми мы будем иметь дело:

• с поддержкой HTML: необходима для обучающего текстового контента (теория и синтаксис);

• с поддержкой JavaScript: обязательна для интерактивных заданий;

• с большими экранами: не требуются для текстового контента, но удобны для упражнений;

• с кнопочной (неэкранной) клавиатурой: предпочтительна для набора кода;

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

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

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

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