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

Давайте накидаем перечень контента:

1. Логотип.

2. Глобальная навигация.

3. Вводный текст (только на домашней странице).

4. Редактор кода (только на обучающей странице).

5. Область результата (только на обучающей странице).

6. Индикатор выполнения задания (только на обучающей странице).

7. Теоретический текст (только на обучающей странице).

8. Текст задания (только на обучающей странице).

9. Навигация урока (только на обучающей странице).

10. Регистрационная форма (только на домашней странице).

У нас есть два вида страницы:

• домашняя страница (для вводного текста и регистрационной формы) и

• обучающая страница.

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

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

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

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

• домашняя страница → 1, 2, 3, 10,

• обучающая страница → 1, 2, 4, 5, 6, 7, 8, 9.

Порядок позиций в данном случае не имеет значения. Мы займемся этим во время этапа прототипирования.

Прототипирование со ссылкой на контент

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

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

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

Рисунок 10.2. Такой стиль прототипа обычен. Хотя, скорее всего, он и полезен, он здорово похож на реальный сайт, и только надпись «Прототип» выдает, что это не так. И визуальный дизайн, и контент подвергаются здесь детальной проработке, комбинация, которую возможно лучше обработать через прототип HTML, потому что создание нескольких вариаций для различных размеров экранов на такой ранней стадии проекта в лучшем случае будет нудным. Честно говоря, такая ранняя модель прототипа страницы из Википедии, возможно, служит своей цели. Но минусы для технологического процесса, дружелюбного к будущему проекта, очевидны.

Иллюстрация: Fabrice Florin, Wikimedia Foundation под лицензией CC-BY-SA и GFD / smashed.by/wkpmckp

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

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

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

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

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

С этого момента прототипы становятся интереснее. Используя медиазапросы CSS, мы сможем начать работу над грубыми разметками для экранов различных размеров. Благодаря этому два наших прототипа превратятся в бесчисленное количество, потому что их так легко загрузить в браузер любого устройства. Потом мы сможем проанализировать возможности разметки и показать прототипы клиенту[121].

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

Но для самих себя просмотр прототипов на различных устройствах имеет свои преимущества.

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

Рисунки 10.3 и 10.4

Рисунки 10.5–10.8

Если мы что-то изменяем в перечне, прототип обновляется незначительно. Здесь мы использовали блоки (div) для ускорения процесса, и добавили немного CSS для оформления блоков и разметки.

Рис. 10.3–10.8. показывают наши два, да, только два прототипа на экранах разной ширины. Снаряженные медиазапросами CSS наши прототипы, основанные на HTML, позволяют нам изучить мультиплатформенную верстку на ранней стадии разработки. Мы уже можем начать подумывать о приоритетах и эффекте близости на экранах разных размеров. Представьте, что вы используете графические приложения для визуализации этих изменений в шаблоне, который богат на контент так же, как и модель Википедии (мы видели ее выше). Представьте объем работы над каждым незначительным изменением.

Проектирование структурированного контента

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