¿Cómo utilizar Form, Input, Text Area, Select Input, Checkbox y Radio Button en el Editor de bloques de Waclis?
El Editor de bloques de Waclis cuenta con diferentes componentes que permiten construir y organizar formularios dentro de una Página web.
Dentro de:
Componentes → Base
encontrarás componentes como:
Form
Input
Text Area
Select Input
Checkbox
Radio Button
Html Button
Estos elementos permiten crear estructuras visuales para solicitar información a los visitantes.
Por ejemplo:
Nombre
[________________________]
[________________________]
Mensaje
[________________________]
[ ]
[________________________]
[ ENVIAR ]
También puedes construir formularios más completos:
Nombre
[________________________]
Empresa
[________________________]
[________________________]
¿Qué servicio te interesa?
[ Seleccionar ▼ ]
¿Cómo prefieres que te contactemos?
( ) Teléfono
[ ] Acepto la política correspondiente
[ ENVIAR CONSULTA ]
Pero antes de comenzar existe una diferencia fundamental que debes comprender.
Un formulario visible no significa necesariamente un formulario funcional
Agregar:
Form
Input
Text Area
Button
permite crear la estructura visual de un formulario.
Eso no significa automáticamente que al presionar:
[ ENVIAR ]
la información:
llegue a un correo;
se almacene;
genere un contacto;
cree una solicitud;
se envíe hacia otro sistema;
se procese mediante una integración.
La apariencia y el procesamiento son dos cosas diferentes
Podemos representarlo así:
FORMULARIO VISUAL
↓
campos + textos + botón
frente a:
FUNCIONAMIENTO DEL FORMULARIO
↓
recepción + procesamiento + destino de los datos
El Editor de bloques permite trabajar sobre la estructura visual.
Si ya existe un formulario funcional, debes conservar cuidadosamente su estructura y atributos.
Si estás creando uno desde cero, no deberías asumir que agregar los componentes visuales configura automáticamente su procesamiento.
Este es el principio más importante del tutorial
Nunca publiques un formulario dando por hecho que recibe consultas solamente porque visualmente permite completar campos y presionar un botón.
Después de crear o modificar un formulario debes probarlo realmente.
¿Qué función cumple cada componente?
Una guía rápida:
| Componente | Uso habitual |
|---|---|
| Form | Contenedor general del formulario |
| Input | Datos breves de una línea |
| Text Area | Textos más extensos |
| Select Input | Elegir una opción desde una lista |
| Checkbox | Seleccionar una o varias condiciones/opciones independientes |
| Radio Button | Elegir una opción entre varias alternativas relacionadas |
| Html Button | Acción del formulario, por ejemplo Enviar |
Estructura conceptual de un formulario
Un formulario simple puede organizarse:
Form
├── Campo Nombre
│ ├── Label
│ └── Input
├── Campo Email
│ ├── Label
│ └── Input
├── Campo Mensaje
│ ├── Label
│ └── Text Area
└── Html Button
Un formulario más completo
Form
├── Nombre
│ └── Input
├── Empresa
│ └── Input
│ └── Input
├── Servicio
│ └── Select Input
├── Medio de contacto
│ ├── Radio Button
│ └── Radio Button
├── Consentimiento
│ └── Checkbox
└── Html Button
La estructura exacta dependerá del formulario y del diseño utilizado.
Utiliza Navigator
En formularios, Navigator es especialmente importante.
Puede ayudarte a distinguir:
Form
de:
Input
o:
Button
y evitar que elimines o clones el nivel incorrecto.
Por ejemplo
Si haces clic visualmente sobre:
podrías estar seleccionando:
el texto;
el Input;
el contenedor del campo.
Si quieres duplicar todo el campo
deberías localizar la unidad correspondiente.
Conceptualmente:
Field
├── Label
└── Input
No clones solamente Input
si también necesitas:
Label
para el nuevo campo.
¿Qué es Form?
El componente:
Form
funciona como contenedor general de los campos relacionados.
Conceptualmente:
Form
├── Input
├── Input
├── Text Area
└── Button
No confundas Form con una Section
La Section organiza una parte general de la página.
El Form agrupa los campos que pertenecen al formulario.
Por ejemplo:
Section
└── Container
└── Grid Row
├── Column
│ ├── Heading
│ └── Paragraph
└── Column
└── Form
├── Input
├── Text Area
└── Button
Visualmente
┌─────────────────────────────────────────────┐
│ │
│ CONTÁCTANOS Nombre │
│ [____________________] │
│ Cuéntanos qué │
│ necesitas. Email │
│ [____________________] │
│ │
│ Mensaje │
│ [____________________] │
│ [____________________] │
│ │
│ [ ENVIAR ] │
│ │
└─────────────────────────────────────────────┘
No agregues un Form alrededor de otro Form sin comprender la estructura
Si una composición ya contiene un formulario funcional:
evita envolverlo dentro de un nuevo Form.
Antes de modificar un formulario existente
Utiliza Navigator y comprueba:
¿Ya existe Form?
Un formulario existente puede contener atributos importantes
Aunque visualmente no los notes, puede depender de:
nombres de campos;
tipos;
identificadores;
estructura;
comportamiento existente.
Por eso no deberías reconstruirlo desde cero solamente para cambiar
color;
Border radius;
separación;
Typography.
Para cambios visuales utiliza Estilo
¿Qué es Input?
El componente:
Input
se utiliza normalmente para solicitar información relativamente breve en una sola línea.
Ejemplos
Nombre
[________________________]
Empresa
[________________________]
[________________________]
Teléfono
[________________________]
Input es apropiado para datos cortos
Por ejemplo:
nombre;
apellido;
email;
teléfono;
empresa;
ciudad;
código;
asunto breve.
No utilices Input para textos extensos
Por ejemplo:
Cuéntanos detalladamente qué necesitas
[____________________________________________]
en una sola línea puede resultar incómodo.
Para eso utiliza:
Text Area
Input vs Text Area
INPUT
→ información corta
TEXT AREA
→ información extensa
Ejemplo
Incorrecto:
Describe tu proyecto
[____________________________________________]
si esperas varias frases.
Mejor:
Describe tu proyecto
[________________________________________]
[ ]
[ ]
[________________________________________]
Labels: identifica siempre qué debe completar el usuario
Una estructura clara:
Nombre
[________________________]
es mejor que:
[________________________]
sin ninguna indicación.
Label vs Placeholder
Puede existir texto dentro del campo que sugiera qué ingresar.
Por ejemplo:
Nombre
[ Escribe tu nombre ]
Aquí:
Nombre
funciona como identificación permanente.
Y:
Escribe tu nombre
puede ser una ayuda adicional.
No dependas únicamente del texto dentro del campo
Porque cuando el usuario empieza a escribir:
[ María González ]
esa indicación puede dejar de verse.
Por eso es recomendable que los campos importantes tengan una identificación clara
Ejemplo poco claro
[ Nombre ]
[ Email ]
[ Teléfono ]
sin ninguna otra referencia puede ser visualmente simple,
pero revisa cuidadosamente la experiencia real.
Ejemplo más claro
Nombre
[ Escribe tu nombre ]
[ nombre@empresa.com ]
Teléfono
[ Ingresa tu teléfono ]
No escribas instrucciones enormes dentro del campo
Por ejemplo:
[ Aquí debes escribir tu nombre completo incluyendo... ]
Utiliza una ayuda externa si necesitas explicar más
Tipos de información
Cuando construyes formularios, piensa primero:
¿Qué información necesitamos realmente?
No empieces agregando campos porque hay espacio.
Formulario de contacto simple
Puede necesitar:
Nombre
Mensaje
No siempre necesita
Nombre
Apellido
Empresa
Cargo
Teléfono
Celular
Dirección
Ciudad
País
Código postal
Sitio web
Cantidad de empleados
Industria
...
Cada campo adicional aumenta el esfuerzo
Por eso solicita solamente lo necesario para el objetivo.
¿Qué es Text Area?
Text Area permite incorporar un área para textos más extensos.
Puede utilizarse para
consulta;
mensaje;
descripción;
comentarios;
detalle del proyecto;
observaciones.
Ejemplo
Cuéntanos sobre tu proyecto
[____________________________________]
[ ]
[ ]
[ ]
[____________________________________]
No lo utilices para
o:
Nombre
si una línea es suficiente.
El tamaño visual debe corresponder a la cantidad de contenido esperada
Ejemplo
Si preguntas:
Comentarios adicionales
puede ser razonable un Text Area moderado.
Si preguntas:
Describe completamente el alcance técnico de un proyecto complejo
puede necesitar mayor espacio.
Pero tampoco conviertas medio sitio en un campo enorme
si normalmente los usuarios escribirán dos líneas.
Text Area y mobile
Comprueba:
ancho;
altura;
Padding;
Font size.
Debe ocupar correctamente el ancho de su columna
sin provocar scroll horizontal.
Evita Width rígido
Por ejemplo:
textarea {
width: 700px;
}
podría desbordar en celular.
Utiliza la estructura responsive
¿Qué es Select Input?
Select Input permite presentar una lista de opciones para que el usuario elija una.
Conceptualmente:
¿Qué servicio te interesa?
[ Selecciona una opción ▼ ]
Al abrirlo:
Diseño
Producción
Instalación
Consultoría
¿Cuándo utilizar Select?
Puede ser útil cuando:
existen varias alternativas;
el usuario debe escoger una;
quieres evitar que escriba distintas variantes del mismo dato.
Ejemplo
En lugar de:
Servicio
[ el usuario escribe cualquier cosa ]
puedes presentar:
Servicio
[ Seleccionar ▼ ]
Diseño
Producción
Instalación
Esto puede mejorar consistencia
si esas opciones son reales y están correctamente definidas.
No agregues opciones inventadas
La lista debe representar alternativas disponibles
Evita un Select con demasiadas opciones sin organización
Por ejemplo:
150 alternativas
puede resultar difícil de recorrer.
Si el contenido es muy extenso
puede requerirse otra estrategia.
Primera opción
Puede ser útil mostrar:
Selecciona una opción
para evitar que una alternativa real parezca elegida automáticamente.
Pero no asumas que ese texto configura por sí mismo validación
El comportamiento real dependerá de la estructura del formulario.
Select vs Radio Button
Supongamos tres alternativas:
Teléfono
Puedes utilizar:
[ Seleccionar ▼ ]
o:
( ) Teléfono
¿Cuál conviene?
Radio Button puede ser más claro cuando:
hay pocas opciones;
quieres que todas estén visibles.
Select puede ser más compacto cuando:
existen más alternativas;
no necesitas mostrar todas permanentemente.
No existe una regla absoluta
¿Qué es Checkbox?
Checkbox representa una casilla que puede marcarse o desmarcarse.
Conceptualmente:
[ ] Deseo recibir novedades
También:
[ ] Acepto la política correspondiente
cuando esa condición forme parte del flujo real y esté correctamente redactada.
Una Checkbox suele representar una decisión independiente
Por ejemplo:
[ ] Deseo recibir información comercial
puede activarse o no independientemente de otras opciones.
Varias Checkbox
También puedes presentar varias opciones independientes:
¿Qué temas te interesan?
[ ] Productos
[ ] Servicios
[ ] Novedades
[ ] Eventos
El usuario podría seleccionar:
una;
varias;
ninguna;
según la lógica del formulario.
Checkbox no es Radio Button
Checkbox
Conceptualmente:
puedo seleccionar varias
Radio Button
Conceptualmente:
elijo una alternativa del grupo
Ejemplo incorrecto
Pregunta:
¿Cómo prefieres que te contactemos?
y necesitas solamente una respuesta.
Si utilizas:
[ ] Teléfono
el usuario podría interpretar que puede elegir varias.
Puede ser más apropiado:
( ) Teléfono
si la lógica requiere una sola.
¿Qué es Radio Button?
Radio Button permite presentar alternativas relacionadas entre las que normalmente se elige una.
Ejemplo
¿Cómo prefieres que te contactemos?
( ) Teléfono
Otro ejemplo
Tipo de cliente
( ) Particular
( ) Empresa
Otro
Modalidad
( ) Presencial
( ) Virtual
si esas alternativas corresponden realmente al servicio.
Las opciones deben pertenecer al mismo grupo conceptual
Ejemplo incorrecto
( ) Empresa
( ) Argentina
No son alternativas equivalentes.
Cada grupo de Radio Button necesita una pregunta clara
Por ejemplo
Tipo de proyecto
( ) Nuevo
( ) Rediseño
( ) Ampliación
No utilices Radio Button como decoración
Checkbox vs Radio Button: regla rápida
CHECKBOX
→ Sí / No
→ o varias selecciones independientes
RADIO BUTTON
→ elegir una alternativa dentro de un grupo
Ejemplo Checkbox
[ ] Quiero recibir novedades
Ejemplo Radio
¿Horario preferido?
( ) Mañana
( ) Tarde
No confundas selección visual con funcionamiento real
Aunque puedas crear:
( ) A
( ) B
debes comprobar que la estructura funcional realmente los trate como opciones relacionadas si el formulario va a procesar datos.
Si estás modificando un Form que ya funciona
conserva los nombres y atributos internos relacionados con esos campos salvo que comprendas exactamente su función.
No renombres propiedades funcionales solamente para cambiar el texto visible
Texto visible vs valores internos
Un formulario puede contener:
Texto visible:
Empresa
y propiedades internas que el sistema utiliza para identificar ese campo.
Cambiar:
Empresa
por:
Organización
visualmente puede ser sencillo.
Pero si también modificas atributos internos sin necesidad:
podrías afectar el procesamiento existente.
Regla práctica
Para cambios visuales:
texto visible;
color;
Padding;
Border;
Font size;
evita tocar propiedades funcionales que no necesitas modificar.
Html Button dentro del Form
Un formulario normalmente necesita una acción.
Por ejemplo:
[ ENVIAR ]
Puede utilizarse:
Html Button
Como vimos en el tutorial de Links y botones, Html Button incluye propiedades como:
Text;
Name;
Type;
Autofocus;
Disabled.
En formularios, Type es especialmente importante
Si un Form ya funciona:
no cambies Type sin comprender qué función cumple.
Para modificar:
Enviar
por:
Enviar consulta
utiliza Text.
Para cambiar:
color;
Border radius;
Padding;
utiliza Estilo.
No cambies propiedades funcionales para realizar modificaciones visuales.
No envuelvas automáticamente el Button de envío en un Link
Este error puede romper la lógica del formulario.
Un Button de navegación
puede estar dentro de:
Link
Un Button de formulario
puede necesitar ejecutar:
envío del Form
Son acciones diferentes.
No configures una Url solamente porque quieres que el botón “funcione”
Primero identifica qué debe ocurrir
Formulario de contacto vs CTA hacia contacto
Son cosas diferentes.
CTA
[ CONTACTAR ]
puede llevar hacia:
/contacto
Formulario
Nombre
Mensaje
[ ENVIAR ]
necesita un mecanismo de procesamiento.
No confundas ambos.
Formulario visual sin procesamiento
Puedes construirlo visualmente, pero antes de publicarlo debes confirmar:
¿Qué ocurre al enviarlo?
Algunas respuestas posibles
se procesa mediante una funcionalidad existente;
forma parte de un Form ya configurado;
todavía no existe procesamiento.
Si no existe procesamiento
no presentes el formulario como operativo.
Formulario de contacto prediseñado vs componentes manuales
Waclis también cuenta con la sección:
Formularios de contacto
dentro de la biblioteca de Secciones.
Esa sección puede ser un punto de partida para una composición completa.
En cambio los componentes:
Form
Input
Text Area
...
permiten construir o modificar estructuras manualmente.
Utiliza el nivel apropiado
Si necesitas un formulario completo:
puede ser más sencillo partir de una sección prediseñada.
Si necesitas agregar un nuevo campo
puede ser útil trabajar con componentes individuales.
Pero recuerda
agregar visualmente un campo adicional a un formulario que ya procesa información no garantiza que el backend o mecanismo existente vaya a recibir ese nuevo dato.
Este es otro punto fundamental
Supongamos que un formulario funcional procesa:
Nombre
Mensaje
y agregas visualmente:
Empresa
Es posible que la nueva información:
Empresa
no sea procesada automáticamente por el mecanismo existente.
Por eso, después de agregar campos a un Form funcional:
prueba que el dato adicional realmente se reciba donde corresponde.
No basta con comprobar que puede escribirse.
Ejemplo práctico: formulario simple
Queremos:
CONTÁCTANOS
Nombre
[________________________]
[________________________]
Mensaje
[________________________]
[ ]
[________________________]
[ ENVIAR CONSULTA ]
Estructura conceptual
Section
└── Container
└── Form
├── Nombre
│ └── Input
│ └── Input
├── Mensaje
│ └── Text Area
└── Html Button
Paso 1
Agrega o selecciona:
Form
Paso 2
Utiliza Navigator para confirmar dónde quedó ubicado.
Paso 3
Agrega:
Input
para Nombre.
Paso 4
Identifica visualmente el campo mediante texto correspondiente.
Paso 5
Agrega otro:
Input
para Email.
Paso 6
Agrega:
Text Area
para Mensaje.
Paso 7
Agrega o configura:
Html Button
Paso 8
Modifica Text:
Enviar consulta
Paso 9
Personaliza:
Width;
Padding;
Border;
Border radius;
Typography.
Paso 10
Revisa mobile.
Paso 11
Confirma cómo se procesará el Form.
Paso 12
Guardar Cambios.
Paso 13
Ver página.
Paso 14
Completa una consulta de prueba.
Paso 15
Confirma que los datos realmente lleguen al destino previsto.
El paso 15 es obligatorio para considerar funcional el formulario
Ejemplo práctico: formulario con Select
Queremos:
Nombre
[________________________]
[________________________]
Servicio
[ Seleccionar ▼ ]
Mensaje
[________________________]
[________________________]
[ ENVIAR ]
La pregunta podría ser
¿Qué servicio te interesa?
Las opciones deberían corresponder a servicios reales.
Por ejemplo:
Diseño
Implementación
Capacitación
Soporte
No agregues
Otro
si después no existe forma de aclarar qué significa.
Si utilizas Otro
puedes considerar un campo adicional:
Cuéntanos qué necesitas
cuando corresponda.
Ejemplo práctico: Checkbox
[ ] Deseo recibir novedades por email
Esta opción debería ser:
clara;
separada de otras decisiones;
comprensible.
No preselecciones visualmente una opción sensible o comercial solo para aumentar conversiones
si no corresponde a tu flujo o requisitos.
Privacidad y consentimiento
Cuando un formulario recopila datos personales, debes considerar:
qué información se solicita;
para qué;
dónde se envía;
si el visitante necesita conocer alguna política;
qué consentimientos corresponden al caso.
Este tutorial no sustituye asesoramiento legal
Las obligaciones pueden variar según:
país;
actividad;
tipo de información;
tratamiento de datos.
No copies una casilla de consentimiento de otro sitio
sin saber si el texto corresponde a tu caso.
Tampoco agregues:
Acepto todos los términos
si no existe ningún contenido al que pueda acceder el usuario.
Si mencionas una política
por ejemplo:
He leído la Política de privacidad
debería existir un acceso real a esa política cuando corresponda.
No crees un Link falso
Formularios y datos mínimos
Antes de agregar un campo pregunta:
¿Realmente necesitamos este dato para responder la consulta?
Formulario simple
Nombre
Mensaje
puede ser suficiente.
Formulario comercial
Puede requerir:
Nombre
Empresa
Teléfono
Servicio
Mensaje
Pero no existe una estructura universal.
Reduce fricción
Cada campo adicional requiere una acción del usuario.
Evita solicitar datos que ya puedes obtener después
si no son necesarios en la primera interacción.
Campos obligatorios
Un formulario puede necesitar distinguir información imprescindible de opcional.
Pero no deberías marcar visualmente un campo como obligatorio si la funcionalidad real permite enviarlo vacío sin ningún control y luego asumir que está validado.
La indicación visual y la validación real deben ser coherentes
Por ejemplo
Email *
comunica que es requerido.
Pero debes probar:
¿Qué ocurre si se intenta enviar vacío?
No asumas que agregar:
*
crea validación.
Un asterisco es solamente una indicación visual
si no existe comportamiento funcional asociado.
Lo mismo ocurre con mensajes como
Campo obligatorio
Deben reflejar el funcionamiento real.
Validación visual vs validación funcional
Puedes diseñar:
Email incorrecto
en rojo.
Pero eso no crea automáticamente una validación de email.
No simules mensajes de error
si el Form no posee lógica para generarlos.
Formulario funcional existente
Si ya tiene:
validaciones;
mensajes;
comportamiento;
conserva su estructura.
No elimines Classes o atributos internos
para “simplificar” el HTML.
Campos de email
Aunque un Input pueda configurarse para diferentes propósitos, no inventaremos en este tutorial controles exactos que no se hayan verificado en el editor.
Cuando trabajes con un formulario existente:
revisa las opciones disponibles dentro de Contenido para el Input seleccionado y conserva cualquier configuración funcional necesaria.
Campos de teléfono
Mismo principio.
Campos numéricos
Mismo principio.
No asumas que cambiar el texto visible cambia el tipo funcional del campo
Ejemplo
Cambias:
Nombre
a:
visualmente.
Eso no garantiza que el Input quede configurado funcionalmente como email.
Si el tipo del campo importa
debes revisar su configuración real.
Clonar un campo
Supongamos:
Nombre
[________________]
y quieres agregar:
Empresa
[________________]
Procedimiento recomendado
abre Navigator;
selecciona el contenedor completo de Nombre;
clónalo;
cambia el Label;
revisa el Input;
revisa cualquier propiedad funcional;
revisa ID;
revisa Name u otros atributos si existen y cumplen una función;
prueba el Form.
No clones solamente Input
si quieres conservar:
Label;
espacio;
estilo.
No dejes propiedades de Nombre en Empresa
si el procesamiento depende de ellas.
Este punto es especialmente importante
Dos campos visualmente distintos pueden terminar enviando:
el mismo identificador
si clonaste sin revisar.
No cambies propiedades a ciegas
pero tampoco las dejes duplicadas sin comprobar.
Si el formulario ya está integrado
consulta o verifica qué identificadores espera el procesamiento antes de modificarlos.
Clonar Checkbox
También requiere cuidado.
Ejemplo
Original:
[ ] Quiero recibir novedades
Copia:
[ ] Quiero recibir promociones
Debes revisar que no compartan incorrectamente propiedades destinadas a una única opción si el formulario las procesa.
Clonar Radio Button
Todavía más importante.
Los Radio Button que forman parte de una misma pregunta deben mantenerse relacionados funcionalmente.
Por ejemplo
Contacto preferido
( ) Teléfono
deberían comportarse como un conjunto.
Si clonas una opción
comprueba que forme parte del grupo correcto.
No inventes la configuración interna
Si necesitas modificar grupos funcionales complejos, revisa la estructura existente antes de cambiar atributos.
Eliminar un campo
Selecciona la unidad correcta.
Si quieres retirar:
Empresa
no elimines:
Form
completo.
Navigator puede mostrar:
Form
├── Field Nombre
├── Field Empresa
├── Field Email
└── Button
Selecciona:
Field Empresa
Recuerda
Waclis no solicita confirmación al eliminar.
Si eliminas algo incorrecto:
Deshacer
Después de eliminar un campo
prueba nuevamente el formulario.
No asumas que retirar visualmente un campo no afecta el procesamiento existente
si esa información era necesaria.
Mover campos
Puedes reorganizar:
Nombre
Empresa
a:
Nombre
Empresa
Pero piensa en el recorrido lógico.
Orden recomendado
Normalmente conviene comenzar con datos fáciles y comprensibles.
Por ejemplo:
Nombre
Servicio
Mensaje
Evita empezar con una pregunta compleja
si todavía no existe contexto.
Orden y agrupación
Un formulario extenso puede organizarse conceptualmente:
DATOS PERSONALES
Nombre
Teléfono
PROYECTO
Servicio
Descripción
PREFERENCIAS
Medio de contacto
Pero si el formulario es corto
no agregues demasiados subtítulos.
Dos campos en una fila
Puedes utilizar Grid Row.
Por ejemplo:
Desktop
Nombre Apellido
[______________] [______________]
Conceptualmente:
Grid Row
├── Column 6
│ └── Campo Nombre
└── Column 6
└── Campo Apellido
Mobile
debería poder convertirse en:
Nombre
[________________]
Apellido
[________________]
No utilices Width 48 % manual como primera solución
Utiliza Grid Row
Tres campos en una fila
Puede ser posible en desktop, pero pregunta si realmente hay suficiente espacio.
Por ejemplo:
Nombre | Email | Teléfono
puede quedar demasiado comprimido.
Formularios suelen beneficiarse de más espacio que Cards simples
No sacrifiques claridad para reducir altura.
Campo de ancho completo
Puede utilizar:
12 unidades
conceptualmente.
Por ejemplo
Text Area:
Mensaje
[________________________________________]
[________________________________________]
puede ocupar todo el ancho.
Grid mixto
Nombre Email
[________] [________]
Servicio
[________________________]
Mensaje
[________________________]
[________________________]
Puede utilizar:
Fila 1
6 + 6
Fila 2
12
Fila 3
12
Este patrón es muy útil
Responsive en formularios
Siempre revisa:
Label;
campos;
Checkbox;
Radio Button;
Button.
Desktop
Nombre Email
[_______] [_______]
Mobile
Nombre
[________________]
[________________]
No mantengas dos campos estrechos
si:
Label se corta;
usuario no puede leer;
teclado ocupa mucho espacio.
Checkbox responsive
Texto largo:
[ ] Confirmo que he leído y comprendido...
puede ocupar varias líneas.
Asegúrate de que la casilla siga alineada correctamente con el texto.
No utilices Height fija
sobre el contenedor del Checkbox.
Radio responsive
Ejemplo desktop:
( ) Email ( ) Teléfono ( ) WhatsApp
Mobile puede necesitar:
( ) Teléfono
No reduzcas Font size excesivamente para mantener todo en una sola línea.
Button responsive
Puede ocupar:
[ ENVIAR CONSULTA ]
En mobile puede ser conveniente darle mayor ancho si mejora la interacción,
pero no es obligatorio.
Revisa el contexto.
Formulario junto a información de contacto
Una composición útil:
[ DATOS DE CONTACTO ][ FORMULARIO ]
Conceptualmente:
Grid Row
├── Column 5
│ ├── Heading
│ ├── Paragraph
│ └── datos
└── Column 7
└── Form
Mobile:
DATOS
FORMULARIO
O:
FORMULARIO
DATOS
según el recorrido deseado.
Revisa el orden real mediante Navigator.
Formulario demasiado ancho
Un formulario de:
100 % de una pantalla de 1900 px
puede producir campos incómodamente largos.
Puedes utilizar:
Container;
Grid Column;
Max Width;
para controlar la lectura.
No siempre necesitas ocupar toda la pantalla.
Formulario demasiado estrecho
Tampoco:
250 px
para campos como email o mensaje,
si existe espacio disponible.
Busca equilibrio.
Estilo de Inputs
Puedes personalizar mediante:
Estilo
aspectos como:
Size;
Margin;
Padding;
Border;
Border radius;
Background;
Text Color;
según el elemento seleccionado.
Mantén coherencia
Todos los Inputs equivalentes deberían compartir:
altura visual;
borde;
Padding;
Typography.
Linked styles puede ser útil
Por ejemplo:
form-field
como Class compartida.
Así:
Nombre
Teléfono
pueden mantener el mismo diseño.
No estilices cada Input manualmente de forma diferente
sin una razón.
Focus
Los campos interactivos necesitan permitir al usuario comprender cuál está utilizando.
Si personalizas CSS avanzado
no elimines indiscriminadamente indicadores visuales de foco.
Por ejemplo evita reglas globales como:
input:focus,
textarea:focus {
outline: none;
}
sin proporcionar una alternativa adecuada.
El usuario necesita reconocer el campo activo.
Hover no es el estado principal de un Input
Los usuarios interactúan mediante:
clic;
teclado;
foco.
No construyas una experiencia donde el campo solo sea reconocible al pasar el mouse.
Background
Un Input puede utilizar:
blanco;
gris muy suave;
transparente;
según el diseño.
Pero debe distinguirse del fondo de la página.
Ejemplo problemático
Input blanco sin borde
sobre
fondo blanco
puede desaparecer visualmente.
Puedes utilizar:
Border;
Background diferente.
Contraste del texto
El contenido ingresado debe ser legible.
También la ayuda dentro del campo debería distinguirse,
sin confundirse con datos ya escritos.
No utilices gris extremadamente claro
que resulte difícil de leer.
Border radius
Puedes utilizar el mismo sistema visual que en Buttons.
Por ejemplo:
Input → 8 px
Button → 8 px
puede generar coherencia.
No es obligatorio que sean idénticos
pero deberían pertenecer al mismo lenguaje visual.
Espacio entre Label y campo
Conceptualmente:
Nombre
pequeño espacio
[________________]
Espacio entre campos
debería ser mayor:
Nombre
[________________]
[________________]
Esto ayuda a reconocer grupos.
No utilices <br> repetidos o espacios manuales como primera solución
Utiliza:
Margin;
Padding;
estructura.
Text Area y Height
Una altura inicial puede ser útil.
Pero no fijes una Height tan rígida que:
corte contenido;
dificulte escribir;
falle en mobile.
Select y ancho
La opción seleccionada debería entrar razonablemente.
Ejemplo
Si el Select mide muy poco:
[ Implementac... ▼ ]
puede ser difícil comprender la opción.
Ajusta el ancho de la estructura.
Checkbox y textos extensos
Utiliza una estructura flexible.
Evita que el texto quede:
[ ]
Acepto...
con desalineaciones excesivas.
Radio Button y espacio
Las opciones relacionadas deben verse como un grupo,
pero no pegadas entre sí.
No uses grandes espacios manuales
Classes para formularios
En una personalización avanzada puedes utilizar Classes conceptuales como:
contact-form
form-group
form-label
form-control-custom
form-checkbox
form-radio
form-submit
Estos nombres son ejemplos
No representan Classes obligatorias de Waclis.
CSS localizado
Por ejemplo:
.contact-section .form-control-custom {
width: 100%;
padding: 12px 14px;
border-radius: 8px;
}
Text Area
.contact-section textarea.form-control-custom {
min-height: 140px;
}
Button
.contact-section .form-submit {
padding: 12px 24px;
}
Evita CSS global
No utilices:
input {
width: 100%;
}
sin evaluar todo el sitio.
Podría afectar:
buscadores;
filtros;
cantidades;
campos internos;
otros Forms.
Tampoco:
textarea {
height: 200px;
}
globalmente.
Tampoco:
select {
border-radius: 20px;
}
si solo quieres modificar Contacto.
Tampoco:
input[type="checkbox"] {
width: 30px;
}
sin scope.
Esto puede afectar otros componentes.
Utiliza:
.contact-section input...
o una Class específica.
Especial cuidado con .form-control
Una Class de formulario puede utilizarse en muchas partes.
Evita sobrescribirla globalmente
si no quieres modificar:
newsletter;
contacto;
buscadores;
otros componentes.
Utiliza un scope raíz
Por ejemplo:
contact-section
Después:
.contact-section .form-control {
...
}
cuando corresponda a la estructura real.
No elimines Classes existentes
Si un Form funcional ya contiene Classes:
conserva las que no comprendas.
Puedes agregar una Class propia
sin borrar la estructural.
IDs en formularios
Los IDs deben mantenerse únicos.
Si clonas:
id="email"
no dejes dos elementos con el mismo ID.
Pero cuidado
No modifiques IDs funcionales de un formulario existente sin comprender si algún comportamiento depende de ellos.
Si necesitas una personalización visual individual
puedes usar una Class adicional siempre que sea suficiente.
Name y otros atributos funcionales
Mismo principio.
No cambies propiedades internas simplemente para que “se vean más prolijas”.
El navegador no muestra muchas de esas propiedades al usuario,
pero el procesamiento puede necesitarlas.
HTML del Form
Para usuarios avanzados puede ser útil utilizar:
Editar código HTML <>
sobre un elemento concreto.
Puede ayudarte a identificar:
Form
Input
Name
Type
ID
Button
Pero no necesitas abrir HTML para cambiar:
color;
Border radius;
Padding;
texto visible.
Utiliza primero:
Contenido y Estilo
Code editor global
Tampoco debería utilizarse como primera opción.
Un cambio simple de:
Mensaje
a:
Cuéntanos sobre tu proyecto
no necesita Code editor.
JavaScript
No agregues JavaScript simplemente para hacer que un formulario “parezca funcionar”.
Si necesitas procesamiento real
debe existir una implementación apropiada.
Un script improvisado puede generar:
pérdida de datos;
errores;
problemas de seguridad;
comportamiento inconsistente.
No inventes un endpoint de envío
No coloques credenciales en el HTML
Este punto es crítico.
Nunca agregues dentro del código público:
contraseñas;
tokens privados;
claves secretas;
credenciales de servicios.
El código de una Página web puede ser visible para los visitantes.
Si una integración necesita credenciales privadas
deben manejarse del lado correspondiente de la aplicación o servicio,
no dentro de un bloque público.
Formularios y seguridad
No asumas que un campo de formulario protege o valida información simplemente porque existe.
Especialmente en formularios que manejan datos sensibles
debes utilizar funcionalidades apropiadas.
No utilices el Editor de bloques para solicitar información que no deberías recopilar mediante un formulario público sin una razón y protección adecuadas.
Solicita únicamente los datos necesarios
No pidas contraseñas
mediante un formulario genérico de contacto.
Tampoco datos altamente sensibles
sin una implementación específicamente preparada para ello.
Mensaje después del envío
Un formulario funcional suele necesitar comunicar qué ocurrió.
Por ejemplo:
Gracias. Recibimos tu consulta.
Pero no agregues ese mensaje visible permanentemente debajo del Form
como si confirmara un envío que aún no ocurrió.
Debe aparecer como parte del funcionamiento real
si la implementación lo contempla.
No simules estados
Error visual
Lo mismo ocurre con:
Hubo un error. Intenta nuevamente.
No lo muestres por defecto.
Estados reales requieren lógica real
Botón “Enviando...”
Tampoco agregues:
[ ENVIANDO... ]
como comportamiento ficticio.
Puede utilizarse si la funcionalidad real lo gestiona.
Formularios y spam
Un formulario público puede recibir envíos no deseados.
El diseño visual por sí solo no resuelve:
spam;
bots;
abuso.
Si existe una necesidad de protección
debe resolverse mediante la funcionalidad correspondiente.
No inventes un campo oculto manual esperando que automáticamente proteja el formulario
sin comprender la implementación.
Newsletter vs Formulario de contacto
También son diferentes.
Newsletter
normalmente busca:
[____________]
[ SUSCRIBIRME ]
Contacto
puede solicitar:
Nombre
Mensaje
No conviertas un Form de Contacto en Newsletter solamente cambiando el texto del Button.
El destino de los datos también debe corresponder.
Formulario de búsqueda
Un buscador también puede utilizar elementos que visualmente se parecen a Inputs y Buttons.
No lo trates como Form de Contacto.
Puede tener una lógica específica.
Si modificas componentes existentes de:
búsqueda;
filtros;
carrito;
hazlo con especial cuidado.
No apliques CSS global pensando únicamente en Contacto.
Formularios y autofill del navegador
El navegador puede completar ciertos datos en determinadas estructuras.
No diseñes el campo suponiendo que siempre estará vacío.
Comprueba cómo se ve con contenido ingresado.
Input con texto real
Prueba:
maria.gonzalez@empresa-internacional.com
No solamente:
a@b.com
Diseña con datos realistas
Nombres largos
Prueba:
María de los Ángeles Fernández Rodríguez
Empresas largas
Servicios Industriales Internacionales S.A.
El campo debe permitir visualizar el contenido razonablemente.
Responsive con teclado móvil
En celular, el teclado ocupará gran parte de la pantalla.
Mantén:
campos suficientemente altos;
espacios adecuados;
Labels visibles.
No reduzcas Inputs a una altura mínima solamente para que el Form se vea más compacto.
Formulario de una sola columna
Suele ser una alternativa muy robusta:
Nombre
[________________]
[________________]
Teléfono
[________________]
Mensaje
[________________]
[________________]
[ ENVIAR ]
Especialmente en mobile.
Dos columnas
Puede ahorrar espacio en desktop:
Nombre Email
[___________] [___________]
Empresa Teléfono
[___________] [___________]
Mensaje
[____________________________]
[____________________________]
Pero revisa la secuencia de lectura.
No mezcles campos sin relación solamente para llenar una fila.
Por ejemplo:
Nombre | Mensaje
puede generar una composición extraña.
Agrupa lógicamente.
Formulario dentro de Card
Puede utilizarse:
╭──────────────────────────────╮
│ │
│ SOLICITA INFORMACIÓN │
│ │
│ Nombre │
│ [____________________] │
│ │
│ Email │
│ [____________________] │
│ │
│ [ ENVIAR ] │
│ │
╰──────────────────────────────╯
Card puede tener:
Background;
Border;
Border radius;
Padding.
No agregues Padding enorme a cada Input
para crear separación entre el Form y la Card.
Trabaja cada nivel correctamente.
Formulario sobre Background Image
Puede verse atractivo,
pero comprueba:
contraste;
legibilidad;
bordes de los Inputs.
Si la imagen tiene mucho detalle
los campos pueden confundirse.
Puede ser preferible:
Overlay;
Card opaca;
fondo simple.
Prioriza completar el formulario
por encima del efecto visual.
Formulario en modal o componente interactivo
Si ya existe dentro de una estructura interactiva:
no rompas IDs;
no elimines controles;
no cambies atributos funcionales sin necesidad.
El Form puede depender de la estructura del componente.
Ejemplo práctico: agregar Empresa a un Form existente
Supongamos que ya funciona:
Nombre
Mensaje
Enviar
y necesitas:
Empresa
Paso 1
Antes de modificar, prueba el Form existente.
Paso 2
Confirma que actualmente funciona.
Paso 3
Abre Navigator.
Paso 4
Identifica una unidad:
Label + Input
similar a la que quieres agregar.
Paso 5
Clona la unidad completa.
Paso 6
Cambia el Label:
Empresa
Paso 7
Revisa las propiedades del Input clonado.
Paso 8
No dejes IDs duplicados.
Paso 9
Si existen propiedades que participan del procesamiento, asegúrate de que la funcionalidad esté preparada para recibir Empresa.
Paso 10
Guardar Cambios.
Paso 11
Ver página.
Paso 12
Envía:
Empresa de prueba
Paso 13
Comprueba si ese dato realmente llega al destino.
Si no llega
la modificación visual no fue suficiente.
No declares el campo funcional hasta resolver el procesamiento.
Ejemplo práctico: cambiar únicamente estilos
Si el formulario ya funciona y solo quieres:
Inputs más altos;
bordes redondeados;
Button de marca;
no reconstruyas nada.
Selecciona los elementos existentes
y personaliza:
Estilo
Mantén:
Form;
Input;
atributos;
Button funcional.
Esta es normalmente la alternativa más segura.
¿Qué hacer si el Button se ve bien pero no envía?
Revisa:
si el formulario funcionaba antes;
estructura de Form;
Button;
Type;
cambios de HTML;
procesamiento existente.
No agregues Link alrededor del Button
como solución.
Eso podría simplemente navegar a otra página sin enviar los datos.
¿Qué hacer si el Form funcionaba y dejó de hacerlo después de modificar estilos?
Los cambios puramente visuales normalmente no deberían requerir modificar:
Type;
Name;
IDs funcionales;
estructura.
Revisa si accidentalmente cambiaste algo adicional.
¿Qué hacer si el Form nunca funcionó?
Entonces no deberías asumir que el problema está en el Button.
Puede no existir procesamiento configurado.
Necesitas determinar primero:
¿Qué mecanismo debería recibir esos datos?
El Editor de bloques por sí mismo no debería presentarse como responsable de crear ese mecanismo automáticamente.
¿Qué hacer si necesito solamente mostrar campos de ejemplo?
Si forman parte de:
una demostración;
una maqueta;
una explicación;
deja claro que no son un formulario operativo si el visitante pudiera confundirse.
No presentes interfaces falsas como funcionales.
¿Qué hacer si quiero solicitar cinco opciones y permitir varias?
Checkbox puede ser apropiado.
¿Qué hacer si solo puede elegir una?
Radio Button.
¿Qué hacer si tengo diez opciones y quiero ahorrar espacio?
Select puede ser más compacto.
Pero analiza la facilidad de uso.
¿Qué hacer si necesito una respuesta larga?
Text Area.
¿Qué hacer si necesito una respuesta corta?
Input.
¿Qué hacer si necesito solo un sí/no?
Puede utilizarse una Checkbox en determinados casos.
Por ejemplo:
[ ] Deseo recibir novedades
Si necesitas obligatoriamente elegir entre dos respuestas explícitas
puede ser más claro:
( ) Sí
( ) No
dependiendo de la pregunta.
¿Qué hacer si quiero marcar obligatorio con *?
Puedes indicarlo visualmente,
pero prueba que exista validación real.
No confundas símbolo con funcionalidad.
¿Qué hacer si el usuario puede enviar vacío?
Entonces la validación real no está funcionando como esperabas.
Corrige la funcionalidad antes de confiar en el indicador visual.
¿Qué hacer si el mensaje es demasiado corto?
Si necesitas un mínimo de información, eso requiere una regla funcional correspondiente.
No agregues simplemente:
Mínimo 100 caracteres
si el Form permite enviar 2.
La ayuda debe coincidir con la validación real.
¿Qué hacer si quiero limitar cantidad de caracteres?
Debe existir un comportamiento funcional que lo implemente.
No simules el límite visualmente.
¿Qué hacer si Select permite enviar la opción de ejemplo?
Prueba el formulario.
No asumas que:
Selecciona una opción
es automáticamente inválida.
¿Qué hacer si los Radio permiten seleccionar varios?
Probablemente debes revisar su agrupación funcional.
No intentes resolverlo con CSS.
CSS cambia apariencia,
no la lógica de agrupación.
¿Qué hacer si Checkbox no se puede seleccionar?
Revisa:
estructura;
Disabled si existe;
elemento superpuesto;
HTML.
No agregues JavaScript automáticamente.
¿Qué hacer si al hacer clic en el texto no se marca la casilla?
Puede depender de cómo está asociada la etiqueta en la estructura.
Si el Form existente ya lo resolvía
conserva esa estructura.
Si estás construyéndolo manualmente y necesitas una experiencia accesible más compleja
puede requerir revisar el HTML específico.
¿Qué hacer si el campo queda debajo de otro elemento?
Revisa:
Grid;
Width;
Position;
z-index si existe una superposición.
No muevas Input con:
top: 80px;
left: 100px;
como primera solución.
¿Qué hacer si todo el Form desborda?
Revisa:
Container;
Grid Column;
Width de Inputs;
Width de Text Area;
Margin;
Padding.
No ocultes overflow.
¿Qué hacer si solo un Input desborda?
Revisa su estilo particular o Class.
¿Qué hacer si cambiar un Border cambia todos?
Puede deberse a:
Linked styles
Si todos los campos deben verse iguales
es correcto.
¿Qué hacer si uno necesita una excepción?
Agrega una Class adicional.
No elimines la Class general.
¿Qué hacer si un Checkbox queda enorme por CSS?
Busca selectores globales como:
input {
width: 100%;
}
Esa regla también puede estar afectando:
checkbox
Este es un error clásico.
No todos los Input deberían recibir necesariamente el mismo Width
Un selector más preciso puede ser necesario.
¿Qué hacer si Radio Button también se estira?
Mismo problema.
Por eso evita CSS global sobre:
input
sin distinguir tipos y scope.
¿Qué hacer si el botón se ve como un Input?
Puede existir una regla global sobre:
input,
button
Revisa el alcance.
IA para diseñar un formulario simple
Puedes utilizar ChatGPT, Claude o Gemini.
Por ejemplo:
Necesito definir un formulario de contacto para una Página web.
Objetivo:
[objetivo]
Información que realmente necesitamos:
[datos]
Propón una estructura mínima utilizando únicamente:
- Input;
- Text Area;
- Select;
- Checkbox;
- Radio Button cuando corresponda.
No inventes datos que no necesitemos.
No agregues campos solo para hacerlo más completo.
IA para decidir tipo de campo
Tengo que solicitar esta información:
[lista]
Clasifica cada dato como:
- Input;
- Text Area;
- Select;
- Checkbox;
- Radio Button.
Explica brevemente por qué.
No agregues nuevos campos.
IA para reducir un formulario
Este formulario tiene estos campos:
[lista]
El objetivo es:
[objetivo]
Identifica qué campos parecen indispensables para la primera consulta y cuáles podrían solicitarse posteriormente.
No elimines automáticamente ninguno.
Solo explica el costo/beneficio de cada uno.
IA para redactar Labels
Tengo estos campos:
[lista]
Redacta Labels breves y claros en español neutro.
Evita tecnicismos.
No cambies el significado de los datos solicitados.
IA para redactar ayuda
Campo:
[Nombre del campo]
Necesito una ayuda breve para explicar qué debe ingresar el usuario.
Máximo 8 palabras.
No repitas exactamente el Label.
No inventes requisitos.
IA para revisar Checkbox de consentimiento
Puedes utilizar IA para mejorar claridad,
pero no para determinar si el texto cumple jurídicamente con tus obligaciones.
Por ejemplo:
Este es un texto de consentimiento ya aprobado por nuestro equipo responsable:
[texto]
Necesito simplificar únicamente su presentación visual sin cambiar su significado.
Señala cualquier modificación que pueda alterar el sentido.
No agregues condiciones legales nuevas.
No le pidas a la IA:
Créame un consentimiento legal universal que sirva para todos los países.
Las obligaciones pueden variar.
IA para diagnosticar un Form existente
Este es únicamente el HTML de un formulario de Waclis que actualmente funciona:
[pegar Form]
Necesito identificar:
- Form;
- Inputs;
- Text Area;
- Select;
- Checkbox;
- Radio;
- Button;
- type;
- name;
- ids;
- classes.
No modifiques nada.
Señala qué atributos parecen funcionales y cuáles son puramente visuales.
IA para agregar un campo sin romper el Form
Tengo este Form funcional:
[pegar HTML]
Quiero agregar visualmente un campo Empresa.
Antes de generar cambios:
1. identifica un campo existente equivalente que pueda servir como estructura;
2. señala qué IDs no deberían duplicarse;
3. señala qué names o atributos necesitarían coordinación con el procesamiento;
4. no asumas que el backend recibirá Empresa automáticamente.
No modifiques todavía el código.
Este prompt es especialmente seguro
porque obliga a diferenciar frontend de procesamiento.
IA para detectar CSS global peligroso
Revisa este CSS de Waclis:
[pegar]
Busca reglas globales que puedan afectar formularios, especialmente:
input
textarea
select
button
.form-control
input[type="checkbox"]
input[type="radio"]
Indica cuáles podrían afectar otros formularios, buscadores o controles de la Página web.
No modifiques el código.
IA para CSS localizado
Estoy personalizando un formulario en Waclis.
La sección utiliza:
.contact-section
El formulario:
.contact-form
Los campos de texto:
.contact-field
El botón:
.contact-submit
Necesito:
- campos al 100 % de su columna;
- Padding cómodo;
- Border radius de 8 px;
- mismo estilo visual;
- Text Area con mayor altura;
- Button responsive;
- no modificar otros Forms, buscadores o filtros.
Waclis utiliza Bootstrap 4.
No cambies HTML.
No agregues JavaScript.
Devuélveme solamente CSS limitado a .contact-section.
IA para responsive
Tengo este Form:
Fila 1:
Nombre | Email
Fila 2:
Empresa | Teléfono
Fila 3:
Mensaje
Desktop debe mantener dos columnas en las dos primeras filas.
Mobile debe mostrar todos los campos uno debajo del otro.
Explícame cómo resolverlo mediante Grid Row.
Waclis utiliza Bootstrap 4.
No utilices Width fijo.
No agregues JavaScript.
IA para revisar funcionamiento después de un cambio
Antes de modificar este Form funcionaba.
Después cambié:
[detallar]
Ahora el Button no envía.
HTML antes:
[pegar]
HTML después:
[pegar]
Compara únicamente:
- estructura Form;
- type del Button;
- name;
- id;
- campos;
- elementos eliminados.
No propongas un backend nuevo.
Busca primero qué cambio pudo romper el funcionamiento existente.
IA para auditar información solicitada
Este formulario público solicita:
[lista de campos]
Clasifica:
- datos necesarios para responder la consulta;
- datos posiblemente opcionales;
- datos que parecen excesivos para el objetivo indicado.
Objetivo del Form:
[objetivo]
No hagas afirmaciones legales.
No inventes requisitos regulatorios.
Buenas prácticas para Form y campos
Recomendamos:
diferenciar apariencia y procesamiento;
comprobar que el Form realmente funcione;
utilizar Form como contenedor general;
utilizar Input para datos cortos;
utilizar Text Area para mensajes extensos;
utilizar Select para listas de opciones;
utilizar Checkbox para decisiones independientes;
utilizar Radio Button para alternativas relacionadas;
identificar claramente cada campo;
solicitar solamente información necesaria;
organizar campos lógicamente;
utilizar Grid Row para varias columnas;
adaptar a una columna en celular cuando corresponda;
conservar propiedades funcionales de Forms existentes;
no modificar Type o Name por razones visuales;
utilizar Navigator;
clonar unidades completas;
revisar IDs después de clonar;
comprobar que nuevos campos sean realmente procesados;
utilizar Linked styles para mantener consistencia visual;
limitar CSS al Form correspondiente;
proteger credenciales;
revisar privacidad;
realizar una prueba completa después de guardar.
Errores frecuentes
Creer que agregar Form + Button crea automáticamente un formulario operativo
No necesariamente.
No probar el envío
Debes comprobar el resultado real.
Crear una apariencia de formulario funcional cuando nadie recibe los datos
Evítalo.
Agregar un campo a un Form existente y asumir que el procesamiento lo recibirá
Debes comprobarlo.
Utilizar Input para mensajes extensos
Utiliza Text Area.
Utilizar Text Area para Nombre o Email
Utiliza Input.
Utilizar Checkbox cuando solo puede elegirse una alternativa
Considera Radio Button.
Utilizar Radio Button para opciones que pueden seleccionarse simultáneamente
Considera Checkbox.
Utilizar Select con opciones inventadas
Mantén datos reales.
Solicitar demasiada información
Reduce campos cuando sea posible.
Depender únicamente del Placeholder
Mantén identificación clara de los campos.
Agregar * y asumir que existe validación
El símbolo no crea comportamiento.
Escribir “Campo obligatorio” sin comprobar la validación
Prueba el Form.
Simular mensajes de éxito
Deben reflejar un envío real.
Simular errores
Necesitan lógica funcional.
Envolver un Button de envío en un Link
Puede romper o evitar el envío.
Modificar Type por una cuestión visual
Utiliza Estilo.
Modificar Name sin comprender su función
Puede afectar procesamiento.
Duplicar IDs al clonar campos
Mantén IDs únicos.
Cambiar únicamente el Label de un campo clonado
Revisa también sus propiedades internas.
Eliminar Form cuando querías eliminar un Input
Utiliza Navigator.
Eliminar un campo requerido por el procesamiento existente
Prueba nuevamente el funcionamiento.
Utilizar columnas vacías para separar campos
Utiliza Grid y espacios.
Mantener dos campos demasiado estrechos en móvil
Apílalos.
Utilizar Width fijo en Text Area
Puede provocar overflow.
Aplicar CSS global sobre input
Puede romper:
Checkbox;
Radio;
buscadores;
filtros;
otros Forms.
Aplicar CSS global sobre textarea
Puede afectar otros formularios.
Aplicar CSS global sobre .form-control
Puede modificar múltiples componentes.
Eliminar indicadores de foco
Mantén una alternativa visual accesible.
Solicitar datos innecesariamente sensibles
Reduce la información solicitada.
Colocar credenciales en HTML o JavaScript público
Nunca.
Copiar textos legales de otra Página web
Deben corresponder a tu situación.
Agregar JavaScript improvisado para “hacer funcionar” el formulario
Utiliza una implementación adecuada.
No revisar el Form mediante Ver página
La prueba final debe realizarse en el frontend.
Flujo recomendado
1. DEFINIR EL OBJETIVO DEL FORMULARIO
↓
2. DEFINIR QUÉ DATOS SON REALMENTE NECESARIOS
↓
3. CONFIRMAR CÓMO SE PROCESARÁN
↓
4. ELEGIR LOS COMPONENTES
↓
5. AGREGAR / REVISAR FORM
↓
6. UTILIZAR NAVIGATOR
↓
7. AGREGAR INPUTS
↓
8. AGREGAR TEXT AREA SI CORRESPONDE
↓
9. AGREGAR SELECT / CHECKBOX / RADIO SI ES NECESARIO
↓
10. IDENTIFICAR CLARAMENTE CADA CAMPO
↓
11. CONFIGURAR EL BUTTON
↓
12. CONSERVAR PROPIEDADES FUNCIONALES
↓
13. PERSONALIZAR ESTILOS
↓
14. REVISAR LINKED STYLES
↓
15. CONFIGURAR GRID RESPONSIVE
↓
16. REVISAR DESKTOP
↓
17. REVISAR TABLET
↓
18. REVISAR CELULAR
↓
19. GUARDAR CAMBIOS
↓
20. VER PÁGINA
↓
21. COMPLETAR EL FORMULARIO
↓
22. ENVIAR UNA PRUEBA
↓
23. COMPROBAR QUE TODOS LOS DATOS LLEGUEN
Checklist antes de publicar un formulario
El objetivo del formulario está claro.
Sé qué sistema o mecanismo procesará los datos.
No asumí que el Form funciona solamente porque se visualiza.
Probé el envío real.
Los datos llegan al destino esperado.
Los nuevos campos también llegan.
Solicito solamente información necesaria.
Cada campo está correctamente identificado.
Los Labels son claros.
No dependo únicamente del Placeholder.
Utilicé Input para datos breves.
Utilicé Text Area para mensajes extensos.
Utilicé Select cuando corresponde.
Las opciones de Select son reales.
Utilicé Checkbox para opciones independientes.
Utilicé Radio Button para alternativas relacionadas.
Los grupos de Radio se comportan correctamente.
Los Checkbox se pueden seleccionar correctamente.
Los campos obligatorios realmente se validan si así se indican.
No simulé validaciones mediante texto.
El Button tiene un texto claro.
Si el Form ya funcionaba, conservé su Type y propiedades funcionales.
No envolví el Button de envío en un Link innecesario.
Utilicé Navigator.
Al clonar un campo seleccioné su unidad completa.
Al clonar revisé Label.
Al clonar revisé Input.
No quedan IDs duplicados.
Revisé propiedades funcionales relevantes.
No eliminé campos necesarios para el procesamiento.
Linked styles tiene el alcance esperado.
Todos los Inputs mantienen una apariencia coherente.
Los campos tienen suficiente Padding.
Existe contraste suficiente.
El foco puede identificarse.
Desktop se visualiza correctamente.
Tablet se visualiza correctamente.
Celular se visualiza correctamente.
Las filas de dos columnas se apilan cuando corresponde.
Text Area no desborda.
Select tiene suficiente ancho.
Checkbox mantiene una alineación correcta con su texto.
Radio Button sigue siendo fácil de seleccionar.
Button tiene un área de interacción cómoda.
No existe scroll horizontal inesperado.
No utilicé Width fijos innecesarios.
No apliqué CSS global sobre input.
No apliqué CSS global sobre textarea.
No sobrescribí globalmente .form-control.
No eliminé Classes estructurales sin comprenderlas.
No coloqué credenciales privadas en el bloque.
Revisé qué datos personales estoy solicitando.
Los textos de privacidad o consentimiento corresponden al caso cuando son necesarios.
Los Links a políticas funcionan.
No simulé un mensaje de éxito.
No simulé estados de envío.
Guardé los cambios.
Revisé todo mediante Ver página.
Realicé al menos un envío real de prueba.
En resumen
Los componentes principales de un formulario cumplen funciones diferentes:
FORM
→ agrupa el formulario
INPUT
→ información breve
TEXT AREA
→ información extensa
SELECT INPUT
→ elegir una opción de una lista
CHECKBOX
→ seleccionar una condición u opciones independientes
RADIO BUTTON
→ elegir una alternativa dentro de un grupo
HTML BUTTON
→ ejecutar la acción correspondiente del formulario
Una estructura conceptual sencilla puede ser:
Form
├── Nombre
│ └── Input
│ └── Input
├── Servicio
│ └── Select Input
├── Mensaje
│ └── Text Area
├── Consentimiento
│ └── Checkbox
└── Html Button
Pero recuerda la regla fundamental:
crear esta estructura visual no significa automáticamente que la información sea enviada o almacenada.
Para considerar un formulario operativo debes comprobar:
COMPLETAR
↓
ENVIAR
↓
RECIBIR
↓
VERIFICAR LOS DATOS
Si agregas un nuevo campo a un Form existente:
también debes comprobar que ese nuevo campo sea procesado.
No basta con que aparezca en pantalla.
Cuando el Form ya funciona, evita modificar propiedades como:
Type;
Name;
IDs;
estructura;
si solamente quieres cambiar:
texto;
color;
Padding;
Border;
Border radius.
Para eso utiliza las herramientas visuales.
En responsive puedes pasar de:
Desktop
Nombre Email
[__________] [__________]
a:
Mobile
Nombre
[________________]
[________________]
mediante Grid Row.
Y evita reglas globales como:
input {
width: 100%;
}
sin analizar el alcance, porque también pueden modificar:
Checkbox;
Radio Button;
buscadores;
filtros;
otros formularios.
Finalmente:
Guardar Cambios → Ver página → completar todos los campos → enviar → comprobar que la información llegue correctamente.
En formularios, la revisión visual es solamente la mitad del trabajo.
La otra mitad es responder una pregunta mucho más importante:
“Cuando el visitante presiona Enviar, ¿qué ocurre realmente con sus datos?”
Si puedes comprobar esa respuesta, el formulario está listo para utilizarse.
¿Necesitas más ayuda?
Si este artículo no resolvió tu consulta, nuestro equipo puede ayudarte personalmente.
Soporte por WhatsApp