Cosas que hacer y no hacer: Reglas de orientación emparejadas

Un bloque de cosas que hacer y no hacer empareja una acción recomendada con un error del mismo alcance y explica por qué el error falla. Su valor proviene del contraste: la versión incorrecta expone un modo de fallo tentador, mientras que la versión correcta le da al lector un reemplazo inmediato.

Este ejemplo mostrado es el modelo de producción. Cada fila aborda un tema con el mismo nivel de detalle. El «No» nombra un error realista y su consecuencia; el «Sí» proporciona una corrección utilizable. Las etiquetas, no el color ni los iconos, transmiten la distinción.

Por qué importa este elemento

Las reglas son más fáciles de entender cuando los lectores pueden ver el límite que deben respetar. Una instrucción positiva por sí sola puede parecer abstracta: «Usa evidencia específica» no revela qué se considera demasiado vago. Una instrucción negativa por sí sola crea fricción: «No hagas afirmaciones sin fundamento» dice qué evitar pero deja el siguiente paso poco claro. Colocar ambas juntas convierte un límite en una elección que el lector puede aplicar.

La versión incorrecta es instructiva porque a menudo se parece a lo que una persona ocupada escribiría naturalmente. Mostrar ese casi error ayuda al lector a reconocerlo en su propio trabajo. La razón importa igualmente. «No uses lenguaje vago» exige obediencia; «No escribas «rápido» sin nombrar la tarea medida, porque los lectores no pueden verificarlo ni compararlo» enseña un principio que se transfiere a nuevos ejemplos.

La paridad significa que ambos lados cubren temas equivalentes, cantidades, detalle y peso editorial. Evita que una columna pulida de «Sí» se siente junto a un montón de advertencias no relacionadas. Los lectores pueden escanear un par, entender el contraste y continuar sin recordar un elemento de otra parte de la página.

La extraíble por máquina es la capacidad del software de aislar contenido preservando su significado y relaciones. Los encabezados visibles, la estructura de lista y los pares alineados en filas permiten que los sistemas de búsqueda y los motores de respuesta recuperen afirmaciones como «Para precios, nombra el plan y la fecha; evita cifras sin fecha porque su alcance no es verificable». Si los dos lados contienen viñetas no relacionadas o la razón se implica solo mediante un icono, la extracción puede preservar el comando mientras pierde la calificación que lo hace seguro.

Sigue las reglas de redacción de elementos antes de seleccionar este bloque. El propósito tiene prioridad sobre la apariencia. El contenido que principalmente advierte sobre daño inmediato sigue siendo una advertencia; una secuencia sigue siendo una lista de pasos; un conjunto finito de comprobaciones de finalización sigue siendo una lista de verificación. Dos columnas de colores no convierten esos propósitos en cosas que hacer y no hacer.

Cuándo usarlo

Usa este elemento cuando los lectores necesiten distinguir una práctica recomendada de un error plausible y con consecuencias. El contraste debería reducir la ambigüedad de manera más efectiva que una sola instrucción. Los temas adecuados incluyen estándares editoriales, convenciones de implementación, controles de calidad, comportamiento de diseño, manejo de datos y elecciones de procesos.

Todas estas condiciones deben cumplirse:

1. Cada error tiene una acción de reemplazo responsable.
2. La razón para evitar el error puede expresarse en una oración corta.
3. Los elementos son orientación independiente, no pasos que deben completarse en orden.
4. Ambos lados pueden usar el mismo alcance y nivel de especificidad.

Los casos de casi error son comunes:

• Pros y contras: las ventajas y limitaciones evalúan una opción. Las cosas que hacer y no hacer instruyen el comportamiento del lector. «Incluye proyectos ilimitados» es un pro, no un «hacer».
• Advertencia: una consecuencia grave o irreversible necesita prominencia directa y una respuesta, no una columna compañera de igual peso.
• Lista de verificación: una lista de verificación rastrea si el trabajo requerido está completo. Su estado no marcado no es un «No hacer».
• Tabla comparativa: una tabla evalúa varias opciones frente a criterios compartidos. No prescribe comportamientos correctos e incorrectos.
• Antes y después: dos ejemplos pueden mostrar una edición sin expresar una regla de comportamiento reutilizable. Usa cosas que hacer y no hacer solo cuando el contraste enseñe una práctica general.
• Estilo interno arbitrario: si no se puede explicar ninguna consecuencia para el lector, el sistema, el cumplimiento o el mantenimiento, documenta la convención como una regla en lugar de pretender que la alternativa es un error.

No uses el bloque para fabricar oposición. «Escribe con claridad; no escribas sin claridad» reformula la misma abstracción y no enseña nada. El lado incorrecto debe ser lo suficientemente tentador para reconocerlo y lo suficientemente específico para diagnosticarlo.

