Una sección de contacto permite que el visitante encuentre rápidamente cómo comunicarse con una empresa y, cuando corresponde, pueda enviar una consulta directamente desde la Página web.
Una sección completa puede combinar:
Heading;
texto introductorio;
Form;
Input;
Text Area;
Select Input;
Checkbox o Radio Button cuando sean realmente necesarios;
teléfono;
email;
dirección;
horario;
Link a WhatsApp;
Google Maps u Open Street Map;
mensajes de ayuda o privacidad.
Una composición posible es:
HABLEMOS
Cuéntanos en qué podemos ayudarte
┌──────────────────────────────┬──────────────────────────────┐
│ │ │
│ Nombre │ CONTACTO │
│ [________________________] │ │
│ │ Teléfono │
│ Email │ +54 ... │
│ [________________________] │ │
│ │ Email │
│ Empresa │ contacto@... │
│ [________________________] │ │
│ │ Dirección │
│ Mensaje │ Calle... │
│ [________________________] │ │
│ [________________________] │ [ WHATSAPP ] │
│ │ │
│ [ ENVIAR CONSULTA ] │ │
│ │ │
└──────────────────────────────┴──────────────────────────────┘
┌──────────────────────────────────────────────────────────────┐
│ │
│ MAPA │
│ │
└──────────────────────────────────────────────────────────────┘
También puedes utilizar una estructura:
FORMULARIO
+
MAPA
en dos columnas,
o:
INFORMACIÓN
+
FORMULARIO
+
MAPA
en bloques consecutivos.
En este tutorial aprenderás a:
planificar una sección de contacto;
decidir qué datos solicitar;
evitar formularios innecesariamente largos;
construir el formulario con los componentes disponibles;
comprender la importancia de Name en los campos;
diferenciar etiqueta, Placeholder y valor;
utilizar tipos de Input apropiados;
trabajar con Select Input;
utilizar Checkbox y Radio Button correctamente;
identificar campos obligatorios;
evitar marcar todos los campos como obligatorios;
no solicitar información que no necesitas;
comprender que un formulario visible no garantiza procesamiento;
conservar atributos funcionales de un formulario existente;
comprobar un envío real;
construir una columna de información;
crear Links de teléfono, email y WhatsApp;
utilizar Google Maps u Open Street Map;
mostrar siempre la dirección también como texto;
verificar la ubicación real del mapa;
adaptar toda la sección a celular;
tratar adecuadamente privacidad y consentimiento;
evitar colocar credenciales o datos sensibles en código público;
utilizar Navigator;
guardar y probar el flujo completo.
La regla más importante de todo el tutorial
Antes de comenzar:
FORMULARIO VISIBLE
≠
FORMULARIO FUNCIONAL
Puedes crear perfectamente:
Nombre
Mensaje
[ ENVIAR ]
y conseguir un diseño impecable.
Pero eso no demuestra que:
el mensaje se envíe;
los datos se procesen;
alguien reciba la consulta;
exista una respuesta de confirmación;
los campos estén conectados correctamente.
Por eso:
No consideres terminada una sección de contacto hasta haber realizado una prueba real del formulario.
Formulario prediseñado vs formulario creado con componentes
Waclis dispone de elementos específicos para formularios dentro de la biblioteca de componentes.
Entre ellos:
Form;
Input;
Text Area;
Select Input;
Checkbox;
Radio Button.
También existen secciones prediseñadas relacionadas con formularios de contacto.
¿Cuál conviene?
Si existe una sección prediseñada que ya resuelve correctamente tu necesidad:
puede ser el camino más rápido.
Si quieres construir una composición personalizada
puedes utilizar los componentes individuales.
Pero existe una diferencia importante
Agregar visualmente:
Form
Input
Text Area
Button
no significa automáticamente:
“este formulario ya está conectado al procesamiento correspondiente”
Si partes de un formulario que ya funciona
conserva sus:
atributos;
Names;
estructura;
elementos funcionales;
salvo que comprendas exactamente qué estás cambiando.
Primera regla técnica
Cuando personalices un formulario funcional existente, modifica su presentación sin eliminar o renombrar atributos funcionales que no comprendes.
Antes de abrir el Editor: define el objetivo
Pregunta:
¿Para qué debe utilizarse este formulario?
Por ejemplo
Consulta general
O:
Solicitud de presupuesto
O:
Consulta sobre un producto
O:
Solicitud comercial
No intentes construir un formulario que sirva simultáneamente para:
soporte;
ventas;
reclamos;
proveedores;
recursos humanos;
prensa;
presupuestos;
si esos procesos requieren información diferente.
Puede ser mejor separar recorridos.
Segunda regla
Solicita únicamente la información que realmente necesitas para responder la consulta.
¿Qué campos necesita un formulario básico?
Una versión sencilla puede utilizar:
Nombre
Mensaje
Una versión comercial puede agregar:
Empresa
Teléfono
Motivo de consulta
Pero no agregues campos simplemente porque existe espacio.
Ejemplo excesivo
Nombre
Apellido
Empresa
Cargo
Teléfono
Celular
Dirección
Ciudad
Provincia
Código postal
Sitio web
Red social
Cantidad de empleados
Motivo
Presupuesto
Mensaje
para una consulta general.
Cada campo adicional genera fricción
Pregunta:
¿Necesitamos este dato antes de responder?
Si la respuesta es no:
evalúa eliminarlo.
¿Qué vamos a construir?
Nuestro ejemplo utilizará:
Nombre
Empresa
Motivo de consulta
Mensaje
más:
información de contacto
+
+
dirección
+
mapa
Los datos del ejemplo deberán sustituirse por los datos reales del sitio.
Estructura general
Conceptualmente:
Section
└── Container
├── Heading Area
│ ├── Paragraph
│ ├── Heading
│ └── Paragraph
│
├── Grid Row
│ ├── Column Form
│ │ └── Form
│ │ ├── Input
│ │ ├── Input
│ │ ├── Input
│ │ ├── Select Input
│ │ ├── Text Area
│ │ └── Submit control
│ │
│ └── Column Information
│ ├── Heading
│ ├── Paragraph
│ ├── Links
│ └── WhatsApp Link
│
└── Map
No es HTML obligatorio
La estructura real puede mostrar wrappers adicionales.
Utiliza:
Navigator
para comprobarla.
Paso 1. Abre el Editor de bloques
Desde:
Menúes
selecciona el Bloque editable correspondiente mediante el icono de paleta.
En una página de Contacto puedes encontrar una posición como:
Bloque editable debajo del menú
o:
Bloque editable arriba del menú inferior
Recuerda
estas áreas son contenido de la página.
No estás editando:
Header;
Footer.
Paso 2. Decide si usarás una sección prediseñada
Antes de crear todo manualmente:
revisa:
Secciones → Formularios de contacto
Puede existir un diseño que ya se aproxime a tu necesidad.
Si lo utilizas
puedes personalizar:
textos;
disposición;
estilos;
pero debes seguir comprobando el funcionamiento real.
Sección prediseñada:
más rápida para comenzar
Componentes individuales:
más flexibilidad de composición
Paso 3. Crea la Section base
Para el caso práctico manual agrega:
Section
Configura conceptualmente:
Container width:
Boxed
Y:
Container height:
Auto
No necesitamos Full Height.
El formulario debe crecer naturalmente
si:
aumenta el mensaje;
aparecen campos;
cambia el contenido.
Evita:
height: 700px;
Paso 4. Configura Padding
Puedes comenzar con un espacio generoso.
Por ejemplo:
72px arriba
72px abajo
como referencia.
Mobile puede necesitar menos.
No es una medida obligatoria.
Paso 5. Agrega el encabezado
Puedes utilizar:
Paragraph
Heading
Paragraph
Ejemplo
Texto superior:
CONTACTO
Heading:
¿En qué podemos ayudarte?
Descripción:
Completa el formulario con tu consulta o utiliza alguno de nuestros canales de contacto.
Evita frases como:
Te responderemos inmediatamente
si ese tiempo de respuesta no está garantizado.
Puedes decir:
Nuestro equipo podrá responder tu consulta a través de los datos proporcionados.
solo si eso describe realmente el proceso.
Paso 6. Define la jerarquía del Heading
Si la página tiene un H1 previo:
este Heading puede ser:
H2
Si esta Section constituye el contenido principal de una Página de Contacto y no existe un H1 anterior:
revisa la jerarquía general antes de elegir.
No selecciones Heading por tamaño.
Paso 7. Agrega Grid Row
Debajo del encabezado:
Grid Row
Crearemos:
2 columnas
Una para:
FORMULARIO
Otra:
INFORMACIÓN
Una proporción posible:
7 + 5
si el Form necesita mayor ancho.
También:
6 + 6
puede funcionar.
Para un formulario con varios campos:
7 + 5
puede ofrecer más comodidad.
No es obligatorio.
Paso 8. Configura responsive ahora
Desktop:
[ FORM ][ INFORMACIÓN ]
Tablet puede:
mantener dos columnas;
apilarse;
dependiendo del ancho y cantidad de campos.
Mobile:
FORMULARIO
INFORMACIÓN
O:
INFORMACIÓN
FORMULARIO
si deseas mostrar primero los canales directos.
Decide el orden conscientemente.
Para nuestro ejemplo utilizaremos:
FORM
↓
INFORMACIÓN
en mobile.
Paso 9. ¿Qué debería aparecer primero?
Depende de la prioridad.
Formulario primero
puede ser apropiado cuando:
Enviar consulta es el objetivo principal.
Información primero
puede ser apropiada cuando:
teléfono, dirección o WhatsApp son los canales principales.
No existe una regla universal.
Paso 10. Agrega Form
Dentro de la primera Column agrega:
Form
Utiliza Navigator para seleccionarlo.
A partir de ahora
es muy importante distinguir:
FORM
→ contenedor del formulario
de:
INPUT
→ campo individual
No agregues Inputs fuera del Form
si deben formar parte del mismo envío,
salvo que sepas exactamente cómo está implementado el procesamiento.
Mantén la estructura lógica.
Paso 11. Agrega el campo Nombre
Dentro del Form agrega:
Input
El visitante debería comprender qué escribir.
Puedes acompañarlo con una etiqueta visible:
Nombre
Y un campo:
[ Escribe tu nombre ]
Etiqueta y Placeholder no son exactamente lo mismo
Etiqueta:
Nombre
explica permanentemente el campo.
Placeholder:
Ej.: Ana Pérez
aparece dentro del Input como ayuda y puede desaparecer al escribir.
No dependas exclusivamente del Placeholder para identificar campos importantes.
Especialmente en formularios extensos.
Paso 12. Revisa Name
En formularios HTML existe un atributo especialmente importante:
name
Puede ser utilizado para identificar el dato enviado.
Por ejemplo, conceptualmente:
<input name="nombre">
Si trabajas con un formulario funcional existente:
No cambies Name solamente porque quieres que el código se vea distinto.
El procesamiento puede depender de él.
Ejemplo
Visualmente:
Nombre completo
puede continuar utilizando internamente un Name determinado por el formulario.
Cambiar el texto visible:
Nombre
→ Nombre completo
no significa necesariamente que debas cambiar:
name
Son conceptos diferentes.
Tercera regla técnica
Texto visible y nombre funcional del campo no deben confundirse.
Paso 13. IDs de Inputs
Un Input también puede tener:
Id
Si existe un Label asociado:
el ID puede participar en esa relación.
No dupliques IDs al clonar.
Especialmente:
id="nombre"
no debe repetirse en:
Nombre;
Email;
Empresa.
Paso 14. Clonar Input
Puedes clonar el Input para mantener:
estilo;
estructura.
Pero después debes revisar:
Label
Placeholder
Name
Type
Id
valor
requisitos
según las opciones disponibles.
No cambies solamente el Placeholder.
Paso 15. Campo Email
Crea otro Input.
Texto visible:
El tipo de Input debería corresponder al dato cuando la configuración disponible lo permita.
Un campo destinado a email debería identificarse correctamente como tal.
Esto puede ayudar al navegador y a la experiencia del usuario.
No utilices un tipo incorrecto solo porque:
“visualmente todos se ven parecidos”
Paso 16. Campo Teléfono
Si el formulario necesita realmente un teléfono:
puedes agregarlo.
Pero pregunta:
¿Es necesario tanto teléfono como email?
En algunos procesos:
sí.
En otros:
un solo canal es suficiente.
No recolectes datos adicionales sin propósito.
Paso 17. Campo Empresa
Puede ser útil en una consulta B2B.
Pero si tu formulario está dirigido principalmente a consumidores:
puede ser innecesario.
Puedes incluso mantenerlo como:
opcional
si la funcionalidad del Form lo permite.
No todos los campos necesitan ser obligatorios.
Paso 18. Campos obligatorios
Pregunta para cada campo:
¿Podemos atender correctamente la consulta sin este dato?
Si sí:
quizá no necesite ser obligatorio.
Ejemplo básico
Nombre → obligatorio
Email → obligatorio
Empresa → opcional
Mensaje → obligatorio
Esto es solo un ejemplo conceptual.
La configuración real depende de tu proceso.
No marques:
todos los campos
como obligatorios por defecto.
Paso 19. Asterisco visual ≠ validación
Esto es fundamental.
Agregar:
Nombre *
visualmente:
no convierte automáticamente el campo en obligatorio.
Debe existir la configuración correspondiente.
De forma similar:
Campo obligatorio
es un mensaje visual.
La validación funcional es otra cosa.
Nunca confundas:
MARCA VISUAL
con:
VALIDACIÓN FUNCIONAL
Paso 20. Select Input
Puede utilizarse cuando existe un conjunto limitado de opciones.
Por ejemplo:
Motivo de consulta
[ Seleccionar... ]
Opciones conceptuales:
Consulta comercial
Consulta sobre productos
Otra consulta
Utiliza únicamente opciones que representen recorridos reales.
No agregues un Select con:
20 opciones
si tres categorías son suficientes.
Paso 21. Cuándo NO utilizar Select
No uses Select si el visitante necesita escribir algo específico.
Por ejemplo:
Nombre de la empresa
no necesita una lista cerrada.
Utiliza Input.
Paso 22. Radio Button
Puede ser apropiado cuando:
existen pocas opciones;
quieres que todas permanezcan visibles.
Por ejemplo:
Preferencia de contacto
( ) Teléfono
Solo si realmente utilizarás esa preferencia.
No agregues Radio Buttons como decoración.
Paso 23. Checkbox
Puede utilizarse para una decisión independiente.
Por ejemplo
un consentimiento o una opción adicional cuando corresponda.
Pero no combines:
Checkbox
y:
Radio Button
indistintamente.
Conceptualmente
Radio:
elegir una opción de un grupo
Checkbox:
activar/desactivar una opción independiente
Paso 24. Privacidad y consentimiento
Si recopilas datos personales:
debes considerar las obligaciones aplicables a tu actividad y jurisdicción.
Según el proceso
puede corresponder informar:
finalidad;
política de privacidad;
tratamiento de datos.
Este tutorial no sustituye asesoramiento legal.
Pero existe una regla práctica importante
No solicites información sensible o innecesaria simplemente porque puedes agregar otro campo.
Paso 25. Nunca solicites contraseñas
Un formulario de contacto normal no debería pedir:
contraseña de la cuenta
Tampoco:
claves privadas;
tokens;
credenciales.
Si soporte necesita verificar algo:
utiliza un procedimiento seguro específico.
No pidas secretos mediante un formulario genérico.
Paso 26. Text Area
Para:
Mensaje
utiliza:
Text Area
Esto permite un contenido más extenso que un Input simple.
Etiqueta:
Mensaje
Placeholder:
Cuéntanos brevemente en qué podemos ayudarte.
Evita Placeholder excesivamente largo.
El visitante debería poder escribir cómodamente.
Paso 27. Tamaño del Text Area
Debe ofrecer suficiente altura inicial.
No hagas:
una línea de alto
para un mensaje extenso.
Tampoco necesita ocupar media pantalla.
Busca un equilibrio.
Paso 28. No utilices Text Area para datos breves
Por ejemplo:
debe ser Input.
Cada componente tiene una función.
Paso 29. Control de envío
El formulario necesita un control para iniciar la acción.
Su texto puede ser:
ENVIAR CONSULTA
Mucho más claro que:
ENVIAR
si quieres contextualizar.
O:
SOLICITAR INFORMACIÓN
cuando corresponda al flujo.
No utilices:
COMPRAR
si el formulario solamente envía una consulta.
Paso 30. Html Button y envío
En un Form puede existir un botón cuyo Type esté relacionado con el comportamiento del formulario.
Si partes de un formulario funcional:
no cambies su:
Type
sin comprender la consecuencia.
Por ejemplo
un Button de envío puede necesitar una configuración específica.
No conviertas accidentalmente el control de envío en:
button genérico
solo para cambiar su apariencia.
Cambia el estilo,
no la función.
Paso 31. No reemplaces un submit funcional por un Link
Si el Button realmente envía el Form:
un Link normal no cumple la misma función.
Recordemos:
LINK
→ navegación
Mientras un control de Form:
→ puede iniciar envío/procesamiento
No intercambies componentes únicamente porque visualmente quieres otro estilo.
Paso 32. Añade una ayuda breve
Debajo del Form puedes mostrar una nota cuando aporte claridad.
Por ejemplo:
Completa los campos requeridos para enviar tu consulta.
O información sobre el uso de datos cuando corresponda.
No escribas:
Responderemos en menos de 5 minutos
si no está garantizado.
Paso 33. Error: poner información esencial únicamente en Placeholder
Por ejemplo:
Placeholder:
“Ingresa tu email. Debe pertenecer a una empresa y...”
Cuando el usuario empieza a escribir:
esa información desaparece.
Utiliza texto de ayuda separado cuando sea importante.
Paso 34. Orden de campos
Un recorrido razonable puede ser:
Nombre
↓
↓
Empresa
↓
Motivo
↓
Mensaje
↓
Enviar
No organices:
Mensaje
↓
Empresa
↓
↓
Nombre
sin una razón.
Coloca primero los datos más naturales.
Paso 35. No construyas dos columnas dentro del Form demasiado pronto
Desktop puede parecer atractivo:
Nombre | Email
Empresa | Teléfono
Pero debes revisar mobile.
Si necesitas una grilla interna:
utiliza Grid correctamente.
No utilices:
width: 48%;
float:left;
como primera solución.
Paso 36. Formulario de una columna
Es una opción muy robusta.
Por ejemplo:
Nombre
[____________________]
[____________________]
Empresa
[____________________]
Mensaje
[____________________]
[ ENVIAR ]
Especialmente cuando el Form ya comparte la pantalla con información de contacto.
No necesitas llenar todo el ancho con múltiples columnas.
Paso 37. Espacio entre campos
Mantén una separación coherente.
No:
campo
campo
campo
pegados.
Utiliza:
Margin;
Padding;
según la estructura.
Evita:
<br><br>
Paso 38. Labels coherentes
Si utilizas:
Nombre
Empresa
Mensaje
mantén:
Typography;
espaciado;
ubicación.
No hagas:
Nombre en Bold
Email en gris
Empresa arriba del Input
Mensaje dentro del Placeholder
sin un sistema.
Paso 39. Estilo de Inputs
Mantén coherencia en:
Height;
Border;
Border radius;
Padding;
Typography.
No diseñes cada Input de forma distinta.
Paso 40. Estado Focus
Cuando el visitante entra en un campo:
debería poder identificar cuál está activo.
No elimines toda señal visual de Focus solamente por estética.
Una interfaz limpia debe seguir siendo utilizable.
Si personalizas CSS:
presta especial atención a:
focus
No ocultes el estado sin ofrecer una alternativa clara.
Paso 41. Placeholder y contraste
El Placeholder puede tener menor intensidad que el texto escrito.
Pero no tan claro que resulte ilegible.
El visitante necesita comprender la ayuda.
Paso 42. Error messages
Si el formulario funcional muestra errores:
no los ocultes mediante CSS.
Por ejemplo:
Email inválido
es información importante.
No utilices:
.error {
display:none;
}
solo para mantener el diseño limpio.
Eso podría impedir que el visitante entienda por qué no puede continuar.
Paso 43. Mensaje de éxito
Después de un envío correcto
el visitante debería poder comprender que la acción se completó,
según el comportamiento real del formulario.
No inventes un mensaje de:
Consulta enviada correctamente
antes de que el Form confirme realmente el envío.
Mostrar visualmente:
“Enviado”
no significa que el servidor haya recibido los datos.
La confirmación debe corresponder al proceso real.
Paso 44. No simules estados funcionales
Evita construir manualmente:
✓ Mensaje enviado
como contenido permanente debajo del Form.
Eso estaría visible incluso antes de enviar.
Los estados deben estar vinculados a la funcionalidad real.
Paso 45. Columna de información
Ahora construimos la segunda Column.
Puede contener:
Heading:
Información de contacto
Y datos como:
teléfono;
email;
dirección;
horario.
Solo muestra información que realmente corresponde al negocio.
Paso 46. Teléfono visible
Ejemplo:
Teléfono
+54 ...
Si quieres que sea accionable:
utiliza un:
Link
El Link puede utilizar el esquema apropiado para iniciar una llamada cuando corresponda.
No asumas que escribir:
+54...
como Paragraph lo vuelve clicable.
Paso 47. Texto del Link de teléfono
Puede mostrarse directamente:
+54 11 ...
O:
Llamar
Incluso puedes combinar:
Teléfono
+54...
Lo importante:
el destino debe ser correcto.
Paso 48. Email
Mismo principio.
Mostrar:
contacto@empresa.com
como texto
no necesariamente crea una acción.
Si quieres abrir el cliente de email:
configura un Link apropiado.
Pero comprueba:
dirección;
destino.
Paso 49. No escribas direcciones de ejemplo
Antes de publicar:
revisa que no quede:
Calle Falsa 123
Lo mismo con:
email;
teléfono;
horarios.
Las secciones de contacto suelen clonarse desde ejemplos
y estos errores pueden pasar inadvertidos.
Paso 50. Dirección
Muéstrala como texto.
Por ejemplo:
Dirección
Calle, número
Localidad, provincia
País
Según los datos reales.
Esto es importante incluso si utilizas un mapa.
Cuarta regla
El mapa complementa la dirección. No la reemplaza.
Paso 51. ¿Por qué mostrar la dirección escrita?
Porque permite:
leerla;
copiarla;
comprenderla sin interactuar con el mapa.
También ayuda cuando:
el mapa no carga;
el proveedor externo falla.
No obligues al visitante a mover un mapa para descubrir dónde estás.
Paso 52. Información adicional
Si la ubicación necesita aclaraciones:
puedes incluir:
Local 4
Piso 2
Ingreso por...
El mapa puede llevar al edificio,
pero no necesariamente:
piso;
oficina;
local.
Agrega esa información como texto.
Paso 53. Horarios
Si son útiles:
Lunes a viernes
9:00 a 18:00
Mantén la información actualizada.
No muestres horarios obsoletos.
Si cambian por temporada:
revísalos.
Paso 54. Link “Cómo llegar”
Puede ser una excelente alternativa.
Por ejemplo:
Cómo llegar →
Debe llevar a una ubicación real.
No utilices:
#
Prueba la URL.
Paso 55. WhatsApp
Si la empresa utiliza WhatsApp como canal:
puedes agregar:
CONTACTAR POR WHATSAPP
mediante un Link real.
El texto debe ser claro.
No:
COMPRAR
si simplemente abre una conversación.
Tampoco:
RESERVAR
si no confirma una reserva.
Paso 56. WhatsApp como alternativa, no necesariamente como competencia
Si el formulario es la acción principal:
puedes mostrar WhatsApp de forma secundaria.
Por ejemplo:
¿Prefieres comunicarte directamente?
[ WHATSAPP ]
No necesitas dar igual jerarquía a:
ENVIAR FORMULARIO
y:
si uno es prioritario.
Paso 57. Demasiados canales
Evita una columna como:
Teléfono
Telegram
Formulario
Chat
si no todos son realmente canales de atención.
Mostrar todas las plataformas puede dificultar la decisión.
Prioriza los canales reales.
Paso 58. Social icons
Si deseas mostrar redes:
puedes utilizar:
Social icons
Pero recuerda:
red social:
no siempre equivale a canal de soporte
Si Instagram se utiliza solo para contenido:
no lo presentes como:
“Soporte”
Paso 59. Agrega el mapa
Puedes utilizar:
Google Maps;
Open Street Map.
Ambos están disponibles dentro de:
Componentes → Widgets
También puedes utilizar la sección prediseñada:
Mapas y localización
si se ajusta a tu diseño.
En este caso
utilizaremos un Widget individual debajo del bloque de contacto.
Paso 60. Widget vs sección prediseñada
Widget:
MAPA
Tú construyes:
Heading;
dirección;
CTA;
estructura.
Sección prediseñada:
composición completa preparada
Elige según la necesidad.
Paso 61. Google Maps
Desde:
Componentes → Widgets → Google Maps
agrega el componente.
Selecciónalo mediante Navigator
y abre:
Contenido
Configura las opciones reales que muestre el componente.
No asumimos que todas las implementaciones muestran exactamente:
Address;
latitude;
longitude;
zoom;
API key;
porque debes utilizar los campos disponibles en tu versión.
Lo importante:
la ubicación mostrada debe verificarse visualmente.
Paso 62. Open Street Map
También puedes utilizar:
Open Street Map
El procedimiento general es similar:
agregar;
seleccionar;
abrir Contenido;
configurar la ubicación mediante las opciones disponibles;
verificar resultado.
No asumimos:
qué librería interna utiliza;
qué proveedor de tiles utiliza;
que no necesite configuración externa.
Utiliza el componente tal como aparece en Waclis.
Paso 63. Google Maps vs Open Street Map
No existe una regla universal de:
“este siempre es mejor”
Puedes elegir según:
necesidades;
funcionamiento del Widget;
proveedor que prefieras utilizar.
Ambos son recursos externos.
La dirección escrita debe mantenerse independientemente del proveedor.
Paso 64. Verifica el pin
Esto es fundamental.
No basta con escribir una dirección
y asumir que:
el mapa la interpretó correctamente
Puede existir:
otra calle con el mismo nombre;
otra localidad;
una ubicación aproximada.
Comprueba visualmente:
¿el marcador está realmente donde debe estar?
Paso 65. Dirección y mapa deben coincidir
Incorrecto:
Texto:
Sucursal Centro
Dirección A
Mapa:
Dirección B
Puede ocurrir después de clonar.
Actualiza ambos.
Paso 66. “Cómo llegar” también debe coincidir
Puedes terminar con tres fuentes de ubicación:
Dirección escrita
Mapa
Link Cómo llegar
Las tres deben representar:
la misma ubicación
No asumas sincronización automática entre ellas.
Si cambias una sucursal:
revisa las tres.
Paso 67. Múltiples sucursales
Si tienes dos o tres:
puedes crear:
Sucursal A
Dirección
Teléfono
Cómo llegar
Sucursal B
Dirección
Teléfono
Cómo llegar
Puede existir un mapa para cada una
si el número es razonable.
Pero si tienes:
20 sucursales
cargar 20 mapas interactivos puede ser excesivo.
Puede ser mejor:
lista de sucursales;
Links;
una página específica.
Paso 68. No dupliques mapas sin necesidad
Los mapas externos pueden aumentar:
carga;
recursos de terceros.
Si la ubicación escrita y Link son suficientes para una sucursal secundaria:
evalúa si necesita otro mapa.
Paso 69. Alto del mapa
Un mapa necesita suficiente espacio para ser útil.
Evita:
height: 100px
También evita ocupar:
toda la pantalla
sin necesidad.
Una altura como:
320–450px
puede ser una referencia frecuente,
pero no es obligatoria.
Ajusta al diseño.
Paso 70. Width del mapa
Debe adaptarse al contenedor.
Evita:
width: 900px
fija
si puede desbordar mobile.
Utiliza un ancho responsive.
Paso 71. CSS sobre el mapa
Antes de escribir:
iframe {
width: 100%;
height: 400px;
}
recuerda:
esto puede afectar:
videos;
calendarios;
otros Iframes.
No utilices un selector global.
Agrega una Class al contenedor.
Por ejemplo:
contact-map
Y limita:
.contact-section .contact-map iframe {
width: 100%;
max-width: 100%;
}
Solo si la estructura real utiliza un iframe.
Puede no ser así.
Inspecciona primero.
Paso 72. No asumas que el mapa es un Iframe
Dependiendo del Widget:
puede utilizar otra estructura.
Por eso:
Navigator;
Editar código HTML <>;
pueden ayudarte a comprenderlo.
No copies CSS de Iframe automáticamente.
Paso 73. Border radius del mapa
Puede resultar atractivo.
Pero cuidado:
si aplicas:
overflow:hidden
para recortar las esquinas,
comprueba que no estés ocultando:
controles;
atribución del proveedor.
No elimines visualmente la atribución requerida por la integración.
Paso 74. No ocultes controles del proveedor
Evita CSS destinado a:
borrar logos;
quitar atribuciones;
ocultar elementos de navegación;
sin comprender los requisitos del proveedor.
Mantén la integración íntegra.
Paso 75. Mapas y privacidad
Un mapa puede cargar recursos externos.
Eso significa que la Página web puede interactuar con servicios de terceros.
Debes evaluar las obligaciones de privacidad aplicables a la configuración real del sitio.
No asumimos en este tutorial:
cookies concretas;
mecanismos legales concretos;
porque dependen del proveedor y configuración.
Paso 76. Responsive de la sección general
Desktop:
[ FORMULARIO ][ INFORMACIÓN ]
[ MAPA ]
Tablet:
puede mantenerse:
[ FORM ][ INFO ]
si sigue siendo cómodo.
O:
FORM
INFO
MAPA
Mobile:
FORM
INFO
MAPA
Este patrón suele ser muy robusto.
Paso 77. No reduzcas el Form para conservar dos columnas
Si en tablet:
Input muy estrecho
no reduzcas:
Font size;
Padding;
hasta hacerlo incómodo.
Apila las columnas.
Paso 78. Formulario en mobile
Los Inputs deben ocupar un ancho cómodo.
Evita:
Nombre | Email
en una pantalla muy estrecha
si ambos quedan diminutos.
Puede ser mejor:
Nombre
Paso 79. Área de toque
Button, Links de teléfono y WhatsApp deben ser fáciles de seleccionar.
No los conviertas en texto diminuto.
Mobile necesita suficiente espacio.
Paso 80. Evita scroll horizontal
Busca especialmente:
Inputs con Width fija;
mapa con Width fija;
Grid interno;
Buttons largos.
No soluciones:
body {
overflow-x:hidden;
}
Corrige el elemento que desborda.
Paso 81. Mensajes de error en mobile
Pueden aumentar la altura del formulario.
La estructura debe permitirlo.
Otra razón para evitar:
Height fija
en el Form o Section.
Paso 82. Mensaje largo del usuario
Aunque Text Area comience con una altura determinada:
el contenido y comportamiento deben seguir siendo utilizables.
No construyas un contenedor que corte cualquier expansión.
Paso 83. Classes recomendadas
Puedes utilizar conceptualmente:
contact-section
Para Form:
contact-form-wrapper
Para información:
contact-info
Para mapa:
contact-map
Son ejemplos.
Utiliza los nombres que mantengan tu proyecto organizado.
Paso 84. No utilices .form-control globalmente para todo el sitio
Aunque Bootstrap pueda utilizar determinadas Classes,
evita modificar globalmente:
.form-control {
...
}
si solo quieres cambiar este formulario.
Puede afectar otros Forms.
Mejor:
.contact-section .form-control {
...
}
si corresponde a la estructura real.
Paso 85. No utilices input globalmente
Evita:
input {
border-radius: 20px;
}
Puede modificar:
búsqueda;
checkout;
otros formularios.
Utiliza scope.
Paso 86. No utilices textarea globalmente
Mismo principio.
Limita:
.contact-section textarea {
...
}
cuando corresponda.
Paso 87. No utilices select globalmente
Puede afectar otros procesos del sitio.
Utiliza una Class raíz.
Paso 88. No utilices button globalmente
Puede cambiar:
botones de formularios;
componentes interactivos;
otras áreas.
Limita el selector.
Paso 89. Linked styles
Si los Inputs comparten selector:
un cambio visual puede aplicarse a todos.
Esto suele ser útil.
Por ejemplo:
Border radius;
Padding;
Typography.
No agregues un ID diferente a cada Input simplemente para aplicar el mismo estilo.
Paso 90. IDs deben ser únicos
Por ejemplo:
nombre
empresa
mensaje
No:
campo
campo
campo
campo
Especialmente si existe una relación entre:
Label;
Input.
Paso 91. Clonar Form completo
Si quieres reutilizar esta sección en otra página:
ten mucho cuidado.
Clonar:
Form
puede duplicar:
IDs;
Names;
configuración funcional.
No basta con cambiar el Heading.
Debes revisar todos los campos.
Paso 92. No cambies Names al azar después de clonar
Si el procesamiento espera determinados nombres:
puede dejar de recibir los datos correctamente.
Si necesitas crear otro Form diferente:
debes comprender cómo está conectado.
No asumas:
“renombro name=email por name=correo y listo”
Puede no ser así.
Paso 93. Editar código HTML de un Form
Utiliza:
Editar código HTML <>
solo cuando sea necesario.
Primero:
copiar HTML original
Después identifica:
Form;
Inputs;
Names;
IDs;
Types;
atributos.
No reescribas el Form entero para:
cambiar Border radius
Eso corresponde a CSS.
Paso 94. No elimines atributos desconocidos
Si encuentras algo que no comprendes:
no lo borres solamente para “limpiar”.
Puede participar en:
validación;
procesamiento;
comportamiento.
Investiga primero.
Paso 95. No agregues JavaScript para “hacer que el formulario envíe”
Si el Form no procesa:
no inventes una solución rápida como:
onclick
+
fetch
+
API improvisada
sin una integración apropiada.
Un formulario funcional necesita un procesamiento real y seguro.
El Editor visual no sustituye el backend.
Paso 96. No coloques credenciales en JavaScript
Nunca agregues en código público:
contraseñas;
tokens privados;
secretos API;
credenciales de email.
El código del navegador puede ser visible.
Si un servicio necesita una credencial privada:
debe gestionarse desde un mecanismo seguro adecuado.
Paso 97. Primera prueba: campos obligatorios
Antes de completar nada:
intenta enviar.
Observa:
¿se identifican campos requeridos?
¿los mensajes son comprensibles?
Si todo se envía vacío:
revisa la configuración.
No confíes solamente en asteriscos.
Paso 98. Segunda prueba: email inválido
Prueba un dato evidentemente incorrecto:
texto-sin-email
Si el campo está destinado a Email:
comprueba el comportamiento real.
No asumas validación.
Paso 99. Tercera prueba: envío válido
Completa:
nombre;
email;
campos requeridos;
mensaje.
Utiliza datos de prueba apropiados.
Envía.
Paso 100. Comprueba qué ocurre
No te detengas cuando:
el Button responde
Comprueba:
¿se muestra confirmación?
¿la consulta realmente llega al destino previsto?
¿se conservan o limpian los campos?
¿se produce algún error?
Solo el comportamiento real permite validar el Form.
Paso 101. Comprueba recepción
Este punto es esencial.
Si esperas que el Form genere:
email;
registro;
conversación;
otra acción;
verifica que realmente ocurrió.
No consideres:
“clic sin error”
como confirmación suficiente.
Paso 102. Comprueba datos
Verifica que el destino reciba:
Nombre correcto
Email correcto
Empresa correcta
Motivo correcto
Mensaje correcto
Si un campo aparece vacío:
puede existir un problema en:
Name;
configuración;
procesamiento.
Paso 103. Error frecuente después de agregar un campo
Agregas:
Empresa
Visualmente aparece.
Pero el mensaje recibido sigue mostrando solamente:
Nombre
Mensaje
Eso demuestra:
CAMPO VISIBLE
≠
CAMPO PROCESADO
Debes verificar que el sistema encargado del procesamiento también reconozca ese campo.
No asumas que agregarlo al HTML es suficiente.
Paso 104. Error frecuente después de cambiar Name
Antes:
name="email"
Después:
name="correo-cliente"
El diseño no cambia.
Pero el procesamiento puede dejar de encontrar:
No modifiques Names funcionales por estética.
Paso 105. Error frecuente después de clonar Input
Creas:
a partir de Nombre.
Cambias visualmente:
Placeholder:
Pero dejas:
name="nombre"
Ahora ambos campos pueden intentar representar el mismo dato.
Revisa siempre la configuración funcional.
Paso 106. Error frecuente: Button no envía
Puede ocurrir si:
está fuera del Form;
Type no corresponde;
se modificó estructura;
procesamiento no está configurado.
No añadas JavaScript aleatorio.
Revisa:
jerarquía
+
configuración
Navigator es fundamental.
Paso 107. Error frecuente: Form se ve bien pero no sucede nada
Señal clara de que necesitas comprobar:
procesamiento
No el diseño.
El problema puede estar fuera del CSS.
Paso 108. Error frecuente: se envía dos veces
Si al personalizar agregaste:
otro Button;
scripts;
eventos;
puedes haber duplicado acciones.
Si el Form funcionaba antes:
compara con la versión original.
No agregues múltiples mecanismos de envío.
Paso 109. Error frecuente: todos los campos llegan con el mismo valor
Revisa especialmente:
Name
e:
Ids
Puede haberse producido una clonación incorrecta.
Paso 110. Error frecuente: mapa correcto, dirección incorrecta
Actualiza el texto.
No asumas sincronización.
Paso 111. Error frecuente: dirección correcta, pin equivocado
Verifica:
localidad;
región;
país;
coordenadas si el componente las utiliza.
No publiques hasta corregir.
Paso 112. Error frecuente: WhatsApp tiene número antiguo
Prueba el Link.
Especialmente después de:
clonar;
cambiar datos del negocio.
Paso 113. Error frecuente: email visible y email del Link no coinciden
Puedes mostrar:
ventas@empresa.com
pero el Link contener:
info@empresa.com
Esto puede ser intencional,
pero debe comprobarse.
Si no lo es:
corrígelo.
Paso 114. Revisa todos los datos duplicados
La información puede aparecer en:
texto;
Link;
mapa;
formulario.
Si un dato cambia:
actualiza todas las instancias.
Paso 115. Formulario + mapa en una misma Row
También puedes diseñar:
[ FORM ][ MAPA ]
Y poner información de contacto arriba o abajo.
Puede funcionar si el mapa tiene suficiente altura.
Pero cuidado:
un Form largo puede medir:
700px
y el mapa:
350px
No fuerces:
mapa height 700px
solo para igualarlos.
Puede quedar excesivo.
Paso 116. No necesitas igualar alturas
Esta es una regla importante.
Form:
alto según campos
Info:
alto según contenido
No tienen que medir exactamente lo mismo.
Busca equilibrio,
no igualdad matemática.
Paso 117. Card para información
Puedes envolver la información en una:
Card
Por ejemplo:
┌──────────────────────────┐
│ Información de contacto │
│ │
│ Teléfono │
│ Email │
│ Dirección │
│ Horario │
│ │
│ [ WHATSAPP ] │
└──────────────────────────┘
Puede ayudar a diferenciarla.
No es obligatorio.
Paso 118. Card para Form
También puedes utilizar un Background o contenedor visual.
Pero evita:
Card dentro de Card dentro de Card
Mantén una estructura simple.
Paso 119. Section Background
Puede utilizar:
Background suave
y Form blanco.
Por ejemplo:
fondo general claro
+
formularios/cards blancas
Esto puede crear contraste sin imágenes.
Paso 120. No uses Background Image detrás de muchos Inputs si perjudica la lectura
Un Form necesita:
claridad;
concentración.
Un Background fotográfico muy detallado puede dificultar:
labels;
bordes;
errores.
En formularios
normalmente la legibilidad debe tener prioridad.
Paso 121. Animaciones
Puedes utilizar Animate on scroll moderadamente.
Pero el Form debería permanecer estable.
Evita:
cada Input aparece con Delay
El visitante no debería esperar para completar campos.
Tampoco:
Button de envío rebota permanentemente
Prioriza usabilidad.
Paso 122. Hover de Inputs
Los Inputs no necesitan comportarse como Cards interactivas.
Focus es más importante que Hover.
No hagas:
Input se mueve 10px
al pasar el mouse.
Puede resultar incómodo.
Paso 123. Hover de Links
Sí puede ser útil para:
teléfono;
email;
WhatsApp;
Cómo llegar.
Pero mantén siempre legibilidad.
Paso 124. Mapa y touch
En celular:
un mapa interactivo puede capturar gestos.
Comprueba que el visitante pueda:
desplazarse por la página;
utilizar el mapa.
No hagas el mapa tan grande que:
ocupe prácticamente toda la pantalla
y dificulte continuar.
Paso 125. Link “Cómo llegar” como alternativa
Es especialmente útil en mobile.
Incluso si el mapa resulta difícil de manipular:
Cómo llegar →
permite abrir una experiencia de mapas apropiada.
Es un excelente complemento.
Paso 126. Mapa que no carga
Puede deberse a:
proveedor externo;
configuración;
red;
CSS;
Height cero.
Revisa primero:
¿el contenedor tiene altura?
Después:
recursos externos;
configuración del Widget.
No reemplaces inmediatamente todo el mapa.
Paso 127. Mapa funciona en Editor pero no en Página web
Utiliza:
Guardar Cambios
Luego:
Ver página
Comprueba:
recursos;
configuración;
consola/errores si realizas un diagnóstico avanzado.
No asumas que la vista del Editor confirma el frontend.
Paso 128. Form funciona en Editor pero no en frontend
La misma regla:
prueba desde:
Página web real
El envío debe probarse como visitante.
Paso 129. No uses únicamente Vista previa
La vista móvil y Vista previa ayudan a diseñar.
Pero el proceso final es:
GUARDAR CAMBIOS
↓
VER PÁGINA
↓
COMPLETAR FORM
↓
ENVIAR
↓
COMPROBAR RESULTADO
Paso 130. Revisa desktop
Comprueba:
Heading;
Form;
información;
mapa;
espacios.
El Form no debería sentirse:
apretado
Ni la info:
perdida en una columna enorme
Ajusta proporciones.
Paso 131. Revisa tablet
Este suele ser el breakpoint más delicado.
Un:
7 + 5
puede funcionar en desktop,
pero en tablet:
Form estrecho;
info estrecha.
Si ocurre:
12 + 12
puede ser mejor.
Paso 132. Revisa mobile
Lee el recorrido completo:
CONTACTO
Heading
Descripción
FORM
INFORMACIÓN
MAPA
¿Tiene sentido?
Comprueba:
campos;
Labels;
Button;
Links;
mapa.
Paso 133. Revisa teclado móvil
Los tipos de Input correctos pueden ayudar al dispositivo a ofrecer una experiencia más apropiada.
Por eso:
no utilices el mismo Type indiscriminadamente para todos los campos.
Configura según las opciones disponibles.
Paso 134. Revisa autofill
Si el navegador ofrece completar datos:
comprueba que el Form siga siendo claro.
No dependas de que el usuario siempre escriba manualmente.
Paso 135. Revisa zoom
El Form debe continuar funcionando cuando aumenta:
tamaño del texto;
zoom.
No utilices:
Height fija;
contenedores con overflow problemático.
Paso 136. Revisa errores largos
Un mensaje como:
Debes ingresar una dirección de email válida.
puede ocupar más espacio en mobile.
La interfaz debe permitirlo.
Paso 137. Revisa textos del Button
Evita:
ENVIAR TODA LA INFORMACIÓN PARA PODER SER CONTACTADO POR NUESTRO EQUIPO
Mejor:
ENVIAR CONSULTA
El resto se explica en el contexto.
Paso 138. ¿Qué hacer si quiero que el usuario adjunte un archivo?
No asumas que un Input agregado visualmente permitirá:
cargar;
almacenar;
enviar archivos.
Esa funcionalidad requiere que el procesamiento soporte archivos.
Si la versión actual no ofrece esa función:
no intentes simularla.
Paso 139. ¿Qué hacer si quiero múltiples destinatarios?
Eso pertenece a:
procesamiento del formulario
No a la apariencia del Editor.
Un Select:
Ventas
Soporte
Administración
no enruta automáticamente mensajes a diferentes departamentos.
Debe existir lógica que lo haga.
Esta distinción es crítica.
Paso 140. ¿Qué hacer si quiero que el Select cambie a quién se envía?
No asumas automatización.
Primero confirma que el procesamiento del Form soporta ese comportamiento.
Si no:
el Select será solamente un dato más.
Paso 141. ¿Qué hacer si quiero mostrar campos según una respuesta?
Por ejemplo:
¿Eres empresa?
Sí
↓
mostrar CUIT
Eso implica:
lógica condicional
No se consigue simplemente agregando Inputs.
Utiliza una solución específica si la funcionalidad está disponible.
No improvises JavaScript sin evaluar el procesamiento.
Paso 142. ¿Qué hacer si quiero CAPTCHA?
Eso es una funcionalidad distinta del diseño visual.
No inventes un:
Checkbox “No soy un robot”
Un Checkbox dibujado:
≠ CAPTCHA
Necesita una integración real.
Paso 143. ¿Qué hacer si recibo spam?
No soluciones ocultando el Form.
Debes evaluar:
mecanismos antispam;
configuración del procesamiento.
El Editor de bloques solo resuelve la parte visual de esta guía.
Paso 144. ¿Qué hacer si el formulario no llega por email?
No modifiques:
colores;
Grid;
CSS.
El problema no es visual.
Revisa:
procesamiento;
configuración;
destino.
Paso 145. ¿Qué hacer si funciona pero llega sin el campo nuevo?
Ese campo probablemente no está integrado al procesamiento.
Revisa:
Name;
configuración del backend/integración.
No asumas que agregar HTML actualiza automáticamente el receptor.
Paso 146. ¿Qué hacer si quiero cambiar solo el diseño?
Entonces:
no toques la lógica.
Conserva:
Form;
Name;
Type;
atributos;
estructura funcional.
Modifica:
Border;
Padding;
Typography;
Background;
Column layout.
Es la estrategia más segura.
Paso 147. ¿Qué hacer si no sé qué atributos son funcionales?
Antes de modificar:
copia HTML;
pide ayuda para identificarlo;
no elimines nada;
modifica solamente la presentación.
Utilizar IA puede ayudar.
Paso 148. Prompt de IA para analizar el Form
Este es el HTML de un formulario funcional existente en Waclis:
[pegar únicamente el Form]
Waclis utiliza Bootstrap 4.
Identifica:
- elemento Form;
- Inputs;
- Text Areas;
- Selects;
- Names;
- IDs;
- Types;
- Labels;
- Buttons;
- atributos que podrían participar en procesamiento o validación.
No modifiques nada.
No elimines nada.
No inventes cómo se procesa.
Paso 149. IA para rediseñar sin tocar funcionalidad
Este formulario de Waclis ya funciona:
[HTML]
Necesito modificar únicamente:
- Border radius;
- Padding de Inputs;
- espacios entre campos;
- estilo visual del Button.
No cambies:
- Name;
- Id;
- Type;
- atributos;
- Form;
- orden funcional.
Waclis utiliza Bootstrap 4.
No agregues JavaScript.
Devuélveme solamente CSS localizado a .contact-section.
Paso 150. IA para detectar Names duplicados
Cloné varios Inputs dentro de este Form:
[HTML]
Busca:
- Name repetidos;
- IDs repetidos;
- Labels asociados al campo equivocado;
- Types incorrectos.
No cambies nada.
Indica únicamente qué debo revisar.
Paso 151. IA para revisar campos necesarios
Objetivo del formulario:
[describir]
Campos actuales:
[listar]
Analiza:
- cuáles son necesarios para responder;
- cuáles podrían ser opcionales;
- cuáles parecen innecesarios.
No elimines campos automáticamente.
No hagas recomendaciones legales.
Paso 152. IA para mejorar Labels
Estos son mis campos:
[listar]
Redacta Labels breves y claros en español neutro.
Evita depender exclusivamente de Placeholder.
No cambies el significado de ningún campo.
Paso 153. IA para Placeholder
Campos:
[listar]
Necesito Placeholder de ayuda únicamente donde aporte valor.
No repitas literalmente el Label.
No inventes formatos obligatorios que no existan.
Paso 154. IA para revisar obligatoriedad
Objetivo:
[describir]
Campos:
[listar]
Indica qué información parece imprescindible para poder responder y qué información podría ser opcional.
No asumas que el formulario ya tiene validación.
No generes código.
Paso 155. IA para auditar cambios funcionales
HTML original:
[pegar]
HTML modificado:
[pegar]
Compara únicamente:
- Name;
- Id;
- Type;
- atributos del Form;
- atributos de Inputs;
- Button de envío.
Indica qué cambios podrían afectar funcionalidad.
No corrijas automáticamente.
Paso 156. IA para detectar secretos
Revisa este HTML/JavaScript que se publicará en una Página web:
[pegar]
Busca valores que parezcan:
- contraseñas;
- API secrets;
- tokens privados;
- credenciales.
No repitas el secreto completo.
Indica dónde existe el riesgo.
Paso 157. IA para planificar layout
Quiero crear una sección de contacto en Waclis.
Contenido:
- H2;
- Form con 5 campos;
- información de contacto;
- WhatsApp;
- dirección;
- mapa.
Desktop:
Form a la izquierda;
información a la derecha;
mapa abajo.
Mobile:
Form;
información;
mapa.
Waclis utiliza Bootstrap 4.
Indícame la estructura con:
Section;
Container;
Grid Row;
Columns.
No generes CSS todavía.
Paso 158. IA para revisar responsive
Mi sección de contacto utiliza:
Desktop:
7 + 5
En tablet:
los Inputs quedan estrechos.
Analiza si conviene pasar a 12 + 12 antes.
No reduzcas Typography ni Padding como primera solución.
No generes código todavía.
Paso 159. IA para CSS localizado
Tengo una sección Waclis:
.contact-section
Form wrapper:
.contact-form-wrapper
Información:
.contact-info
Mapa:
.contact-map
Necesito ajustar:
- espacios;
- Border radius;
- Inputs;
- Button;
- responsive.
No modificar:
- otros Forms;
- Header;
- Footer;
- checkout;
- búsqueda.
Waclis utiliza Bootstrap 4.
No agregues JavaScript.
Devuélveme únicamente CSS localizado.
Paso 160. IA para detectar CSS global
Revisa este CSS:
[pegar]
Busca selectores globales sobre:
input
textarea
select
button
label
.form-control
.row
iframe
Indica qué otras partes de Waclis podrían verse afectadas.
No modifiques el código.
Paso 161. IA para mapa
Tengo una sección con:
Dirección escrita:
[pegar]
Ubicación configurada en el mapa:
[pegar datos disponibles]
Link Cómo llegar:
[pegar destino]
Compara únicamente los datos proporcionados y señala inconsistencias.
No inventes coordenadas ni direcciones.
Paso 162. IA para mapa responsive
Tengo este HTML del mapa en Waclis:
[pegar]
Necesito hacerlo responsive dentro de:
.contact-map
Primero identifica si utiliza:
- iframe;
- div;
- otra estructura.
No asumas que es iframe.
No cambies el proveedor.
No ocultes controles ni atribuciones.
Paso 163. IA para formulario que no funciona
Este formulario funcionaba antes de esta modificación.
HTML original:
[...]
HTML actual:
[...]
Problema:
[describir]
Busca diferencias relacionadas con:
- Form;
- Name;
- Id;
- Type;
- Button;
- atributos.
No agregues JavaScript.
No inventes un backend.
Paso 164. IA para prueba funcional
Necesito crear un plan de prueba para este formulario.
Campos:
[listar]
Objetivo:
[describir]
Crea casos para:
- envío vacío;
- datos válidos;
- email inválido;
- campos opcionales;
- recepción de todos los campos;
- confirmación de éxito.
No asumas resultados.
Indica qué debo comprobar manualmente.
Buenas prácticas
Recomendamos:
definir primero el objetivo del Form;
solicitar solo información necesaria;
utilizar Labels claros;
utilizar Placeholder como ayuda;
configurar Types apropiados;
mantener Names funcionales;
mantener IDs únicos;
no marcar todo como obligatorio;
utilizar Text Area para mensajes;
mantener la estructura dentro de Form;
no modificar atributos funcionales por estética;
crear información de contacto visible;
utilizar Links reales;
mostrar dirección escrita;
utilizar mapa como complemento;
verificar el pin;
probar WhatsApp, teléfono y email;
probar un envío real;
comprobar recepción;
revisar responsive;
mantener CSS localizado.
Errores frecuentes
Creer que el formulario funciona porque se ve bien
Siempre envía una prueba.
Agregar un campo y asumir que se enviará automáticamente
Comprueba procesamiento.
Cambiar Name por estética
Puede romper la recepción.
Clonar Input y dejar Name original
Revisa cada campo.
Duplicar IDs
Mantén unicidad.
Utilizar Placeholder como único Label
Puede dificultar la comprensión.
Agregar * y creer que valida
La validación es funcional.
Marcar todos los campos obligatorios
Solicita lo necesario.
Pedir demasiada información
Reduce fricción.
Pedir contraseñas o secretos
Nunca en un formulario genérico.
Utilizar Input para un mensaje largo
Utiliza Text Area.
Utilizar Text Area para Email
Utiliza el componente apropiado.
Utilizar Select con demasiadas opciones
Simplifica.
Utilizar Radio cuando se pueden seleccionar varias opciones
Comprende su función.
Utilizar Checkbox cuando solo debe elegirse una opción
Utiliza el control correcto.
Agregar un CAPTCHA visual falso
Un Checkbox no es CAPTCHA.
Simular mensaje de éxito
Debe depender del envío real.
Ocultar mensajes de error con CSS
El visitante necesita verlos.
Eliminar Focus
Mantén usabilidad.
Reemplazar submit por Link
No cumplen la misma función.
Agregar JavaScript improvisado para enviar
Utiliza procesamiento real.
Colocar credenciales en frontend
Nunca.
Mostrar mapa sin dirección escrita
El mapa es complemento.
No comprobar el pin
Puede llevar al visitante a otro lugar.
Cambiar dirección y olvidar el mapa
Revisa ambos.
Cambiar mapa y olvidar Cómo llegar
Revisa las tres ubicaciones.
Utilizar 20 mapas para 20 sucursales
Evalúa rendimiento.
Utilizar Width fija en mapa
Puede romper mobile.
Aplicar iframe globalmente
Puede afectar videos y otros Embeds.
Ocultar atribución del mapa
Conserva los elementos del proveedor.
Utilizar Background complejo detrás del Form
Prioriza lectura.
Mantener dos columnas en tablet aunque queden estrechas
Apila.
Crear Form desktop y Form mobile duplicados
Mantén una sola estructura responsive cuando sea posible.
No probar teléfono o WhatsApp
Haz clic realmente.
No probar el formulario después de modificar CSS/HTML
Siempre vuelve a probar.
Flujo profesional recomendado
1. DEFINIR OBJETIVO DEL CONTACTO
↓
2. DEFINIR CAMPOS NECESARIOS
↓
3. DEFINIR CANALES ALTERNATIVOS
↓
4. CREAR SECTION
↓
5. CONFIGURAR BOXED / AUTO
↓
6. CREAR ENCABEZADO
↓
7. AGREGAR GRID ROW
↓
8. DEFINIR FORM / INFO
↓
9. DEFINIR RESPONSIVE
↓
10. AGREGAR FORM
↓
11. AGREGAR INPUTS
↓
12. CONFIGURAR LABELS
↓
13. REVISAR TYPES
↓
14. REVISAR NAMES
↓
15. REVISAR IDS
↓
16. AGREGAR TEXT AREA
↓
17. AGREGAR SELECT SI APORTA
↓
18. CONFIGURAR OBLIGATORIEDAD REAL
↓
19. AGREGAR CONTROL DE ENVÍO
↓
20. CREAR INFORMACIÓN DE CONTACTO
↓
21. CONFIGURAR TELÉFONO
↓
22. CONFIGURAR EMAIL
↓
23. CONFIGURAR WHATSAPP
↓
24. AGREGAR DIRECCIÓN
↓
25. AGREGAR CÓMO LLEGAR
↓
26. AGREGAR MAPA
↓
27. VERIFICAR PIN
↓
28. REVISAR LINKED STYLES
↓
29. AJUSTAR DISEÑO
↓
30. REVISAR DESKTOP
↓
31. REVISAR TABLET
↓
32. REVISAR MOBILE
↓
33. GUARDAR CAMBIOS
↓
34. VER PÁGINA
↓
35. PROBAR LINKS
↓
36. ENVIAR FORMULARIO REAL
↓
37. COMPROBAR CONFIRMACIÓN
↓
38. COMPROBAR RECEPCIÓN
↓
39. COMPROBAR TODOS LOS CAMPOS
Checklist del formulario
Sé para qué se utiliza.
Solo solicita información necesaria.
Los Labels son claros.
Los Placeholder son ayudas, no sustitutos de toda la información.
Los Types corresponden al dato.
Los Names fueron revisados.
Los IDs son únicos.
Los campos obligatorios realmente están configurados.
No dependí solamente de *.
Text Area se utiliza para el mensaje.
Select solo aparece cuando aporta.
Radio y Checkbox tienen funciones correctas.
El Button pertenece al Form.
No cambié Type funcional por estética.
Checklist de privacidad y seguridad
No solicito contraseñas.
No solicito secretos.
No coloqué tokens privados en HTML.
No coloqué credenciales en JavaScript.
Solicito solamente datos pertinentes.
Evalué la información de privacidad que corresponda al proceso real.
No oculté avisos importantes.
No inventé un consentimiento que no corresponde.
Checklist de información de contacto
Teléfono es correcto.
Link de teléfono es correcto.
Email visible es correcto.
Link de email es correcto.
WhatsApp utiliza el destino correcto.
El texto de WhatsApp coincide con la acción real.
Dirección es correcta.
Horarios están actualizados.
No quedan datos de ejemplo.
Los canales mostrados realmente se utilizan.
Checklist del mapa
Elegí Google Maps u Open Street Map conscientemente.
Configuré únicamente las opciones reales del Widget.
El pin corresponde al lugar correcto.
La dirección está escrita también como texto.
Dirección y mapa coinciden.
Cómo llegar coincide con ambos.
El mapa tiene altura suficiente.
No utiliza Width rígida problemática.
Mobile funciona.
No oculté atribución ni controles mediante CSS.
No cargué mapas innecesarios.
Probé el mapa desde Ver página.
Checklist responsive
Desktop funciona.
Tablet funciona.
Mobile funciona.
El Form no queda estrecho.
Los Inputs ocupan un ancho cómodo.
Labels se leen.
Text Area es utilizable.
El Button no desborda.
Los Links son fáciles de seleccionar.
El mapa no ocupa excesivamente la pantalla.
No existe scroll horizontal.
Los mensajes de error pueden crecer sin romper el diseño.
Checklist técnico
Utilicé Navigator.
Los Inputs se encuentran dentro del Form cuando corresponde.
Revisé Names.
Revisé IDs.
Revisé Types.
Conservé atributos funcionales.
Revisé Linked styles.
No modifiqué input globalmente.
No modifiqué textarea globalmente.
No modifiqué select globalmente.
No modifiqué button globalmente.
No modifiqué .form-control globalmente.
No modifiqué iframe globalmente.
No agregué JavaScript innecesario.
No agregué un backend improvisado.
El CSS adicional tiene scope.
Checklist de prueba funcional
Intenté enviar vacío.
Comprobé los campos requeridos.
Probé un email inválido.
Completé datos válidos.
Envié el formulario.
Observé la respuesta real.
Comprobé que el envío llegó donde debía.
Comprobé Nombre.
Comprobé Email.
Comprobé Empresa.
Comprobé Select.
Comprobé Mensaje.
Comprobé cualquier campo nuevo.
Probé nuevamente después de modificar HTML.
Probé nuevamente después de cambios importantes.
Checklist final
Guardé los cambios.
Utilicé Ver página.
Probé el Form como visitante.
Probé teléfono.
Probé email.
Probé WhatsApp.
Probé Cómo llegar.
Revisé mapa.
Revisé desktop.
Revisé tablet.
Revisé celular.
Revisé un dispositivo real cuando fue posible.
No existen datos de ejemplo.
No existen Links #.
No existen credenciales públicas.
El visitante puede contactar incluso si el mapa no carga.
El visitante entiende qué ocurrirá al enviar el formulario.
En resumen
Una sección de contacto completa puede estructurarse como:
HEADING
↓
FORMULARIO + INFORMACIÓN
↓
MAPA
Desktop:
┌───────────────────────────┬───────────────────────┐
│ │ │
│ FORMULARIO │ INFORMACIÓN │
│ │ │
└───────────────────────────┴───────────────────────┘
┌───────────────────────────────────────────────────┐
│ MAPA │
└───────────────────────────────────────────────────┘
Mobile:
FORMULARIO
↓
INFORMACIÓN
↓
MAPA
El Form puede utilizar:
FORM
↓
INPUT
↓
INPUT
↓
SELECT
↓
TEXT AREA
↓
SUBMIT
Pero recuerda siempre:
CAMPO VISIBLE
≠
CAMPO PROCESADO
Y:
BUTTON VISIBLE
≠
FORMULARIO FUNCIONAL
Para cada campo debes revisar:
LABEL
TYPE
NAME
ID
REQUISITOS
según las opciones disponibles.
Especialmente:
NAME
puede formar parte de cómo el procesamiento identifica el dato.
No lo cambies por estética.
Tampoco confundas:
Nombre *
con:
validación real de campo obligatorio
La marca visual no crea la lógica.
Respecto del mapa
MAPA
→ ayuda visual
Pero:
DIRECCIÓN ESCRITA
→ información accesible sin depender del mapa
Mantén ambos.
Y comprueba:
DIRECCIÓN
=
PIN DEL MAPA
=
LINK CÓMO LLEGAR
No asumas sincronización automática.
Respecto de WhatsApp
CONTACTAR POR WHATSAPP
→ abre conversación
No:
COMPRAR
→ abre conversación
si la compra no se completa realmente.
Finalmente, el proceso profesional no termina en:
“se ve bien”
Termina en:
GUARDAR CAMBIOS
↓
VER PÁGINA
↓
COMPLETAR CAMPOS
↓
ENVIAR
↓
COMPROBAR RESULTADO
↓
COMPROBAR RECEPCIÓN
↓
COMPROBAR TODOS LOS DATOS
Una sección de contacto está realmente terminada cuando un visitante puede:
encontrar los datos correctos, utilizar los canales disponibles, comprender dónde está ubicada la empresa cuando corresponde y enviar una consulta que efectivamente llega con la información esperada.
Ese último punto distingue un formulario simplemente atractivo de un formulario realmente útil y funcional.
¿Necesitas más ayuda?
Si este artículo no resolvió tu consulta, nuestro equipo puede ayudarte personalmente.
Soporte por WhatsApp