LFW

Blog · Formularios bien hechos

Enviar sin perder la página

El envío dentro de la página hecho con honestidad: los cuatro estados que un botón de enviar le debe al visitante, por qué lo escrito debe sobrevivir a cada fallo y cómo hacer que el éxito sea audible además de visible.

La recarga es una apuesta con el trabajo de otro

El envío tradicional de un formulario es un pequeño acto de fe: el visitante pulsa el botón, la página en la que estaba se tira a la basura, y llega una página nueva para decir qué pasó. Cuando todo funciona, está bien. Cuando algo falla (un error de validación, un tropiezo del servidor, una conexión caída), el fallo aterriza en lo que el servidor devuelva, y en demasiadas configuraciones esa página llega con todos los campos vacíos. Los diez minutos de escritura cuidadosa del visitante se han cambiado por una frase sobre un número de teléfono no válido.

Esa es la razón real para enviar en el sitio, sin abandonar la página. No porque las recargas sean anticuadas, sino porque conservar la página conserva el trabajo del visitante bajo sus propias manos. Los párrafos que escribió, las opciones que eligió, su posición en la página: todo sobrevive a lo que pase después, porque nada se tiró.

No recargar no es el objetivo. La certeza sí.

Pero un envío dentro de la página también quita algo: la navegación entre páginas que, con todos sus defectos, era evidencia inconfundible de que algo había pasado. Quítela y reemplácela con nada, y obtiene la peor versión de este formulario: el visitante hace clic, la página se queda igual, y le toca interrogar a una pantalla inmóvil. ¿Se envió? Vuelve a hacer clic. Ahora puede tener dos envíos, o ninguno, y sigue sin saberlo.

Así que la decisión no es recargar frente a no recargar. Es si cada estado del envío es inconfundible. Un formulario que envía en el sitio asume la carga de narrar lo que la navegación solía narrar. Esa carga es el trabajo real.

Los cuatro estados que un botón de enviar le debe al visitante

En reposo: el botón invita al clic. Trabajando: en el instante en que aterriza el clic, el botón lo dice. Se desactiva para que un segundo clic nervioso no pueda crear un duplicado, y su propio texto cambia a algo como «Enviando…» para que la evidencia esté exactamente donde el visitante ya está mirando.

Fallo: aparece un mensaje en lenguaje claro cerca del problema, y cada campo sigue conteniendo lo que el visitante escribió. Éxito: el formulario da paso a una confirmación que se siente definitiva (qué se recibió y qué pasa después), no a un formulario que se reinicia en silencio y espera que el visitante saque la conclusión correcta.

El estado de fallo merece la mayor atención de diseño, porque es el que decide si el visitante vuelve a intentarlo. Un envío fallido que conserva las palabras del visitante es un tropiezo; pulsa el botón otra vez y sigue adelante. Un envío fallido que se las come es con frecuencia el fin de la conversación. Muy poca gente reescribe de memoria un mensaje largo para beneficio de un formulario que acaba de descartar el primer borrador.

El éxito tiene una dimensión de accesibilidad fácil de pasar por alto: si la confirmación solo aparece (un mensaje intercambiado en la página), un visitante que usa un lector de pantalla puede no oír nada en absoluto. La página cambió y nadie lo dijo. La confirmación tiene que anunciarse, no solo mostrarse, ya sea moviendo el foco hacia ella o marcando la región para que la tecnología de asistencia lea el cambio en voz alta. Para los sitios del sector público es la misma norma que todo lo demás en la página: cambios de estado que todos puedan percibir.

Cuando el script falla, el formulario no debe fallar

El envío dentro de la página corre sobre JavaScript, y JavaScript es la capa menos fiable de cualquier página: los scripts los bloquean las redes corporativas estrictas, los rompe un error sin relación en otra parte de la página, o simplemente no llegan con una mala conexión. Un formulario que solo funciona cuando funciona su script tiene un modo de fallo silencioso dirigido exactamente a los visitantes menos equipados para diagnosticarlo.

La construcción honesta es un formulario real debajo: un formulario normal que envía de la manera tradicional por sí solo, con el comportamiento dentro de la página añadido encima cuando el script está presente y sano. Si el script carga, los visitantes reciben la experiencia tranquila sin recarga. Si no, el formulario igual envía y una página de confirmación simple igual responde. Nadie sostiene jamás un botón que no hace nada.

La misma humildad aplica a la propia red. Cuando un envío expira a mitad de camino, el formulario no puede saber si el mensaje llegó, así que debe decirlo con claridad, conservar el texto del visitante y ofrecer el reintento. Adivinar «éxito» cuando la verdad es «desconocido» es como las organizaciones acaban pidiendo disculpas por mensajes que nunca recibieron.

El botón de enviar es una promesa

Todo lo anterior es un principio vestido de cuatro maneras: en el momento en que alguien pulsa enviar, ha hecho su parte, y cada riesgo después de eso pertenece al formulario. Su trabajo está protegido, su incertidumbre está respondida, su fallo le cuesta como mucho un clic más. Consiga eso y el formulario se siente digno de confianza de una forma que los visitantes no pueden nombrar, que es la única forma en que la mayoría de la gente evalúa la competencia de una institución en línea.

Y cuando el estado de fallo se dispara, las palabras que usa importan tanto como la mecánica. Esa es la siguiente decisión de esta serie: mensajes de error que ayudan de verdad, en lugar de anunciar «no válido» y dejar al visitante adivinar cómo sería una vida válida.

Siga leyendo

6 de septiembre de 2026 8 minutos

Los cuatro archivos que nadie enlaza

Todo sitio web tiene cuatro archivos de texto plano que ningún visitante ve: robots.txt, sitemap.xml, security.txt y llms.txt. Los buscadores, los escáneres de seguridad y los agentes de IA los leen en cada visita. Qué es cada uno, quién lo lee de verdad, qué poner en él y la única regla que los mantiene a todos seguros. Esta semana repasamos la lista en nuestro propio sitio y encontramos huecos, así que la auditoría gratuita ahora los comprueba.

6 de septiembre de 2026 6 minutos

Nuestra imagen principal desaparecía en iPhone. Un bloqueador de anuncios la escondía.

Durante semanas, la imagen principal de tres de nuestras propias páginas desaparecía un segundo y medio en iPhone, solo en la primera carga. Nada lo reproducía en el laboratorio. Un rastreo de campo de cincuenta líneas lo encontró en tres cargas de página: un bloqueador de anuncios escondía cualquier elemento cuya clase empezara por ad-.

Todos los artículos →

Prefer to write?

Tell us what needs to work better.

Slow, fragile, hard to edit, missing a workflow. Say it plainly, and you'll get a straight answer, not a ticket number.

You'll get a straight answer, usually the same day.