Dónde colocarlo

Coloca el bloque después de que la página haya definido la tarea, la audiencia y cualquier término necesario para entender la guía. Pertenece inmediatamente después de la explicación o demostración que condensa, o cerca del final de una sección como repaso práctico antes de que el lector actúe.

Reglas de colocación exactas:

• Introduce un tema en el encabezado más cercano. Cada par debe tener sentido bajo ese tema sin tomar prestado el alcance de un párrafo lejano.
• Pon el bloque después del principio rector y antes de una lista de verificación de implementación o siguiente acción. Los lectores deben entender el porqué antes de verificar la finalización.
• En secciones repetidas, usa la misma posición y límites de pares. Mover el bloque de forma impredecible dificulta el escaneo entre temas.
• Mantén las listas emparejadas juntas en el orden de origen y en la disposición visual. La prosa explicativa puede seguir al bloque completo, no dividir sus lados.

No puede situarse directamente junto a otro elemento de decisión de dos columnas, porque las cuadrículas adyacentes oscurecen qué etiquetas y filas pertenecen juntas. No coloques un testimonio, banner promocional, formulario o llamada a la acción entre los lados de «Sí» y «No». No lo conviertas en el primer contenido significativo de una página cuando las reglas dependan de términos o contexto que el lector aún no ha recibido.

Anatomía

Leyenda renderizada

1. Encabezado del tema: nombra la tarea delimitada o decisión compartida por cada par.
2. Etiqueta «Sí»: texto visible que identifica el comportamiento recomendado; un icono o tratamiento verde es complementario.
3. Etiqueta «No»: texto visible que identifica el comportamiento a evitar; la puntuación usa la forma editorial localizada.
4. Declaración de acción: una instrucción imperativa o declarativa que nombra un comportamiento observable.
5. Razón: una oración que conecta la instrucción con una consecuencia, modo de fallo o principio rector.
6. Relación del par: el orden de origen y la disposición preservan qué «Sí» responde a qué «No».
7. Nota de fuente opcional: identifica la política, prueba, regulación o evidencia que rige los requisitos fácticos.

El autor proporciona el tema, los pares y las razones. El renderizador proporciona presentación igualitaria, apilamiento responsivo, etiquetas accesibles e iconos decorativos cuando corresponda.

Ejemplos de diseño

Las siguientes variantes son el conjunto admitido completo. Cambian la densidad y la disposición, nunca la paridad ni el contrato de razonamiento.

Filas emparejadas estándar

Usa de tres a siete filas alineadas horizontalmente en pantallas anchas. Cada fila contiene un «Sí» y un «No» sobre el mismo tema.

Pares apilados para móvil

En anchos estrechos, mantén cada par junto: «Sí», luego «No», luego el siguiente par. Apilar todos los elementos positivos antes que todos los negativos ocultaría la correspondencia.

Variante basada en ejemplos

Úsala cuando el lenguaje exacto, el marcado o el comportamiento de la interfaz sean más útiles que un comando abstracto. Cada lado muestra un ejemplo corto seguido de su razón. El código permanece como texto seleccionable.

Variante de repaso compacto

Úsala solo cuando las razones rectoras ya se hayan explicado inmediatamente arriba. La razón todavía aparece en cada elemento, pero en una frase corta en lugar de un párrafo separado.

No crees variantes solo con iconos, carruseles, pestañas o elementos plegables de forma independiente. Separan el par, ocultan un lado o hacen que la comparación dependa de la interacción.

Parámetros

El contrato modela pares en lugar de dos listas no relacionadas. «Fuente» describe dónde obtiene cada valor el renderizador.

El primer encabezado del cuerpo se asigna a heading. Cada pair anidado posee ambas acciones y ambas razones. El modelo de fuente no debe almacenar todos los elementos positivos separados de todos los negativos, porque eso hace que la correspondencia de filas dependa de la posición en el array y sea fácil de romper durante la edición.

Sintaxis y ejemplos de código

Los tres formatos preservan el mismo tema, orden de pares, acciones y razones. No infieren una razón a partir de la acción ni crean un elemento positivo automáticamente.

Directiva portátil de Markdown

:::dos-and-donts
## Redactar afirmaciones comparativas

::item{do="Nombra el plan exacto y la fecha consultada" dont="No publiques un precio sin fecha"}
### Sí
Los datos comerciales cambian, así que el alcance permite a los lectores verificar y reutilizar la afirmación.

### No
Los lectores no pueden saber qué plan o período describe una cifra sin fecha.
::

::item{do="Compara ambos productos con el mismo criterio" dont="No compares capacidades no relacionadas"}
### Sí
Una medida compartida hace que la diferencia sea significativa.

