O Que Fazer e o Que Não Fazer: Regras de Orientação Pareadas
Construa blocos de "o que fazer e o que não fazer" que pareiam ações equivalentes, explicam cada proibição e oferecem aos leitores e mecanismos de resposta uma orientação clara e prática que possa ser reutilizada.
Um bloco de o que fazer e o que não fazer pareia uma ação recomendada com um erro de mesmo escopo e explica por que o erro falha. Seu valor vem do contraste: a versão errada expõe um modo de falha tentador, enquanto a versão certa oferece ao leitor uma substituição imediata.
Escrevendo alegações de comparação
- Faça: Nomeie o plano exato e a data verificada. Fatos comerciais mudam, portanto o escopo permite que os leitores verifiquem e reutilizem a alegação com segurança.Não faça: Não publique um preço sem data. Os leitores não conseguem identificar qual plano ou período o valor descreve.
- Faça: Compare ambos os produtos no mesmo critério. Uma medida compartilhada torna a diferença significativa.Não faça: Não compare a velocidade de um produto com o suporte de outro. Critérios diferentes criam a aparência de comparação sem uma escolha válida.
- Faça: Escreva "Desconhecido" quando não houver evidência disponível. Uma lacuna explícita distingue pesquisa faltante de funcionalidade ausente.Não faça: Não deixe um campo não verificado em branco. Um campo em branco pode ser interpretado como zero, indisponível ou não aplicável.
Este exemplo renderizado é o modelo de produção. Cada linha aborda um assunto no mesmo nível de detalhe. O “Não faça” nomeia um erro realista e sua consequência; o “Faça” fornece uma correção utilizável. Rótulos, e não cores ou ícones, carregam a distinção.
Por que este elemento é importante
Regras são mais fáceis de entender quando os leitores podem ver o limite que devem respeitar. Uma instrução positiva isolada pode parecer abstrata: “Use evidências específicas” não revela o que é considerado vago demais. Uma instrução negativa isolada cria atrito: “Não faça alegações sem fundamento” diz o que evitar, mas deixa o próximo passo incerto. Colocar as duas juntas transforma um limite em uma escolha que o leitor pode executar.
A versão errada é instrutiva porque frequentemente se assemelha ao que uma pessoa ocupada escreveria naturalmente. Mostrar esse erro próximo ajuda o leitor a reconhecê-lo em seu próprio trabalho. A razão é igualmente importante. “Não use linguagem vaga” exige obediência; “Não escreva ‘rápido’ sem nomear a tarefa medida, porque os leitores não podem verificar ou comparar” ensina um princípio que se transfere para novos exemplos.
Paridade significa que ambos os lados cobrem assuntos, contagens, detalhes e peso editorial equivalentes. Isso impede que uma coluna polida de “Faça” se situe ao lado de um monte de avisos não relacionados. Os leitores podem escanear um par, entender o contraste e continuar sem precisar lembrar de um item de outra parte da página.
Extraibilidade por máquina é a capacidade do software de isolar conteúdo preservando seu significado e relacionamentos. Cabeçalhos visíveis, estrutura de lista e pares alinhados em linhas permitem que sistemas de busca e mecanismos de resposta recuperem afirmações como “Para preços, nomeie o plano e a data; evite valores sem data porque seu escopo é inverificável.” Se os dois lados contiverem marcadores não relacionados ou a razão for implícita apenas por um ícone, a extração pode preservar o comando enquanto perde a qualificação que o torna seguro.
Siga as regras de escrita de elementos antes de selecionar este bloco. O propósito tem precedência sobre a aparência. Conteúdo que alerta principalmente sobre dano imediato continua sendo um aviso; uma sequência continua sendo uma lista de etapas; um conjunto finito de verificações de conclusão continua sendo uma lista de verificação. Duas colunas coloridas não transformam esses propósitos em “o que fazer e o que não fazer”.
Quando usar
Use este elemento quando os leitores precisarem distinguir uma prática recomendada de um erro plausível e consequente. O contraste deve reduzir a ambiguidade de forma mais eficaz do que uma única instrução. Assuntos adequados incluem padrões editoriais, convenções de implementação, controles de qualidade, comportamento de design, manipulação de dados e escolhas de processo.
Todas estas condições devem ser verdadeiras:
- Cada erro tem uma ação de substituição responsável.
- A razão para evitar o erro pode ser declarada em uma frase curta.
- Os itens são orientações independentes, não etapas que devem ser concluídas em ordem.
- Ambos os lados podem usar o mesmo escopo e nível de especificidade.
Casos de erro próximo são comuns:
- Prós e contras: vantagens e limitações avaliam uma opção. “O que fazer e o que não fazer” instrui o comportamento do leitor. “Inclui projetos ilimitados” é um pró, não um “faça”.
- Aviso: uma consequência severa ou irreversível precisa de destaque direto e uma resposta, não de uma coluna companheira de peso igual.
- Lista de verificação: uma lista de verificação acompanha se o trabalho necessário está completo. Seu estado não verificado não é um “Não faça”.
- Tabela de comparação: uma tabela avalia várias opções contra critérios compartilhados. Ela não prescreve comportamentos corretos e incorretos.
- Antes e depois: dois exemplos podem mostrar uma edição sem expressar uma regra comportamental reutilizável. Use “o que fazer e o que não fazer” apenas quando o contraste ensinar uma prática geral.
- Estilo interno arbitrário: se nenhuma consequência para o leitor, sistema, conformidade ou manutenção puder ser explicada, documente a convenção como uma regra em vez de fingir que a alternativa é um erro.
Não use o bloco para fabricar oposição. “Faça escrever claramente; não faça escrever obscuramente” reitera a mesma abstração e não ensina nada. O lado errado deve ser tentador o suficiente para ser reconhecido e específico o suficiente para ser diagnosticado.
Onde posicionar
Posicione o bloco depois que a página tiver definido a tarefa, o público e quaisquer termos necessários para entender a orientação. Ele pertence imediatamente após a explicação ou demonstração que resume, ou perto do final de uma seção como uma revisão prática antes de o leitor agir.
Regras exatas de posicionamento:
- Introduza um tópico no cabeçalho mais próximo. Cada par deve fazer sentido sob aquele tópico sem tomar emprestado escopo de um parágrafo distante.
- Coloque o bloco após o princípio orientador e antes de uma lista de verificação de implementação ou próxima ação. Os leitores devem entender o porquê antes de verificar a conclusão.
- Em seções repetidas, use a mesma posição e os mesmos limites de pares. Mover o bloco de forma imprevisível dificulta a leitura entre assuntos.
- Mantenha as listas pareadas juntas na ordem de origem e no layout visual. A prosa explicativa pode seguir o bloco completo, não dividir seus lados.
Ele não pode ficar diretamente ao lado de outro elemento de decisão de duas colunas, porque grades adjacentes obscurecem quais rótulos e linhas pertencem uns aos outros. Não coloque um depoimento, banner promocional, formulário ou chamada para ação entre os lados “Faça” e “Não faça”. Não o torne o primeiro conteúdo significativo em uma página quando as regras dependem de termos ou contexto que o leitor ainda não recebeu.
Anatomia
Legenda renderizada
- Cabeçalho do tópico: nomeia a tarefa delimitada ou decisão compartilhada por cada par.
- Rótulo Faça: texto visível identificando o comportamento recomendado; um ícone ou tratamento verde é suplementar.
- Rótulo Não faça: texto visível identificando o comportamento a evitar; a pontuação usa a forma editorial localizada.
- Declaração de ação: uma instrução imperativa ou declarativa que nomeia comportamento observável.
- Razão: uma frase conectando a instrução a uma consequência, modo de falha ou princípio orientador.
- Relação do par: ordem de origem e layout preservam qual “Faça” responde a qual “Não faça”.
- Nota de fonte opcional: identifica a política, teste, regulamentação ou evidência que rege os requisitos factuais.
O autor fornece o tópico, os pares e as razões. O renderizador fornece apresentação igual, empilhamento responsivo, rótulos acessíveis e ícones decorativos quando apropriado.
Exemplos de design
As variantes a seguir são o conjunto completo suportado. Elas alteram densidade e disposição, nunca a paridade ou o contrato de raciocínio.
Linhas pareadas padrão
Use de três a sete linhas horizontalmente alinhadas em telas largas. Cada linha contém um “Faça” e um “Não faça” sobre o mesmo assunto.
Pares móveis empilhados
Em larguras estreitas, mantenha cada par junto: “Faça”, depois “Não faça”, depois o próximo par. Empilhar todos os itens positivos antes de todos os itens negativos ocultaria a correspondência.
Variante liderada por exemplo
Use quando a linguagem exata, marcação ou comportamento de interface for mais útil do que um comando abstrato. Cada lado mostra um exemplo curto seguido por sua razão. O código permanece como texto selecionável.
Variante de revisão compacta
Use apenas quando as razões orientadoras já tiverem sido explicadas imediatamente acima. A razão ainda aparece em cada item, mas em uma frase curta em vez de um parágrafo separado.
Não crie variantes apenas com ícones, carrossel, abas ou colapsáveis independentes. Elas separam o par, ocultam um lado ou fazem a comparação depender de interação.
Parâmetros
O contrato modela pares em vez de duas listas não relacionadas. “Fonte” descreve de onde o renderizador obtém cada valor.
| Nome | Tipo | Obrigatório | Mín./máx. | Padrão | Fonte |
|---|---|---|---|---|---|
| heading | String simples | Sim | 2–10 palavras; 100 caracteres | Nenhum | Primeiro cabeçalho no corpo |
| pair | Registro repetido | Sim | 3–7 pares | Nenhum | Item de corpo aninhado |
| do | Texto simples com código inline limitado | Sim por par | 1 ação; 110 caracteres recomendados | Nenhum | Atributo do par ou primeiro campo Faça no corpo |
| dont | Texto simples com código inline limitado | Sim por par | 1 ação; 110 caracteres recomendados | Nenhum | Atributo do par ou primeiro campo Não Faça no corpo |
| do-reason | String simples | Sim por par | 1 frase; 180 caracteres | Nenhum | Corpo sob o cabeçalho Faça |
| dont-reason | String simples | Sim por par | 1 frase; 180 caracteres | Nenhum | Corpo sob o cabeçalho Não Faça |
| variant | Enum | Não | standard, example-led ou compact | standard | Atributo |
| source-note | Texto simples com links opcionais | Condicional | 1–3 fontes | Nenhum | Corpo após todos os pares |
O primeiro cabeçalho do corpo mapeia para heading. Cada pair aninhado possui ambas as ações e ambas as razões. O modelo de fonte não deve armazenar todos os itens positivos separadamente de todos os itens negativos, porque isso torna a correspondência de linhas dependente da posição no array e fácil de quebrar durante a edição.
Sintaxe e exemplos de código
Todos os três formatos preservam o mesmo tópico, ordem dos pares, ações e razões. Eles não inferem uma razão a partir da ação nem criam um item positivo automaticamente.
Diretiva Markdown portátil
:::dos-and-donts
## Escrevendo alegações de comparação
::item{do="Nomeie o plano exato e a data verificada" dont="Não publique um preço sem data"}
### Faça
Fatos comerciais mudam, portanto o escopo permite que os leitores verifiquem e reutilizem a alegação.
### Não faça
Os leitores não conseguem identificar qual plano ou período um valor sem data descreve.
::
::item{do="Compare ambos os produtos no mesmo critério" dont="Não compare capacidades não relacionadas"}
### Faça
Uma medida compartilhada torna a diferença significativa.
### Não faça
Critérios diferentes criam a aparência de comparação sem uma escolha válida.
::
:::
Este elemento substitui o mapeamento de item padrão: o cabeçalho pai fornece heading; os atributos do item fornecem as ações; os primeiros subtítulos Faça e Não faça mapeiam seu texto seguinte para as duas razões.
Shortcode Hugo
Nenhum shortcode Hugo de produção implementa atualmente o contrato de registro pareado. Até que um exista, renderize HTML semântico como o exemplo ao vivo em vez de usar dois auxiliares de lista não relacionados. O adaptador pretendido é:
{{< dos-and-donts >}}
## Escrevendo alegações de comparação
{{< do-dont-pair do="Nomeie o plano exato e a data verificada" dont="Não publique um preço sem data" >}}
### Faça
Fatos comerciais mudam, portanto o escopo permite que os leitores verifiquem e reutilizem a alegação.
### Não faça
Os leitores não conseguem identificar qual plano ou período um valor sem data descreve.
{{< /do-dont-pair >}}
{{< /dos-and-donts >}}
O renderizador futuro deve produzir uma região rotulada com uma lista de registros pareados. Ele não deve criar dois arrays e combiná-los por índice após a renderização.
Bloco ou shortcode WordPress
[dos_and_donts heading="Escrevendo alegações de comparação" variant="standard"]
[pair]
[do action="Nomeie o plano exato e a data verificada"]Fatos comerciais mudam, portanto o escopo permite que os leitores verifiquem e reutilizem a alegação.[/do]
[dont action="Não publique um preço sem data"]Os leitores não conseguem identificar qual plano ou período um valor sem data descreve.[/dont]
[/pair]
[pair]
[do action="Compare ambos os produtos no mesmo critério"]Uma medida compartilhada torna a diferença significativa.[/do]
[dont action="Não compare capacidades não relacionadas"]Critérios diferentes criam a aparência de comparação sem uma escolha válida.[/dont]
[/pair]
[/dos_and_donts]
Um bloco WordPress personalizado deve editar cada par como um registro e impedir a publicação quando uma ação ou razão estiver faltando.
Exemplos
Bom: equivalente, acionável e fundamentado
| Faça | Não faça |
|---|---|
| Informe qual plano de preços você verificou. O escopo do plano impede que um preço válido seja aplicado à oferta errada. | Não escreva “a partir de R$ 29” sem o nome do plano. O número pode permanecer tecnicamente verdadeiro enquanto engana o comprador pretendido. |
| Use a mesma janela de medição para cada opção. Períodos correspondentes tornam mudanças e classificações comparáveis. | Não compare um total anual com um instantâneo mensal. Janelas diferentes podem criar um vencedor artificial. |
| Marque evidência indisponível como “Desconhecido.” O rótulo preserva a diferença entre incerteza e ausência. | Não trate um fato omitido como “Não.” Documentação faltante não prova que uma capacidade está indisponível. |
Os pares compartilham um assunto em cada linha: escopo do plano, janela de tempo e status da evidência. Ambas as ações são específicas o suficiente para serem revisadas em um rascunho, e cada razão explica o que pode dar errado. Um leitor pode aplicar o princípio mesmo quando o preço, produto ou período exato muda.
Ruim: duas pilhas de comandos
| Faça | Não faça |
|---|---|
| Seja preciso | Nunca use jargão |
| Adicione exemplos | Não escreva parágrafos longos |
| Mantenha simples | Evite muitos links |
| Verifique fatos | — |
Isso falha porque as colunas são não relacionadas e desiguais. “Seja preciso” não tem condição de conclusão observável, enquanto “Nunca use jargão” proíbe linguagem sem distinguir termos necessários de termos não explicados. Nenhum dos itens negativos declara uma consequência, e a célula em branco expõe que o autor criou duas listas em vez de quatro pares.
Repare o bloco escolhendo um tópico e depois escrevendo linhas equivalentes. Para terminologia, o par poderia ser: “Defina um termo técnico necessário no primeiro uso, porque a definição permite que os novatos acompanhem o argumento” e “Não substitua um termo preciso por uma frase vaga do dia a dia, porque a substituição pode alterar o significado.” A correção ensina julgamento em vez de impor um slogan.
Marcação Schema e acessibilidade
O Schema.org não fornece um tipo geral DoAndDont. Mantenha o bloco visível dentro do Article, TechArticle, HowTo ou outros dados estruturados de nível de página quando essa página genuinamente se qualificar. Não converta os itens positivos em registros HowToStep a menos que eles formem um procedimento ordenado, e não publique os pares como FAQPage meramente porque contêm explicações curtas.
Use cabeçalhos e listas nativos. Uma seção externa recebe seu nome acessível do cabeçalho do tópico. Cada par deve ser um item de lista ou registro agrupado contendo um rótulo “Faça” visível e um rótulo “Não faça” visível. Preserve cada par na ordem de origem para que um usuário de leitor de tela encontre a recomendação e seu erro correspondente juntos.
Cor e ícones são suplementares. Verde não pode ser o único sinal para “Faça”, e um X não pode ser o único sinal para “Não faça”. Ícones decorativos recebem texto alternativo vazio ou são ocultados da tecnologia assistiva. Não torne um bloco estático focalizável. Se o transbordamento horizontal for inevitável para uma tabela de exemplo, contenha e rotule a região de rolagem; o componente de produção deve empilhar pares em vez disso.
A contração “Não faça” é aceitável como texto editorial visível. Campos de código usam dont seguro para ASCII onde apóstrofos complicariam nomes de atributos. Renderizadores localizam os rótulos sem alterar as ações ou razões armazenadas.
Regras de escrita
Escreva a razão antes de finalizar o comando. Isso força o autor a identificar a consequência para o leitor, sistema, segurança, conformidade ou manutenção. Se uma razão defensável não puder ser escrita, a proibição pode ser preferência em vez de orientação.
Use de três a sete pares. Cada ação deve expressar um comportamento observável em 110 caracteres ou menos quando prático. Dê a cada lado uma frase de razão de no máximo 180 caracteres. Os limites mantêm os dois lados escaneáveis; qualificações mais longas pertencem à prosa ao redor.
Mantenha a paridade em cinco dimensões:
- Assunto: ambas as ações abordam a mesma decisão ou artefato.
- Altitude: uma regra precisa de marcação não pode ser pareada com uma máxima ampla como “escreva bem.”
- Gramática: use imperativos paralelos ou declarações declarativas paralelas.
- Evidência: aplique o mesmo limiar factual e de fontes a ambos os lados.
- Peso visual: nenhum lado recebe mais espaço, ênfase, detalhe ou visibilidade padrão.
Use linguagem direta e neutra. Prefira “Não publique um preço não verificado” a linguagem de vergonha como “Apenas escritores descuidados esquecem de verificar preços.” Evite sarcasmo, medo e termos absolutos, a menos que a regra seja genuinamente absoluta e seu escopo seja declarado.
Nunca coloque dentro do elemento:
- Dicas não relacionadas adicionadas para preencher um lado ou forçar simetria numérica.
- Uma proibição sem consequência, princípio ou ação de substituição.
- Procedimentos ordenados, caixas de seleção, classificações, vereditos ou vantagens e limitações de produtos.
- Avisos críticos de segurança, isenções legais, instruções de emergência ou avisos de ação irreversível.
- Depoimentos, citações longas, mídia, formulários, chamadas para ação, botões promocionais ou códigos de cupom.
- Acordeões aninhados, abas, carrosséis, tabelas de comparação ou outro bloco de “o que fazer e o que não fazer.”
- Afirmações sobre pessoas ou grupos enquadradas como falha moral em vez de comportamento observável.
Quando um requisito vier de uma política, regulamentação, teste ou padrão externo, adicione uma nota de fonte próxima. Atribua a regra com precisão suficiente para que um editor possa re verificá-la; não faça o bloco carregar um aparato de citação longo.
Tipos de postagem que o utilizam
O array postTypes do frontmatter orienta esta matriz de uso. A inclusão torna o elemento disponível sob a condição declarada; não torna o bloco obrigatório em toda página desse tipo.
| Tipo de postagem | Uso | Posição preferida | Regra especial |
|---|---|---|---|
| Guias de instruções | Recomendado para escolhas de execução de alto risco ou frequentemente confusas | Após o método relevante, antes da verificação | Nunca substitua etapas ordenadas por pares. |
| Guias completos | Opcional para uma prática delimitada com erros próximos recorrentes | Ao final da seção de ensino relevante | Mantenha cada bloco em um tópico dentro do guia mais amplo. |
| Artigos de documentação | Recomendado para configuração, sintaxe ou convenções de fluxo de trabalho | Após o comportamento canônico ser explicado | Corresponda à versão do produto documentada e à interface. |
| Artigos de lista de verificação | Opcional como ensino antes das verificações | Antes da lista de verificação, nunca dentro dela | Pares explicam julgamento; verificações confirmam conclusão. |
| Postagens de erros a evitar | Recomendado quando cada erro tem uma correção concreta | Após diagnosticar o erro e a consequência | Não comprima evidência no item negativo. |
| Páginas de políticas | Opcional para interpretação prática de uma regra formal | Após a regra autoritativa e escopo | O bloco não pode criar requisitos ausentes da política. |
| Páginas de normas e regulamentações | Opcional para práticas conformes versus não conformes | Após explicar a aplicabilidade e o requisito exato | Cite a disposição controladora e evite conclusões legais além dela. |
| Postagens de framework | Opcional para aplicação correta e incorreta de um framework | Após introduzir a parte relevante do framework | Pareie o uso incorreto com o mesmo princípio do framework, não com conselho genérico. |
Lista de verificação de QA
- O bloco tem um tópico delimitado que fica claro a partir de seu cabeçalho mais próximo.
- O princípio orientador aparece antes do bloco, para que os pares reforcem em vez de inventar a regra.
- Há de três a sete pares completos e exatamente o mesmo número de ações “Faça” e “Não faça”.
- Cada par aborda o mesmo assunto, público, escopo e nível de especificidade.
- Cada “Não faça” nomeia um erro realista e explica sua consequência ou modo de falha.
- Cada “Faça” fornece uma substituição acionável e explica por que funciona.
- Nenhum item meramente nega seu parceiro, repete um slogan ou usa redação circular.
- As ações contêm um comportamento e permanecem próximas ao alvo de 110 caracteres.
- As razões contêm uma frase e permanecem dentro de 180 caracteres.
- Ambos os lados usam gramática, padrões de evidência, detalhe e peso visual paralelos.
- Requisitos factuais identificam sua política, regulamentação, teste ou fonte quando necessário.
- O bloco não contém etapas, estados de verificação, compensações de produto, avisos severos, promoção, formulários ou elementos complexos aninhados.
- O texto visível diz “Faça” e “Não faça”; cor, posição e ícones não são os únicos sinais.
- A saída responsiva mantém cada par junto em vez de empilhar todos os itens positivos antes de todos os itens negativos.
- O cabeçalho do tópico e a estrutura do par permanecem compreensíveis em texto simples e quando estilos ou scripts não estão disponíveis.
- Os dados estruturados descrevem apenas a página envolvente e não inventam um tipo de schema de “o que fazer e o que não fazer”.
- Comentários de captura de tela permanecem instruções de captura não renderizadas até que ativos reais existam.
FAQ
O template da academia renderiza as cinco perguntas armazenadas no frontmatter [[faq]] desta página. Elas cobrem completude dos pares, paridade numérica, razões, dados estruturados e contagem de itens.
Mais tutoriais nesta seção
Pronto para colocar em prática?
Verificação gratuita · Teste de 7 dias · sem cartão de crédito