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

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

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

Богохульство? Думаю, нет. Наши средства позволяют нам роскошь немедленной публикации. Каждый может создать веб-страницу за секунды. Вы не смогли бы это сделать в печатном виде. Когда работа выходит с печатного станка, существует легкое напряжение, как будто мы должны проверить, как все обернется. Почему мы настаиваем на разработке статических изображений, заставляя клиента утверждать их, и потом делаем ту же работу снова в HTML? Возможно, мы думаем, что дизайнеры не могут или не должны писать код. Спорный вопрос, который не является неминуемым препятствием. В худшем случае дизайнеры могли сделать свои наброски, а потом сесть с верстальщиком и создавать дизайн в браузере.

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

Создание нашего дизайна в HTML и CSS дает следующие преимущества:

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

• Разработчики видят, где правильно, а где нет, с технической точки зрения. Как бонус они постигают процесс графического дизайна (если они не дизайнеры).

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

Полезно будет также показать клиенту скриншоты этих HTML-прототипов. Я делаю скриншоты в различных браузерах, с разной шириной окна просмотра и/или устройств[125] и говорю клиенту: «Вот несколько изображений того, как этот дизайн может работать в различных сценариях». Показ их сначала именно в качестве изображений помогает проводить обсуждение вопросов по дизайну и избежать глубинного анализа отдельных частей контента. Но если клиент хочет изменить стиль, допустим, «шапки», вы можете сделать это в CSS и сделать новые скриншоты очень быстро. Представьте, что вы делаете эти изменения в различных документах Photoshop – невесело! Клиент не заметит (или его не волнует) то, что эти изображения не созданы в Photoshop.

Рисунок 10.14. Взяв наш простой, структурированный контент в HTML, мы создали дизайн для него в линейной форме. Опираясь на скетчи, мы начали добавлять стили к нему. Потом, ссылаясь на наш график точек прерывания, мы сможем использовать медиазапросы, чтобы начать писать код для неимоверно больших экранов и браузеров, которые поддерживают наши желаемые свойства

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

На самом деле, вы продвинулись далеко, но вашего клиента не должно волновать это. Следование технологическому процессу – это преимущество для вас и вашей команды. Клиент тоже останется доволен, когда сайт будет завершен, он будет выглядеть почти так же, как и в прототипе. Как вы будете разрабатывать прототип – это ваше дело. Некоторые генераторы статических сайтов могут приносить пользу: контент утверждается в файлах с разметкой Markdown, которые передаются по конвейеру через шаблоны, чтобы создать статический сайт. В конце концов, это просто инструменты. Вам все же придется сделать несколько шаблонов в HTML и CSS-файлов для дизайна. Если вы уже таким образом сделали исходные прототипы, то обычно контент распределяется по различным прямоугольникам на странице, к которым применяется CSS, основанный на ваших дизайнерских набросках.

Многие дизайнеры эффективно используют метаязыки на основе CSS и/или препроцессоры или компиляторы, такие как SASS и LESS[126] для значимых изменений в CSS в относительно короткие сроки. В сочетании с контролем версий эти средства могут осуществлять разработку в браузере быстрее, проще и намного интереснее, чем работу в графическом редакторе. Апробирование Великой Новой Идеи клиента (или вашей собственной) становится обычным делом, а процесс может помочь вам держать проект «в тонусе» и сохранить бюджет, сократив объем работ, требующийся на освоение новых идей.

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

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

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

В конечном итоге разработка в браузере таким способом приносит огромную пользу:

• Мало или вообще нисколько времени не тратится на графические редакторы. Все время посвящается коду, который мог бы использоваться полностью или частично в процессе разработки самого сайта. Использование контроля версий наподобие Git позволит вам свободно экспериментировать со своим дизайном непосредственно в коде и не волноваться о постоянных изменениях.

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

• Демонстрация клиенту изменений состояний (например, авторизован или разлогинен пользователь) возможна с минимумом усилий.

• Если вы внимательно относитесь к качеству вашего кода на фазе разработки прототипа, многое из него пригодится для создания сайта.

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

Новое мышление, новый подход к дизайну

Давайте взглянем на наш новый технологический процесс:

1. Создать перечень, включив в список наш контент и функции.

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

3. Используйте некоторое количество реального контента в структуре.

4. Создайте линейный дизайн для этого контента.

5. Рассмотрите классы устройств и создайте график точек прерывания.

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

7. Объедините контент из линейного дизайна и вайрфрейма на HTML, создавая дизайн в виде прототипа на HTML.

8. Покажите клиенту скриншоты прототипов, представляя их как графический дизайн.

9. После одобрения дизайна (необязательно) доработайте HTML-прототип и представьте его (например, для пользовательского тестирования).

10. Если все сделали правильно, большая часть кода может использоваться для создания сайта.

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