От страниц к шаблонам.
Упражнение для всех

Язык определяет судьбу компонентов. «Голубая кнопка» будет выполнять свои функции, только до тех пор, пока она будет голубой – а затем её название потеряет всякий смысл. Такой шаблон прекратит своё существование в тот самый момент, когда все голубые кнопки выйдут из употребления. Однако компонент с названием «кнопка» проживёт намного более продуктивную и насыщенную жизнь, даже если его свойства поменяются. Почему? Потому что его название будет описывать функцию, а не то, как он выглядит.

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

Постраничное мышление (всё еще)

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

На Clearleft проблема одновременной разработки страниц и компонентов стала очевидной в нескольких наших последних проектах. Когда вместо того, чтобы предоставить завершённые библиотеки шаблонов, нас попросили сотрудничать с их штатными командами дизайнеров и разработчиками, чтобы помочь им разработать собственную библиотеку. Однажды, в качестве упражнения, мы провели с этой командой несколько недель, сфокусировавшись на пользовательском интерфейсе (UX and UI), перед тем как попросить их назвать и скодировать компоненты дизайна. Первый компонент, который мы разработали, выглядел как карточка, поэтому все назвали её «карточка продукта». Мы продолжили упражнение для разных компонентов, и результаты были похожи. Что ж, это здорово, что люди пришли к единодушию – но вы видите проблему в этой структуре присвоения имён? Что если компонент переместится на другую страницу или будет содержать другой контент? Вы также могли принять карточку продукта за «карточку профиля» или «карточку расположения». Её можно использовать повторно для множества различных целей. Так что название «карточка» стало бы более гибким и простым.

От страниц к шаблонам

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

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

  • принтер
  • бумага
  • ножницы
  • Cтикеры для заметок

Вот как оно выполняется:

Часть первая: бумага и ножницы

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

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

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

image001

Моя версия упражнения – от страниц к шаблонам. Я сгруппировала поля форм, таблицы, кнопки, иконки, шрифты, размеры шрифтов и даже цвета вебсайта.

 

Часть вторая: называние компонентов

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

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

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

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

image003

Несколько предложений для названий компонентов.

Часть 3: кодирование

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

  • Все берут компонент.
  • Кодируют его в HTML (установите ограничение по времени и избегайте соблазна сделать всё идеально). В порядке вещей отказаться от кода, если дизайн поменяется.
  • Сравните и обсудите ваши коды.
  • Повторите.

Повторяйте, повторяйте, повторяйте

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

image005

Первая часть упражнения, повторенная с более крупными компонентами

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

Или вы, возможно, продвинулись дальше в проекте и дизайн уже достаточно цельный, так что вы хотите начать группировать и называть шаблоны. Опять же, используйте последние разработки дизайна для упражнения.  Удобство использования бумаги заключается в низкой цене её замены; вы всегда можете просто её выкинуть и повторить всё снова и снова. Натали Дауни раньше выполняла такое же упражнение, когда работала в Clearleft. Она использовала ручки и бумагу, чтобы создать прототипы компонентов, демонстрируя их функциональность и размер. Это действие помогло ей увидеть, как они могли бы работать вместе, перед тем как тратить время на кодирование.

Что происходит дальше?

Тут все зависит от вас. Зависит от того, чего вы хотите добиться, выполняя упражнение. Лично я нахожу эффективным поместить компоненты и их названия на большой лист бумаги и затем приклеить его на стену так, что всем было видно. Если дизайн поменяется, то компоненты можно перепечатать, обсудить и заменить. Такая наглядность служит напоминанием о компонентах, и будет вызывать дискуссии по мере развития проекта. Или же если ваша команда не имеет возможности работать в одном здании, вы можете хранить записи онлайн. Дэн Мол уже рассказывал о том, как использовать Google Sheet в качестве главного хранилища компонентов, чтобы все члены команды в разное время могли получить доступ и обсуждать их. Целью упражнения, которое я здесь описала, является вовлечение всей команды в процесс создания библиотеки образцов. Алла Холматова идёт ещё дальше и вовлекает пользователей сайта в процесс. Она тестирует на них бумажные компоненты, чтобы получить от пользователей обратный отзыв, так рано как это возможно.

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

Разработка компонентов

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

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

<div class="card">
<a class="card_link" href="#">
<h3 class="card_title">Hello</h3>
<img class="card_hero" src="images/image.png" alt="Card image">
<p class="card_description">Some text content</p>
</a>
</div>

Разновидность – скажем «Карточка продукта» – может быть создан при помощи изменения компонента «Карточка» следующим образом:

<div class="card card-product">
<a class="card_link" href="">
<h3 class="card_title">Hello</h3>
<img class="card_hero" src="images/image.png" alt="Card image">
<p class="card_description">Some text content</p>
</a>
</div>

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

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

image007

Шарлотта Джэксон

является фронт-энд разработчиком в Clearleft в Брайтоне.

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

<blockquote>by <a href=»http://alistapart.com/author/charlottejackson»>Charlotte Jackson</a> 3 ноября, 2015

http://alistapart.com/article/from-pages-to-patterns-an-exercise-for-everyone

Перевод: Ольга Тихоньких</blockquote>

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *