Temas do futuro: uma estrutura de design e um tema mestre

O tema WordPress tem uma história rica. Ao longo dos anos, os autores do tema trouxeram uma infinidade de recursos para a plataforma. Em parte, é porque eles muitas vezes tiveram que resolver problemas fundamentais com o WordPress para criar os recursos que os usuários finais desejam.

O post e as aulas de corpo que todos os autores do tema usam hoje? Esses foram originalmente em um tema chamado Sandbox.

Imagens em destaque? Esses foram popularizados por temas de revistas há uma década.

Você acha que os formatos de postagem se originaram com o Tumblr? Matt Mullenweg, co-criador do WordPress, nos ensinou como criar posts à parte em nossos temas em 2004, mas eles existiam antes disso.

Os recursos do WordPress geralmente começam no mundo dos temas. Às vezes, tomamos como garantidos os anos de experimentação e iteração de ideias em que os autores do tema estão colocando no trabalho. Até mesmo o editor de blocos está lidando com itens que tradicionalmente estão no domínio do design de temas. O bloco de cobertura é um bom exemplo. Durante anos, os autores de temas criaram opções de temas para uma imagem básica de herói com texto e botões sobrepostos. O resultado era muitas vezes desajeitado e não ideal para os usuários. Ao trazer esse recurso para o núcleo, ele forneceu aos usuários a capacidade de colocar esse bloco de cobertura em qualquer área de bloco permitida.

A razão pela qual muitos recursos temáticos chegam ao núcleo é que eles simplesmente funcionam melhor quando são padronizados. Os usuários sabem o que esperar e os autores de temas podem se concentrar no aspecto do design em vez de resolver o problema da experiência do usuário.

Parte do problema do passado é que cada novo recurso adotado no núcleo não seguia nenhum padrão de design padrão ou esquema de nomenclatura. Uma grande habilidade no design de temas do WordPress é cometer a miscelânea de centenas de classes na memória.

O editor de blocos está em uma posição única para mudar isso criando uma estrutura de design universal.

O WordPress precisa de um framework de design front-end?

Com os padrões de bloco chegando no futuro e a personalização completa do site em algum momento depois disso, os autores do tema estão se perguntando exatamente para onde esse navio está navegando. É emocionante porque as possibilidades são ilimitadas para os usuários finais. É assustador para os autores temáticos que construíram seus impérios sobre uma maneira de fazer as coisas, mas o desenvolvimento é mais sobre adaptação do que qualquer outra coisa.

Armados com a presciência de que a paisagem está mudando, este é o momento em que os autores do tema precisam se unir para moldar seus futuros em um mundo baseado em blocos.

Há um pouco de uma piada em um dos grupos de desenvolvedores em que estou envolvido que os desenvolvedores principais não são autores de temas. Da perspectiva do autor do tema, às vezes pode parecer que as ideias são jogadas ao acaso sem pensar em sistemas de design CSS.

Oh, eu vejo alguns BEM. Por que esse subelemento não segue o mesmo esquema de nomenclatura? Esperar. Essa é uma classe utilitária de 38 caracteres?

O que sempre faltou ao WordPress é um sistema de design de front-end universal. Às vezes, isso tem sido uma coisa boa. Ele permitiu que os autores do tema usassem sua estrutura preferida. Qualquer autor de tema que esteja no jogo há tempo suficiente lhe dirá que esse tipo de flexibilidade é ótimo ... até que não seja . Você já tentou adicionar classes contextuais a widgets? Que tal adicionar uma classe de utilitário ao wrapper do formulário de comentário? Você vai precisar de uma aspirina. Ou dois.

Com o WordPress, algumas coisas são definitivas e outras são conectáveis. Alguns recursos seguem um esquema de nomenclatura de classe padrão e outros não fazem sentido. O resultado para temas é muitas vezes CSS inchado em uma tentativa de disputar os vários componentes.

É quase impossível usar totalmente uma estrutura de classe utilitária como Tailwind CSS em um tema sem recriar os recursos principais.

Muito disso decorre de anos de código legado se acumulando e do compromisso do WordPress com a compatibilidade com versões anteriores. Mas, o futuro não tem que se assemelhar ao passado. Estamos no limiar de uma nova era, e agora é a hora dos designers de front-end entrarem na conversa.

O WordPress precisa de uma estrutura de design de front-end sólida.

