Темы будущего: основа дизайна и главная тема

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

Классы post и body, которые сегодня используют все авторы тем? Изначально они были в теме под названием Sandbox.

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

Вы думаете, форматы постов появились в Tumblr? Мэтт Мулленвег, один из создателей WordPress, научил нас создавать посты в наших темах в 2004 году, но они существовали и раньше.

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

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

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

Редактор блоков имеет уникальную возможность изменить это, создав универсальную структуру дизайна.

Нужна ли WordPress инфраструктура внешнего интерфейса?

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

Вооруженные предвидением того, что ландшафт меняется, авторы тем должны объединиться, чтобы сформировать свое будущее в блочном мире.

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

О, я вижу какой-то БЭМ. Почему этот подэлемент не соответствует той же схеме именования? Ждать. Это 38-символьный служебный класс?

Чего всегда не хватало WordPress, так это универсальной системы внешнего дизайна. Иногда это было хорошо. Это позволило авторам тем использовать предпочитаемую ими структуру. Любой автор темы, который был в игре достаточно долго, скажет вам, что такая гибкость великолепна… до тех пор, пока это не так . Вы когда-нибудь пробовали добавлять контекстные классы в виджеты? Как насчет добавления служебного класса в оболочку формы комментария? Вам понадобится аспирин. Или два.

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

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

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

WordPress нужна надежная структура внешнего интерфейса.

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

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

Больше всего на свете нам нужно больше дизайнеров интерфейса. Не может быть, чтобы .has-subtle-pale-green-background-color существовал как служебный класс над чем-то вроде .bg-pale-green , .bg-green-100 или даже .background-pale-green , если вы хочу быть более подробным. В этом решении не было никакой концепции оптимизации. В то время, когда разработчики используют гигабитные интернет-соединения, легко забыть, что большая часть мира движется медленнее.

Схема именования на основе компонентов со здоровой дозой классов полезности — это один из вариантов, который может найти несколько приятных моментов. Это не аргумент в пользу одного CSS-фреймворка, а не другого. Есть много хороших, существующих вариантов. WordPress должен решить эту проблему, заимствуя основу, заложенную другими проектами, и создавая что-то уникальное для WordPress. Он должен быть лидером в этой области.

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

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

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

Возможно ли будущее с одной темой?

Рич Табор в своей статье A Look at WordPress Themes of the Future приводит аргумент, что ядро ​​WordPress может предоставить единую родительскую тему. Идея состоит в том, что авторы темы должны будут создать дочернюю тему для этой «главной» темы.

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

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

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

Темы должны будут выделяться цветовыми палитрами, типографикой и собственной причудливостью — возвращение дней CSS Zen Garden, но в гораздо большем масштабе.

Я не буду об этом грустить. Было бы интересно увидеть конкуренцию между лучшими дизайнерами в этой области. Это также может вернуть тематику WordPress в эпоху, когда любой мог сделать это с небольшим знанием CSS и решимостью.

Хотя мы не совсем готовы к будущему, в котором одна тема управляет всеми, это место, с которого можно начать разговор. Если бы мы разработали WordPress для этого потенциального будущего, даже если мы никогда не реализуем основную тему, как бы выглядела дорожная карта? Какие препятствия стоят на пути? Возможно ли это?