Documentação

Design Studio - Visão Geral

Esta documentação apresenta o Design Studio, o CMS (Content Management System) da Wake voltado para lojistas que utilizam o Storefront 2.0, detalhando sua proposta de valor, funcionamento técnico e diretrizes para agências parceiras

O Design Studio surgiu da necessidade estratégica de fornecer autonomia total aos lojistas Wake. O objetivo é permitir a gestão dinâmica de conteúdos como banners, textos e layouts de forma code-free, eliminando a dependência de desenvolvedores para alterações rotineiras.

O Design Studio foi projetado para unir o poder de performance do desenvolvimento em servidor com a flexibilidade de uma interface no-code para o lojista. Nesta primeira versão, o uso de blocos dinâmicos está disponível para páginas do tipo hotsite, focando inicialmente na Home da loja.

O que é o Design Studio?

É uma interface visual dentro do Admin Wake que permite a edição de páginas em tempo real. Através dele, o lojista pode configurar a experiência do usuário sem navegar por sistemas complexos ou fluxos de deploy.

Nesta primeira fase (MVP), o foco exclusivo de atuação são as páginas do tipo Hotsite, especificamente a Home da loja.

O Valor da Autonomia e Gestão de Campanhas

Tradicionalmente, alterações visuais em páginas do Storefront exigiam intervenção direta no código. Com os Blocos Dinâmicos:

  • **Agências **criam a inteligência e o design (HTML + Schema).
  • **Lojistas **ganham autonomia total para arrastar, soltar, editar textos e trocar imagens pelo painel da Wake, sem tocar em código.
  • **Agendamento Inteligente: **O CMS permite planejar o layout de uma campanha inteira com antecedência. É possível definir quando um layout entra no ar e quando ele expira. Após o término, o sistema reverte automaticamente para o layout padrão da loja.digo.

Principais Funcionalidades