### No
Criterios diferentes crean la apariencia de comparación sin una elección válida.
::
:::

Este elemento anula el mapeo de elementos predeterminado: el encabezado padre proporciona heading; los atributos del elemento proporcionan las acciones; los primeros subtítulos «Sí» y «No» asignan su texto siguiente a las dos razones.

Shortcode de Hugo

Actualmente ningún shortcode de Hugo de producción implementa el contrato de registro emparejado. Hasta que exista uno, renderiza HTML semántico como el ejemplo en vivo en lugar de usar dos ayudantes de lista no relacionados. El adaptador previsto es:

{{< dos-and-donts >}}
## Redactar afirmaciones comparativas

{{< do-dont-pair do="Nombra el plan exacto y la fecha consultada" dont="No publiques un precio sin fecha" >}}
### Sí
Los datos comerciales cambian, así que el alcance permite a los lectores verificar y reutilizar la afirmación.
### No
Los lectores no pueden saber qué plan o período describe una cifra sin fecha.
{{< /do-dont-pair >}}
{{< /dos-and-donts >}}

El futuro renderizador debe producir una región etiquetada con una lista de registros emparejados. No debe crear dos arrays y combinarlos por índice después del renderizado.

Bloque o shortcode de WordPress

[dos_and_donts heading="Redactar afirmaciones comparativas" variant="standard"]
[pair]
[do action="Nombra el plan exacto y la fecha consultada"]Los datos comerciales cambian, así que el alcance permite a los lectores verificar y reutilizar la afirmación.[/do]
[dont action="No publiques un precio sin fecha"]Los lectores no pueden saber qué plan o período describe una cifra sin fecha.[/dont]
[/pair]
[pair]
[do action="Compara ambos productos con el mismo criterio"]Una medida compartida hace que la diferencia sea significativa.[/do]
[dont action="No compares capacidades no relacionadas"]Criterios diferentes crean la apariencia de comparación sin una elección válida.[/dont]
[/pair]
[/dos_and_donts]

Un bloque personalizado de WordPress debería editar cada par como un solo registro y evitar la publicación cuando falte una acción o una razón.

Ejemplos

Bueno: equivalente, procesable y razonado

Los pares comparten un tema en cada fila: alcance del plan, ventana de tiempo y estado de la evidencia. Ambas acciones son lo suficientemente específicas para revisarlas en un borrador, y cada razón explica lo que puede salir mal. Un lector puede aplicar el principio incluso cuando cambian el precio exacto, el producto o el período.

Malo: dos montones de comandos

Esto falla porque las columnas no están relacionadas y son desiguales. «Sé preciso» no tiene una condición de finalización observable, mientras que «Nunca uses jerga» prohíbe el lenguaje sin distinguir entre términos necesarios y términos no explicados. Ninguno de los elementos negativos indica una consecuencia, y la celda vacía revela que el autor creó dos listas en lugar de cuatro pares.

Repara el bloque eligiendo un tema y luego escribiendo filas equivalentes. Para terminología, el par podría ser: «Define un término especializado necesario en la primera mención, porque la definición permite que los recién llegados sigan el argumento» y «No reemplaces un término preciso con una frase cotidiana vaga, porque la sustitución puede cambiar el significado». La corrección enseña criterio en lugar de imponer un eslogan.

Marcado de esquema y accesibilidad

Schema.org no proporciona un tipo general DoAndDont. Mantén el bloque visible dentro del Article, TechArticle, HowTo u otros datos estructurados a nivel de página cuando la página realmente califique. No conviertas los elementos positivos en registros HowToStep a menos que formen un procedimiento ordenado, y no publiques los pares como FAQPage solo porque contienen explicaciones breves.

Usa encabezados y listas nativos. Una sección exterior recibe su nombre accesible del encabezado del tema. Cada par debe ser un elemento de lista o un registro agrupado que contenga una etiqueta visible de «Sí» y una etiqueta visible de «No». Preserva cada par en el orden de origen para que un usuario de lector de pantalla encuentre la recomendación y su error correspondiente juntos.

El color y los iconos son complementarios. El verde no puede ser la única señal para «Sí», y una cruz no puede ser la única señal para «No». Los iconos decorativos reciben texto alternativo vacío o están ocultos para la tecnología de asistencia. No hagas que un bloque estático sea enfocable. Si el desbordamiento horizontal es inevitable para una tabla de ejemplo, contiene y etiqueta la región de desplazamiento; el componente de producción debería apilar los pares en su lugar.

La contracción «Don’t» (No) es aceptable como texto editorial visible. Los campos de código usan dont seguro para ASCII donde los apóstrofos complicarían los nombres de atributos. Los renderizadores localizan las etiquetas sin cambiar las acciones o razones almacenadas.

