Начало работы с модулями и модульной интерфейсной разработкой

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

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

Модуль Коллажи

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

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

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

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

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

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

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

• Вместо того, чтобы тратить часы на разработку нескольких статических макетов для разных разрешений, я могу сэкономить много времени, заранее погрузившись в код. Настройка CSS позволяет мне быстро демонстрировать изменения и отзывчивость клиенту на различных устройствах — смартфонах, планшетах и ​​т. д.

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

Создание модулей для фронтенд-разработки

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

Модульный дизайн переплетается с модульной разработкой в ​​итеративном процессе. Я кодирую модуль, затем пробую его в браузере, чтобы увидеть, как он работает, а затем повторяю, если необходимо. Опять же, этот процесс очень похож на сборку Лего — вы в основном проектируете и разрабатываете одновременно и пробуете разные варианты, пока не почувствуете себя хорошо.

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

 .submit-button { background: orange; color: #fff; padding: 10px 20px; font-size: 16px; }

 <a href=“#” class=“submit-button”>A link</a>

Достаточно просто, не так ли? Вы примените класс .submit-button к своему HTML, и это решит вашу текущую проблему. А что произойдет, если вам понадобится создать новую кнопку, точно такую ​​же, но с синим цветом фона? Вы, вероятно, скопируете именно этот класс, а затем измените имя класса и цвет фона. Быстро и грязно. Теперь представьте, что вам нужно использовать ту же кнопку, но с оранжевым фоном. Вы можете видеть, к чему это идет — вы можете получить много повторений CSS. В очень маленьком проекте это может не стать реальной проблемой, но в более крупных, вероятно, станет. Прежде чем вы это узнаете, ваш CSS раздуется и его будет сложно поддерживать.

Если вы когда-либо разрабатывали проект среднего или крупного масштаба, вы, несомненно, испытали немало головной боли. Они могут быть вызваны любой из следующих причин:

• Код, который беспорядочный, непоследовательный, трудно сканируемый и понятный.
• Раздутый код и CSS-файлы XXL с большим количеством дубликатов.
• Код, который сложно поддерживать.
• Отсутствие разделения структуры и кожи.

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

Одним из способов избежать или свести к минимуму эти проблемы является модульное построение.

Модульная кнопка

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

 .button { padding: 10px 20px; font-size: 16px; } .button-orange { background: orange; color: #fff; }

 <a href=“#” class=“button button-orange”>A link</a>

Мы сделали умное разделение стилей. Класс .button содержит стили, используемые каждой кнопкой в ​​вашем проекте, поэтому вам не нужно повторять его. Класс .button-orange использует только те стили, которые относятся к оранжевой кнопке. Вы должны сделать то же самое для всех других кнопок и определить их фон и цвет текста.

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

А как насчет более сложных вещей?

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

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

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

Вовлечение клиента

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

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

Используйте созданные вами модули в качестве строительных блоков для страниц. Для вашей индексной страницы вы можете поместить модуль навигации вверху, затем модуль героя, затем некоторые модули контента, а затем нижний колонтитул. Прежде чем вы это узнаете, у вас уже есть страница для прототипа HTML. Но что такое прототип? Мне всегда нравилось определение прототипа, данное Лией Бьюли из ее замечательной книги «Команда взаимодействия с пользователем»:

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

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

Повторно используйте строительные блоки

Модули и прототипы позволят вам повторно использовать код для текущего проекта, а также для будущих проектов. Настройка модуля из вашего последнего проекта может сэкономить вам много времени — модули, которые вам нужны в каждом проекте, часто похожи. У меня есть большая библиотека модулей, которые я часто использую повторно: вкладки, навигационные меню, кнопки, хлебные крошки, формы, таблицы, нумерация страниц, списки и т. д. Хотя код этих модулей не совсем одинаков во всех проектах, хорошие его фрагменты можно использовать повторно, что сэкономит мне много времени на разработку. Мой вам совет: создавайте повторно используемые модули и для себя. Ознакомьтесь с BASSCSS, Pure и Refills, чтобы вдохновиться.

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

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