Acquia Site Studio · antigo Cohesion
Site Studio é governança de design system. Ou vira um depósito de componentes.
Os dois resultados vêm do mesmo produto. O que decide não é a ferramenta, é quem tem autoridade para criar componente e o que acontece quando alguém quer um novo.
A stack
Site Studio não roda sozinho.
Três peças, três responsabilidades distintas. Operamos as três.
CMS
A base. Conteúdo, permissões, workflow e a camada de cache.
Plataforma
Site Studio e a hospedagem gerenciada. Somos parceiros.
Busca
Solr gerenciado. A busca que o Site Studio não resolve.
O que é
Uma camada de construção visual em que o componente é configuração, não desenho.
Uma biblioteca de componentes definida pela engenharia, da qual o time de conteúdo monta as páginas. Cada componente é configuração versionada: vive no repositório, passa por revisão, viaja entre ambientes como código.
O que não está na biblioteca não pode ser usado. Essa restrição não é limitação do produto. É o produto.
Camadas
Variantes
Propriedades
Árvore de elementos
O que o editor preenche
O mesmo componente, duas vezes. À esquerda o que o designer define; à direita o que o editor recebe para usar. Entre os dois não há uma linha de código, e é exatamente isso que se compra quando se compra Site Studio.
Repare no token: space/lg tem o mesmo nome nas duas telas. Não é coincidência de nomenclatura, é governança. Quando ele muda no Figma e não muda aqui, o design system virou o depósito de componentes de que esta página fala.
O erro que custa caro
Tratar Site Studio como page builder.
Começa parecendo agilidade, e o padrão é sempre o mesmo:
- 01Uma campanha precisa de um bloco diferente e ganha um componente novo
- 02O componente novo não é revisado, porque não é código aos olhos de ninguém
- 03Seis meses depois a biblioteca tem três versões do mesmo card
- 04O design system deixa de ser verificável: ninguém sabe qual versão é a certa
O sintoma é a biblioteca crescendo. A causa é não haver resposta para quem decide que um componente novo é necessário.
A camada de engenharia
O produto compila dado de editor dentro do código do template.
Esse único fato explica quase tudo o que dá errado em base grande. O template gerado não é um arquivo que lê dados: é um arquivo onde o valor digitado por quem edita vira parte do fonte compilado.
A consequência prática: um campo declarado como texto que apenas PARECE numérico é emitido sem aspas. Um telefone com um ponto sobrando no fim vira literal inválido, o Twig não compila, e o canvas passa a responder erro em toda renderização. Salvo com sucesso, quebrado para sempre.
As quatro respostas
Quatro defesas para o mesmo fato.
Não são quatro problemas. É um problema e uma progressão: conter, consertar, garantir no deploy e, se o custo continuar, assumir a geração.
- 01CONTER. No save, o Twig compilado é validado e o save é abortado se não compilar. Vale no presave da entidade, onde o template já chega compilado, e parseando do mesmo jeito que a renderização parsearia.
- 02CONSERTAR. Uma rotina confere o que já existe: se compila, não toca; se não compila, corrige e recompila para conferir; se continua quebrado, troca por um stub válido e registra. A página perde um bloco em vez de perder tudo.
- 03GARANTIR NO DEPLOY. Template compilado é artefato gerado, e qualquer regeneração o sobrescreve. A rotina roda dentro do deploy, no passo seguinte ao da regeneração. Conserto feito à mão some no próximo rebuild, em silêncio.
- 04ASSUMIR A GERAÇÃO. Gerar o template você mesmo, com o fonte carregando só estrutura e o valor viajando no contexto. Não é configuração: é decisão de arquitetura, e é o que torna o fonte inerte por construção.
Correção verificada, nunca presumida. Ao trocar o gerador do fornecedor por um próprio, a validação é comparar o HTML renderizado: ler o código gerado e achar que está igual não é prova.
O que o produto não faz
O que você vai escrever, queira ou não.
- Invalidação de componente compartilhado. Alterar um bloco reaproveitado não invalida as páginas que o renderizam, nem a borda. Exige descobrir quais páginas o usam, inclusive aninhado, e purgar cada uma fora do save, porque a busca é cara e faz o editor esperar.
- Preview do que ainda não foi salvo. O produto não mostra a página real com as alterações pendentes. Exige renderizar por subrequest, aplicando os valores não salvos, sem gravar em nó, layout ou revisão.
- Deploy de pacote de componente. Não anda no export e import de configuração padrão: exige rebuild no ambiente de destino. Errar essa etapa derruba o layout do site inteiro.
A solução
Tradução declarada.
O designer entrega uma tela e alguém recompõe aquela tela à mão dentro do CMS. É nesse trajeto que a biblioteca vira depósito: usa-se o componente parecido em vez do certo, e espaçamento e cor são digitados em vez de referenciados.
São duas camadas com donos diferentes: o Site Studio governa a composição, o design system governa a aparência e o comportamento. O ponto de contato é o componente do Site Studio emitir a tag do design system em vez de desenhar markup próprio.
Nada disso aparece em revisão, porque o resultado parece com o Figma. A recomposição manual é a causa. Uma tabela declara, por componente, o que ele emite no design system e o que ele vira no canvas, e a composição deixa de ser recomposta: passa a ser publicada.
O que ela ainda não garante
A arquitetura sustenta a garantia. A implementação ainda a entrega como preferência.
Quando um nó do Figma não casa com nenhuma entrada da tabela, o transformador não recusa: infere uma estrutura genérica a partir do tipo do nó, do nome, da direção do auto-layout e do preenchimento. O design perde o componente do design system e sobrevive como estrutura. E o casamento não é exato: o nome é normalizado e comparado por substring nos dois sentidos, então "Button Group" casa com a entrada "Button".
O desvio é contado quando o componente existe no Figma e não existe na tabela. Nos outros dois casos ele não aparece: um componente casado com a entrada errada é contado sob o nome errado, como se estivesse certo, e um sósia desenhado à mão nunca entra na contagem. O relatório mostra a ausência, não a divergência.
A tabela é o lugar do portão: recusar em vez de inferir, e casar exato em vez de por substring. São duas mudanças pequenas e conhecidas. Ainda não estão lá, e dizer o contrário seria o único trecho desta página que não se sustenta sob pergunta.
O que não está na biblioteca não pode ser usado.
Essa restrição não é limitação do produto. É o produto, e é ela que impede a biblioteca de virar depósito.
A decisão
Quando Site Studio vale, e quando não.
Vale quando
- Há muita gente publicando, com responsabilidades diferentes
- O design system existe e precisa sobreviver à pressa de quem publica
- A operação é multi-marca, multi-país ou multi-site
- Engenharia é gargalo para publicar, e isso está custando campanha
Não vale quando
- O site tem poucas páginas e um time pequeno publicando
- Não existe design system para proteger, e o Site Studio viraria o lugar onde ele deveria ter nascido
- A expectativa é de que a ferramenta substitua a decisão sobre governança
A pergunta útil não é se o Site Studio é bom. É se a sua operação tem o problema que ele resolve.
Perguntas de quem já opera
- Dá para migrar de Cohesion para Site Studio sem reconstruir o site?
- Na maioria dos casos, sim: é a mesma linhagem de produto e a migração é de versão, não de plataforma. O trabalho real raramente está na atualização em si, está em decidir o que fazer com os componentes que a base acumulou. Migrar carregando uma biblioteca inchada é pagar duas vezes pelo mesmo problema.
- Site Studio deixa o Drupal mais lento?
- Não por si. O que pesa é a quantidade de componentes distintos renderizando na mesma página e a granularidade das tags de cache que eles declaram. Biblioteca enxuta com cache bem declarado tem desempenho indistinguível de template escrito à mão; biblioteca inchada é lenta pelo mesmo motivo que qualquer página com componentes demais.
- Quem deve poder criar componente?
- Quem responde pela consistência do design system, e isso costuma ser engenharia junto de design, nunca quem está fechando uma campanha. Não é questão de confiança: quem está sob prazo escolhe sempre o caminho mais curto, e o caminho mais curto é criar um componente novo em vez de descobrir se já existe um parecido.
- Como saber se a nossa biblioteca já está grande demais?
- Um indicador prático: peça a duas pessoas do time de conteúdo que montem a mesma página, separadamente. Se escolherem componentes diferentes para o mesmo bloco, a biblioteca já tem duplicata e o design system já não está sendo imposto por ela.
- Site Studio substitui um design system?
- Não. Ele impõe um design system que já exista, e isso é diferente. Sem decisões de design tomadas antes, a biblioteca vira o lugar onde cada decisão é tomada de novo, uma campanha por vez, sem ninguém revisando o conjunto.
Design system de verdade tem número. Biblioteca de componentes tem catálogo.
- 479
- componentes no design system
- 675
- templates construídos sobre eles
- 3.172
- canvas montados em produção
- 49
- módulos sob medida em produção, de 79 construídos
- 18
- editores publicando sem abrir chamado, em 90 dias
- 9.028
- revisões de conteúdo nos mesmos 90 dias
Medidos no banco de uma plataforma corporativa de grande escala que operamos. Sem nome de cliente e sem setor: escala de design system não identifica empresa, e é por isso que estes números podem ser publicados enquanto outros, desse mesmo projeto, não podem e não são.
Conte como a sua biblioteca está hoje.
Quantos componentes existem, quem pode criar um novo, e o que já quebrou por causa disso.
Engenharia não é decoração. É direção.