# Diretrizes de Responsividade, Grid e CMS — Site Omni ## 1. Objetivo Este documento define as regras de grid, responsividade e configuração de conteúdo via CMS para o desenvolvimento do site da Omni. Estas diretrizes devem ser consideradas em conjunto com: * Wireframes e layouts aprovados. * Design System da Omni. * Diretrizes gerais de desenvolvimento do projeto. * Especificações de componentes. * Regras de gestão de conteúdo via CMS. > **Princípio fundamental:** a Omni trabalha com **dois layouts principais e explicitamente definidos: Web e Mobile**. Não deve ser criada uma experiência de responsividade fluida que reorganize continuamente a interface em diferentes larguras. --- # 2. Especificações do Layout Web O layout de referência Web foi projetado considerando: | Propriedade | Valor | | --------------------------------- | --------------: | | Viewport de referência | `1440 × 900 px` | | Grid | `12 colunas` | | Margens laterais | `140 px` | | Gutter / espaçamento | `40 px` | | Breakpoint / referência informada | `80 px` | Esses valores devem ser utilizados como referência para reprodução do layout aprovado. --- # 3. Grid Web A estrutura principal do layout Web utiliza: ```text Viewport de referência: 1440px Margem esquerda: 140px Margem direita: 140px Grid: 12 colunas Gutter: 40px ``` A implementação deve respeitar: * Alinhamento dos elementos ao grid. * Larguras previstas no design. * Margens laterais. * Espaçamentos entre colunas. * Hierarquia e proporções definidas no layout. * Posicionamento dos elementos dentro do grid. Não substituir arbitrariamente o grid aprovado por containers ou grids genéricos do framework utilizado no projeto caso isso altere a composição visual. --- # 4. Estratégia de Responsividade ## 4.1. Regra principal A Omni **não utiliza uma estratégia baseada em layouts fluidos que se reorganizam continuamente para cada tamanho de viewport**. A implementação deve trabalhar com duas experiências principais: ```text WEB + MOBILE ``` Cada experiência possui estrutura e comportamento próprios. --- # 5. Layout Web O layout Web deve atender: * Desktops. * Notebooks. * Tablets em orientação horizontal/paisagem. Dentro desse contexto, devem ser preservados: * Estrutura. * Hierarquia. * Posicionamento. * Proporções. * Ordem dos elementos. * Composição visual. * Comportamento definido no design. O objetivo não é criar diferentes versões intermediárias para cada largura de desktop ou tablet. A implementação deve preservar o conceito do layout Web enquanto estiver dentro da faixa correspondente. --- # 6. Layout Mobile A partir do breakpoint definido para Mobile, a interface deve utilizar a composição específica aprovada para dispositivos móveis. ## Breakpoint principal ```css 720px ``` A mudança deve ser tratada conceitualmente como: ```text WEB ───────────────────── ↓ 720px ↓ ───────────────────── MOBILE ``` Ou seja, existem dois estados principais de layout. A implementação não deve inventar layouts intermediários entre Web e Mobile sem que estejam previstos ou aprovados pelo Design. --- # 7. Regra do Breakpoint de 720px A implementação deve considerar `720px` como o ponto de transição entre as experiências Web e Mobile, conforme especificação do projeto. A convenção exata de implementação (`max-width`, `min-width`, mobile-first ou desktop-first) deve ser definida de forma consistente no código para evitar sobreposição ou gaps entre media queries. O resultado esperado é: ```text Acima da faixa Mobile → Layout Web Faixa Mobile definida pelo breakpoint de 720px → Layout Mobile ``` > Não criar breakpoints adicionais apenas para reorganizar visualmente a página, salvo quando forem tecnicamente indispensáveis e não alterarem o conceito visual aprovado. --- # 8. Não Implementar Responsividade Fluida de Layout Evitar implementar regras que façam a composição mudar continuamente conforme a largura da tela. Por exemplo, não criar arbitrariamente: ```text 1440px → Layout A 1200px → Layout B 1024px → Layout C 900px → Layout D 768px → Layout E 720px → Layout F ``` O conceito correto é: ```text ┌──────────────────────────┐ │ WEB │ │ │ │ mesma linguagem, │ │ estrutura e hierarquia │ └──────────────────────────┘ ↓ 720px ↓ ┌──────────────────────────┐ │ MOBILE │ │ │ │ estrutura específica │ │ para dispositivos móveis │ └──────────────────────────┘ ``` --- # 9. Adaptações Técnicas Permitidas A existência de apenas dois layouts principais não significa que elementos devam quebrar quando houver pequenas variações de viewport. São permitidas adaptações técnicas para garantir funcionamento correto, como: * Ajuste de largura disponível. * Limitação através de `max-width`. * Preservação de `aspect-ratio`. * Ajustes necessários para evitar overflow. * Redimensionamento proporcional de imagens. * Tratamento de textos dinâmicos. * Ajustes de containers. * Scroll horizontal quando previsto pelo componente. * Comportamentos necessários para acessibilidade. Esses ajustes **não devem alterar o conceito do layout**. Não devem mudar arbitrariamente: * Hierarquia. * Ordem dos elementos. * Composição. * Quantidade de colunas definida pelo design. * Posicionamento conceitual. * Relação visual entre os componentes. --- # 10. Web e Mobile São Experiências Específicas Não considerar Mobile simplesmente como: ```text Web reduzido ``` O Mobile deve utilizar a estrutura aprovada especificamente para essa experiência. Portanto, determinados componentes podem possuir diferenças entre Web e Mobile em: * Composição. * Posicionamento. * Imagem. * Proporção. * Organização. * Distribuição de conteúdo. * Comportamento. Essas diferenças devem seguir os layouts aprovados. --- # 11. Imagens por Dispositivo Quando previsto pelo Design e pelo CMS, determinados componentes devem aceitar materiais diferentes para Web e Mobile. Estrutura conceitual: ```text Componente ├── conteúdo compartilhado ├── mídia Web └── mídia Mobile ``` O frontend deve selecionar automaticamente a mídia apropriada de acordo com a experiência ativa. Não utilizar a imagem Web obrigatoriamente no Mobile quando existir material específico cadastrado para Mobile. --- # 12. CMS — Princípios Gerais O CMS deve permitir que a equipe responsável pelo conteúdo atualize as principais informações do site sem necessidade de alterações no código. Os componentes devem: * Consumir dados do CMS. * Evitar conteúdo editorial hardcoded. * Permitir atualização independente dos campos. * Permitir alteração de links. * Permitir substituição de imagens. * Suportar conteúdos específicos para Web e Mobile quando previsto. --- # 13. CMS — Header / Hero O Header/Hero deve permitir configuração dos seguintes campos: | Campo | Configurável | | -------------- | ------------ | | Imagem | Sim | | Título | Sim | | Texto | Sim | | CTA | Sim | | URL de destino | Sim | ## Imagens Web e Mobile O CMS deve prever materiais distintos para: ```text Imagem Desktop/Web Imagem Mobile ``` Essa separação é especialmente importante no Hero devido à composição visual e ao enquadramento das imagens. Estrutura conceitual: ```text Hero ├── title ├── description ├── cta ├── cta_url ├── desktop_image └── mobile_image ``` Os nomes técnicos dos campos podem ser adaptados às convenções existentes no projeto. --- # 14. CMS — Facilidades para Você Cada card da seção **Facilidades para Você** deve permitir configuração individual dos seguintes campos: | Campo | Configurável | | --------------- | ------------ | | Ícone | Sim | | Título | Sim | | Descrição | Sim | | Link de destino | Sim | Estrutura conceitual: ```text Facilidades └── cards[] ├── icon ├── title ├── description └── destination_url ``` A seção deve trabalhar com uma coleção de cards e não com posições hardcoded como: ```text card_1 card_2 card_3 card_4 ``` Preferir: ```text cards[] ``` Isso permite: * Reordenar cards. * Adicionar cards. * Remover cards. * Atualizar cards individualmente. --- # 15. CMS — Nossas Soluções Cada item da seção **Nossas Soluções** deve permitir: | Campo | Configurável | | --------------- | ------------ | | Categoria | Sim | | Imagem | Sim | | Título | Sim | | Descrição | Sim | | Link de destino | Sim | ## Categorias Inicialmente devem ser suportadas: ```text Para Você Para Empresa ``` Estrutura conceitual: ```text Soluções └── items[] ├── category ├── image ├── title ├── description └── destination_url ``` A categoria deve ser tratada como dado estruturado e não inferida pelo título ou conteúdo do card. --- # 16. CMS — Vídeo Institucional A seção de vídeo deve permitir: | Campo | Configurável | | ------------------------------ | ------------ | | URL do vídeo | Sim | | Link do botão "Conheça a Omni" | Sim | Estrutura conceitual: ```text InstitutionalVideo ├── video_url └── know_omni_url ``` A URL do vídeo não deve ficar hardcoded no frontend. O mesmo vale para o destino do botão **"Conheça a Omni"**. --- # 17. CMS — Baixe o App A seção **Baixe o App** deve prever materiais visuais específicos para Web e Mobile. Como a composição visual possui papel fundamental nessa seção, o CMS deve permitir, quando aplicável: ```text Baixe o App ├── desktop_media └── mobile_media ``` Caso existam outros campos editoriais previstos no layout ou no CMS para essa seção, eles também devem ser tratados como conteúdo configurável. O frontend deve utilizar o material correspondente ao contexto ativo. --- # 18. CMS — Notícias Cada notícia exibida no site deve permitir: | Campo | Configurável | | --------------- | ------------ | | Imagem | Sim | | Título | Sim | | Resumo | Sim | | Link da notícia | Sim | Estrutura conceitual: ```text Notícias └── items[] ├── image ├── title ├── summary └── news_url ``` Os componentes devem trabalhar com dados dinâmicos e não depender de uma quantidade fixa de notícias. --- # 19. Tratamento de Conteúdo Web e Mobile Quando existirem conteúdos específicos para cada experiência, a lógica deve priorizar explicitamente o conteúdo correspondente. Exemplo conceitual: ```text WEB → desktop_image MOBILE → mobile_image ``` Caso seja definida uma estratégia de fallback pelo projeto, ela deve ser implementada de forma centralizada e previsível. Exemplo possível: ```text mobile_image disponível? ├── Sim → utilizar mobile_image └── Não → utilizar desktop_image ``` Não assumir esse fallback automaticamente caso o CMS ou as regras de negócio definam outro comportamento. --- # 20. Separação entre CMS e Apresentação O CMS deve fornecer conteúdo. O frontend deve controlar a apresentação. Fluxo esperado: ```text CMS ↓ Dados estruturados ↓ Componente Web/Mobile ↓ Design System Omni ↓ Interface ``` O CMS não deve precisar armazenar regras de layout complexas quando essas regras pertencem ao frontend. Da mesma forma, o frontend não deve conter conteúdo editorial que deveria ser administrável pelo CMS. --- # 21. Regras para Implementação Durante o desenvolvimento: 1. Utilizar o layout `1440 × 900` como referência Web aprovada. 2. Respeitar o grid Web de `12 colunas`. 3. Respeitar as margens laterais de `140px`. 4. Respeitar o espaçamento/gutter de `40px`. 5. Considerar a referência adicional de breakpoint/espaçamento de `80px` conforme especificação do design. 6. Trabalhar com dois layouts principais: **Web e Mobile**. 7. Utilizar `720px` como breakpoint principal entre as experiências. 8. Não criar layouts intermediários arbitrários. 9. Não implementar reorganização fluida que descaracterize o design aprovado. 10. Preservar a hierarquia visual em cada experiência. 11. Utilizar materiais específicos de Web e Mobile quando disponibilizados. 12. Preparar Hero e Baixe o App para mídias distintas por dispositivo. 13. Consumir conteúdos editoriais através do CMS. 14. Evitar conteúdo hardcoded. 15. Implementar cards como coleções dinâmicas quando aplicável. 16. Preservar o Design System da Omni em ambas as experiências. 17. Garantir que adaptações técnicas necessárias não alterem o conceito visual aprovado. --- # 22. Critério de Decisão Caso o desenvolvedor ou agente de IA encontre uma situação de viewport não explicitamente representada no design, **não deve inventar uma nova composição visual**. A prioridade deve ser: ```text 1. Identificar se o viewport pertence à experiência Web ou Mobile ↓ 2. Aplicar o layout correspondente ↓ 3. Preservar hierarquia e composição ↓ 4. Realizar apenas ajustes técnicos necessários ↓ 5. Não criar uma terceira experiência sem validação de Design ``` Se houver conflito entre uma adaptação responsiva convencional e o layout aprovado pela Omni, deve prevalecer o layout aprovado, desde que não gere problemas funcionais ou de acessibilidade. --- # 23. Resultado Esperado O site deve possuir comportamento previsível entre dispositivos. A implementação final deve refletir: ```text SITE OMNI │ ┌─────────┴─────────┐ │ │ WEB MOBILE │ │ Desktop/Tablet ≤ breakpoint paisagem 720px │ │ Layout aprovado Layout aprovado Web Mobile ``` Não deve existir uma sequência arbitrária de layouts intermediários. Ao mesmo tempo, ambos os layouts devem possuir robustez suficiente para lidar com pequenas variações de viewport e conteúdos dinâmicos sem quebrar a interface. > **Diretriz final:** implementar Web e Mobile como duas experiências explicitamente projetadas, preservando a composição definida pelo Design da Omni. A responsividade deve garantir funcionamento e adaptação técnica, mas não deve criar novas hierarquias, reorganizações ou composições que não tenham sido aprovadas.