O Design Studio oferece recursos avançados para a gestão do dia a dia:

  • Gestão de Layout (Drag-and-Drop): Permite reordenar componentes verticalmente, além de ocultar ou exibir seções nativas sem removê-las do código.

  • Rascunhos (Drafts) e Preview: O lojista pode salvar alterações como rascunho para finalizar posteriormente. O modo de pré-visualização permite ver exatamente como a página ficará antes da publicação oficial.

  • [Agendamento de Campanhas: É possível programar a data e hora exata para um layout entrar e sair do ar (ideal para Black Friday, Natal, etc.)

    ❗️

    Nota importante!

    Ao agendar o término de uma página, certifique-se de que há outra versão programada para substituí-la. Caso contrário, o sistema poderá retornar ao estado inicial da primeira vez que o CMS foi utilizado, correndo o risco de exibir banners desatualizados.

  • Histórico: O sistema mantém um log de versões, permitindo identificar quem fez a alteração e realizar a reversão imediata para uma versão anterior em caso de erro.

A Arquitetura do CMS (Como as partes se conectam)

Para que um bloco dinâmico funcione e apareça na sua loja, três partes do seu projeto precisam se comunicar. O fluxo de implementação segue esta ordem lógica:

  1. A Rota (pages.json): Informa à plataforma quais blocos estão disponíveis para aquela página. A Estrutura (pasta Blocks/): Define os arquivos físicos do bloco (o visual em HTML e os campos de edição no Schema).
  2. A Renderização (pasta Pages/): Você diz ao template da página onde os blocos devem ser desenhados na tela.
  3. Abaixo, detalhamos cada um desses três passos.

Passo 1: Autorizando Blocos no Arquivo pages.json

(Nota: Esta informação complementa a documentação existente do pages.json)

O primeiro passo é habilitar a página para receber o CMS. Para isso, utilizamos a propriedade content_for_page. Ela funciona como um "cardápio", listando quais tipos de blocos o lojista poderá adicionar naquela URL. No exemplo abaixo, estamos autorizando a home (urlMatch: "") a usar três tipos de blocos:

{
  "type": "hotsite",
  "path": "hotsite.html",
  "customs": [
    {
      "urlMatch": "",
      "path": "home.html",
      "content_for_page": [
        { "type": "banner_button" },
        { "type": "product_carousel" },
        { "type": "image_showcase" }
      ]
    }
  ]
}
🚧

Atenção à Conexão:

O valor definido em type (ex: "banner_button") é o identificador único do bloco. Esse nome exato será usado para nomear os arquivos físicos na próxima etapa. Se houver divergência, o CMS poderá não identificar corretamente o bloco.

Passo 2: Criando os Arquivos na pasta Blocks

Nota: Esta informação complementa a documentação de Estrutura de Pastase funciona de forma similar aos Components

Agora que o pages.json sabe que o bloco "banner_button" existe para determinado template, precisamos criá-lo fisicamente.

Na raiz do repositório, na pasta Blocks, cada bloco modular exige obrigatoriamente um par de arquivos com o mesmo nome base (o mesmo nome do type definido no passo anterior):

  1. Blocks/<type>.html: O esqueleto visual (Scriban) que renderiza o bloco.
  2. Blocks/<type>.schema.json: O contrato que gera os campos de edição no painel do lojista.

2.1 Construindo o Contrato (schema.json)

O arquivo .schema.json é o que traduz o seu bloco para uma interface amigável. É aqui que são definidas quais opções o lojista verá no painel administrativo da loja.

Estrutura base (exemplo para banner_button.schema.json):

{
  "name": "Banner com Botão",
  "type": "banner_button",
  "settings": [
    {
      "label": "Título Principal",
      "name": "title",
      "type": "text",
      "required": true
    },
    {
      "label": "Cor de Fundo",
      "name": "bg_color",
      "type": "color"
    }
  ]
}

Tipos de Campos Suportados em settings:

  • text / string: Edição direta de chamadas e textos curtos.
  • number: Valores numéricos.
  • image_picker: Seleção visual de imagens (upload ou galeria).
  • url: Links para botões ou banners.
  • color: Personalização de cores (Hexadecimal ou RGBA).
  • select: Criação de variações (requer array options). Ex: "Modo Noturno", "Alinhamento". checkbox: Chave liga/desliga (booleano).

2.2 Desenhando o Visual (.html)

Com o Schema criado, o painel já exibirá os campos. Agora, precisamos que o HTML leia o que o lojista digitou. Dentro do arquivo .html (ex: banner_button.html), todos os dados preenchidos no CMS são entregues dentro do objeto block_data.

🚧

Atenção à conexão:

A chave de acesso no Scriban é exatamente o valor de name que você definiu no settings do seu schema.

{{~ 
  # Acessando os dados do CMS
  titulo = block_data.title ?? "Título Padrão" 
  cor_fundo = block_data.bg_color ?? "#FFFFFF"
~}}

<section class="banner-custom" style="background-color: {{ cor_fundo }}">
  <h2>{{ titulo }}</h2>
  <!-- Restante do markup do componente... -->
</section>

Passo 3: Renderizando na Página Final

O último passo fecha o ciclo. O pages.json autorizou, a pasta Blocks definiu o formato, e o lojista preencheu os dados no painel. Agora, precisamos dizer à página principal da loja (a Home) onde esses blocos devem aparecer.

No template da página (ex: Pages/home.html), utilizamos o helper dinâmico wake_content_for_page. Ele percorre a lista de blocos salvos pelo lojista no painel e renderiza os arquivos HTML correspondentes na ordem exata configurada.

O Padrão Recomendado (Uso de Fallback)

É altamente recomendado manter um conteúdo fixo (fallback) para o caso da loja ainda não ter nenhum layout de CMS publicado ou para o período de transição.

{{ if wake_has_content_for_page }}
    
    {{# Se o lojista publicou ou agendou um layout no CMS, renderiza os blocos aqui #}}
    {{ wake_content_for_page }}

{{ else }}
    
    {{# Fallback: Se o CMS estiver vazio, exibe a estrutura original (legada) do template #}}
    {{ banners_carousel id: "banners_top" banners: data.hotsite.banners position: "Topo" }}
    {{ spot_carousel products: data.lancamentos.products.nodes title:"Lançamentos" }}

{{ end }}

Resumo das Variáveis de Renderização:

wake_has_content_for_page : Retorna true se existe pelo menos um bloco salvo/ativo para aquela renderização.

wake_content_for_page : Executa a renderização sequencial de todos os arquivos Blocks/<type>.html configurados pelo lojista.

Com esses três passos concluídos, sua agência entrega um template 100% integrável com o painel da Wake, permitindo que as equipes de marketing operem com total autonomia!

Updated about 6 hours ago