Решения разработчиков для создания гибких компонентов

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

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

Изменение нашего мышления в области развития

Мы просто больше не можем проектировать и разрабатывать только для «оптимального» контента или условий просмотра. Вместо этого мы должны принять присущую Интернету гибкость и непредсказуемость и создать устойчивые компоненты. Статические макеты не могут удовлетворить все сценарии, поэтому многие дизайнерские решения принимаются разработчиками во время сборки. Нравится вам это или нет, но если вы UI-разработчик, вы дизайнер, даже если вы таковым себя не считаете!

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

Дизайн

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

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

Макет и порядок

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

Однако в мобильном макете изображение во всех случаях размещается над текстовым содержимым. Предполагая, что мы создаем этот макет с помощью Grid или flexbox, мы могли бы использовать flex-direction или свойство order чтобы изменить порядок макета для каждого второго компонента:

 .text-and-media:nth-child(even) { flex-direction: row-reverse; }

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

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

1. Выразите наши опасения по поводу доступности и порекомендуйте изменить визуальный порядок макетов для мобильных устройств, чтобы он соответствовал порядку для настольных компьютеров.
2. Используйте Javascript для изменения порядка элементов в DOM.

Нам также необходимо решить, применять ли порядок с помощью селектора :nth-child или разрешить клиенту управлять порядком (скажем, путем добавления класса к компоненту). Пригодность каждого варианта, вероятно, будет зависеть от проекта.

Работа с контентом разной длины

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

Более длинный контент

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

1. Изображение или видео остается вверху, а пространство добавляется внизу (рис. 1).
2. Изображение или видео располагаются по центру, добавляя пространство вверху или внизу (рис. 2).
3. Пропорции изображения или видео масштабируются в соответствии с высотой с использованием object-fit: cover , чтобы предотвратить искажение и гарантировать, что изображение заполняет доступное пространство. Это означает, что некоторые части изображения могут быть обрезаны (рис. 3).

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

Авторы контента могут выбрать этот вариант, если он лучше соответствует их потребностям.

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

Более короткий контент

Работать с меньшим количеством контента немного проще, но все же возникают некоторые проблемы. Как должно вести себя изображение, когда текстовое содержимое короче? Должен ли он стать мельче, чтобы общая высота компонента определялась текстовым содержимым (рис. 4)? Или мы должны установить минимальное соотношение сторон, чтобы изображение не превращалось в леттербокс или чтобы изображение занимало его естественную внутреннюю высоту? В этом случае мы также должны рассмотреть вопрос о том, следует ли выравнивать текст по центру или по верхнему краю (рис. 5 и 5а).

Длина заголовка

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

Разрешается ли авторам контента вообще опускать заголовок там, где это им удобно? Это подводит нас к следующему соображению.

Пропуск содержимого

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

Мы можем ограничить авторов контента «обязательными» полями в CMS, но, возможно, мы могли бы также рассмотреть сценарии, в которых клиент может решить опустить изображение или, наоборот, без какого -либо текстового контента? Возможно, было бы полезно предоставить им эти варианты. Вот пример того, как мы можем выбрать визуализацию компонента в таких случаях:

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

Несколько ссылок

Пропуск содержимого — это один из сценариев. Но в Atomic Smash мы обнаружили, что чаще клиенты хотели иметь возможность добавить более одной ссылки на компонент. Это ставит нас перед другим выбором: как разместить несколько ссылок? Раскладываем ли мы их рядом (рис. 8) или складываем вертикально (рис. 8а)?

Как быть с заголовками ссылок разной длины? Хороший трюк — установить ширину обеих ссылок равной максимальной ширине самой длинной (рис. 9). (Эта статья посвящена именно этому.) Это хорошо работает для вертикально расположенных кнопок, тогда как их горизонтальное размещение дает нам еще больше возможностей выбора (рис. 9а).

Нужен ли нам дополнительный стиль ссылок, чтобы различать их? Это все вопросы для рассмотрения.

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

видео

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

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

Помещение в контекст

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

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

В процессе сборки мы решили добавить возможность не использовать цвет фона. Это позволяет нам разбить страницу и сделать ее более интересной:

Мы могли бы либо применить шаблон, используя :nth-child , либо добавить поле в CMS, чтобы дать клиенту больше творческого контроля.

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

Стили текста WYSIWYG

При рассмотрении контента нам нужно учитывать не только длину текста, но и фактические элементы HTML, которые могут быть разрешены в поле основного текста. Авторы контента могут захотеть добавить в основной текст несколько абзацев, якорных ссылок, списков и т. д. В Atomic Smash нам нравится предоставлять WYSIWYG (что видишь, то и получишь) или форматированное текстовое поле для этих областей, что позволяет использовать множество различных элементов. Важно проводить тестирование с различными типами контента и соответствующим стилем, включая тестирование достаточного цветового контраста на всех используемых цветах фона.

Подведение итогов

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

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

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

Контрольный список

Что нужно проверить:

1. Доступность макета (мобильный и десктоп).
2. Изображения с разными внутренними пропорциями — правильно ли они обрезаны?
3. Более длинный и короткий основной текст (включая несколько абзацев).
4. Длинный и короткий заголовок (включая разную длину слова).
5. Опуская (по-разному) заголовок, основной текст, ссылки и изображения.
6. Несколько ссылок (включая разную длину текста ссылки).
7. Доступность видеоконтента.
8. Текстовое содержимое WYSIWYG (включая ссылки, списки и т. д. в основном тексте).
9. Тестируйте в контексте — включайте несколько компонентов (с разными вариантами содержимого), а также другие компоненты, смешанные с макетом страницы.