Reglas de redacción

Escribe la razón antes de finalizar el comando. Esto obliga al autor a identificar la consecuencia para el lector, el sistema, la seguridad, el cumplimiento o el mantenimiento. Si no se puede escribir una razón defendible, la prohibición puede ser preferencia en lugar de orientación.

Usa de tres a siete pares. Cada acción debe expresar un comportamiento observable en 110 caracteres o menos cuando sea práctico. Dale a cada lado una oración de razón de no más de 180 caracteres. Los límites mantienen ambos lados escaneables; las calificaciones más largas pertenecen a la prosa circundante.

Mantén la paridad en cinco dimensiones:

• Tema: ambas acciones abordan la misma decisión o artefacto.
• Altitud: una regla de marcado precisa no puede emparejarse con una máxima amplia como «escribe bien».
• Gramática: usa imperativos paralelos o declaraciones paralelas.
• Evidencia: aplica el mismo umbral fáctico y de fuentes a ambos lados.
• Peso visual: ningún lado recibe más espacio, énfasis, detalle o visibilidad predeterminada.

Usa un lenguaje directo y neutral. Prefiere «No publiques un precio no verificado» a un lenguaje avergonzante como «Solo los redactores descuidados olvidan verificar los precios». Evita el sarcasmo, el miedo y los términos absolutos a menos que la regla sea genuinamente absoluta y su alcance esté declarado.

Nunca pongas esto dentro del elemento:

• Consejos no relacionados añadidos para llenar un lado o forzar una simetría numérica.
• Una prohibición sin consecuencia, principio o acción de reemplazo.
• Procedimientos ordenados, casillas de verificación, calificaciones, veredictos o ventajas y limitaciones de productos.
• Advertencias críticas de seguridad, exenciones de responsabilidad legales, instrucciones de emergencia o avisos de acción irreversible.
• Testimonios, citas largas, medios, formularios, llamadas a la acción, botones promocionales o códigos de cupón.
• Acordeones anidados, pestañas, carruseles, tablas comparativas u otro bloque de cosas que hacer y no hacer.
• Afirmaciones sobre personas o grupos enmarcadas como fracaso moral en lugar de comportamiento observable.

Cuando un requisito provenga de una política, regulación, prueba o estándar externo, añade una nota de fuente cercana. Atribuye la regla con la suficiente precisión para que un editor pueda verificarla de nuevo; no hagas que el bloque lleve un aparato de citas largo.

Tipos de publicaciones que lo usan

El array postTypes del front matter impulsa esta matriz de uso. La inclusión hace que el elemento esté disponible bajo la condición indicada; no hace que el bloque sea obligatorio en cada página de ese tipo.

Lista de verificación de QA

• El bloque tiene un tema delimitado que queda claro desde su encabezado más cercano.
• El principio rector aparece antes del bloque, para que los pares refuercen la regla en lugar de inventarla.
• Hay de tres a siete pares completos y exactamente el mismo número de acciones «Sí» y «No».
• Cada par aborda el mismo tema, audiencia, alcance y nivel de especificidad.
• Cada «No» nombra un error realista y explica su consecuencia o modo de fallo.
• Cada «Sí» proporciona un reemplazo procesable y explica por qué funciona.
• Ningún elemento simplemente niega a su compañero, repite un eslogan o usa redacción circular.
• Las acciones contienen un comportamiento y se mantienen cerca del objetivo de 110 caracteres.
• Las razones contienen una oración y se mantienen dentro de los 180 caracteres.
• Ambos lados usan gramática, estándares de evidencia, detalle y peso visual paralelos.
• Los requisitos fácticos identifican su política, regulación, prueba o fuente cuando sea necesario.
• El bloque no contiene pasos, estados de verificación, compensaciones de productos, advertencias graves, promociones, formularios ni elementos complejos anidados.
• El texto visible dice «Sí» y «No»; el color, la posición y los iconos no son las únicas señales.
• La salida responsiva mantiene cada par junto en lugar de apilar todos los elementos positivos antes que todos los negativos.
• El encabezado del tema y la estructura de pares siguen siendo comprensibles en texto plano y cuando los estilos o scripts no están disponibles.
• Los datos estructurados describen solo la página contenedora y no inventan un tipo de esquema de cosas que hacer y no hacer.
• Los comentarios de captura de pantalla siguen siendo instrucciones de captura no renderizadas hasta que existan activos reales.

Preguntas frecuentes (FAQ)

La plantilla de academia renderiza las cinco preguntas almacenadas en el front matter [[faq]] de esta página. Cubren la completitud de pares, la paridad numérica, las razones, los datos estructurados y el conteo de elementos.