Essa é uma declaração carregada. Se você colocar 20 designers em uma sala e pedir para eles discutirem estruturas de design, isso pode ser uma receita para brigas. Costumo ser otimista e espero que o debate tenha dado resultados.

Gutenberg nos empurrou parcialmente nessa direção, mas não vai longe o suficiente. Com a edição de site completo no futuro, há uma necessidade de uma abordagem mais holística para lidar com esse problema.

Mais do que tudo, precisamos de mais designers de front-end na conversa. Não há como .has-subtle-pale-green-background-color existir como uma classe de utilitário sobre algo como .bg-pale-green , .bg-green-100 ou mesmo .background-pale-green , se você quer ser mais detalhado. Não havia nenhum conceito de otimização que entrou nessa decisão. Em uma época em que os desenvolvedores estão rodando em conexões de internet gigabit, é fácil esquecer que grande parte do mundo está seguindo em um ritmo mais lento.

Um esquema de nomenclatura baseado em componentes com uma boa dose de classes utilitárias é uma opção que pode atingir vários pontos positivos. Este não é um argumento para um framework CSS em detrimento de outro. Existem muitas opções boas e existentes. O WordPress deve enfrentar isso de frente tomando emprestado as bases estabelecidas por outros projetos e criando algo exclusivamente WordPress. Deve ser um líder no campo.

Estruturas de design também são sobre plugins. Há algum cruzamento no reino dos temas em que os dois travam uma guerra contínua desde o início do sistema de temas. O campo de batalha entre temas e plugins está repleto de mortes de boas ideias. Muitos nunca conseguiram o apoio de que precisavam para pousar no núcleo. Algum tipo de padrão de design universal poderia estancar a enxurrada de problemas e exigir um cessar-fogo.

Um plugin que produz um componente front-end personalizado não tem como saber como o tema atual lida com o ritmo vertical, por exemplo. Ele usa margem superior ou inferior? Qual o valor e a unidade utilizada? Isso é fundamental e quase sempre é quebrado quando o plug-in tenta adicionar CSS personalizado para lidar com isso.

O WordPress precisa de uma estrutura de design, ou linguagem, que permita que todas as suas partes móveis se unam em harmonia no front-end. Tenho certeza que chegaremos lá em algum momento. Espero que seja mais coeso do que os componentes aleatórios e esquemas de nomenclatura do passado. Também devemos ter um roteiro claro que preencha alguns dos detalhes técnicos para que desenvolvedores e designers possam estar preparados.

É possível um futuro de um tema?

Rich Tabor argumenta que o núcleo do WordPress poderia fornecer um tema de pai único em seu artigo A Look at WordPress Themes of the Future. A ideia é que os autores do tema sejam relegados a criar um tema filho para este tema “mestre”.

A reação instintiva para muitos seria que não funcionaria, os temas perderiam sua personalidade e viveríamos em um mundo de designs de biscoitos.

A realidade é que estamos caminhando para um futuro onde a ideia de um pai solteiro ou tema principal é uma consideração séria.

A maioria dos temas são agrupamentos personalizados de elementos padrão que existem em quase todos os temas. Existem algumas decisões, além das preocupações estilísticas, que diferenciam os temas entre si, como o layout do cabeçalho. Um tema pode ter um título de site e um menu de navegação em um bloco. Outro pode ter um menu de navegação, título e um segundo menu de navegação abaixo. No entanto, outro tema pode mostrar uma caixa de pesquisa. Em um mundo em que a personalização completa do site pertence ao usuário, essas decisões se tornam parte da experiência do usuário e não da experiência do desenvolvedor.

Os temas precisarão se destacar com paletas de cores, tipografia e sua própria marca de peculiaridade - um retorno dos dias do CSS Zen Garden, mas em uma escala muito maior.

Não vou ficar triste com isso. Seria interessante ver a competição entre os melhores designers da área. Também pode trazer o tema WordPress de volta a uma era em que qualquer um poderia fazê-lo com um pouco de conhecimento e determinação de CSS.

Embora ainda não estejamos prontos para um futuro em que um tema governe todos os temas, é um lugar para iniciar a conversa. Se desenhássemos o WordPress para esse futuro potencial, mesmo que nunca implementássemos um tema mestre, como seria o roteiro? Que obstáculos estão no caminho? É viável?