taller
abierto.
CUADERNO DE TRABAJO

Una web se construye.
Y después se cuida.

Contenido que se entiende, formularios que orientan y documentación que alguien puede usar. Un cuaderno en español para construir y cuidar proyectos web.

La historia del dominio: DrupalCamp México 2013

Antes del tema visual: dibuja el contenido

Una portada puede verse terminada mientras el contenido sigue sin estructura. Para un sitio pequeño, conviene empezar con una hoja y una pregunta: ¿qué cosas distintas vamos a publicar? Una noticia, una persona y una actividad no necesitan exactamente los mismos datos.

Imaginemos una biblioteca comunitaria ficticia. Sus actividades tienen título, fecha, lugar y una descripción. Sus artículos necesitan título, autoría y texto, pero no un horario de asistencia. Si todo se guarda en un gran campo de texto, cada editor deberá recordar el mismo formato. Separar los datos repetidos permite pensar en consistencia antes de elegir colores.

Un modelo mínimo

Dibuja una ficha de actividad y complétala con tres ejemplos inventados: un taller presencial, una charla en línea y una actividad cancelada. El tercer ejemplo es especialmente útil. Obliga a decidir dónde vive el estado de la actividad y cómo se conserva la información anterior sin confundir a quien llega desde un enlace antiguo.

Drupal distingue contenido, configuración, estado y sesión en su guía de tipos de datos. Esa distinción ayuda a no tratar el texto de un artículo, una regla del sitio y un dato temporal como si fueran la misma cosa. El ejercicio de la biblioteca es una propuesta editorial propia, no una receta de configuración para una versión específica.

Cuando las fichas funcionen sobre papel, revisa qué información se repite y cuál debe ser obligatoria. Después podrás decidir cómo implementarla. Un tema visual debería presentar un modelo entendible, no esconder la ausencia de uno.

La etiqueta del formulario debe seguir ahí al escribir

Un campo vacío puede parecer claro porque dentro dice “Tu correo”. Después de escribir, ese texto desaparece. Si era la única explicación, la persona pierde una referencia justamente cuando necesita revisar lo que hizo.

La guía de W3C sobre etiquetas recomienda identificar los controles y asociar las etiquetas con ellos. En HTML, una asociación explícita puede unir el atributo for de la etiqueta con el id del campo. MDN documenta este comportamiento en su referencia del elemento label.

<label for="correo">Correo para responder (opcional)</label>
<input id="correo" name="correo" type="email">

El ejemplo no envía mensajes por sí mismo. Todavía hacen falta validación, tratamiento seguro de los datos y una respuesta comprensible. Su objetivo es mostrar una relación pequeña y verificable: la instrucción permanece visible y el control tiene un nombre asociado.

Prueba con un error realista

Escribe una dirección incompleta y revisa cómo se explica el problema. Luego vuelve al campo con el teclado. ¿Sigue claro qué falta? ¿La página conserva lo ya escrito? Las etiquetas son el comienzo, no una certificación completa de accesibilidad. Una buena revisión combina inspección del código con uso real y, cuando sea posible, pruebas con personas que utilizan diferentes tecnologías de apoyo.