Map picker

El flujo óptimo de captura de ubicación usa dos capas secuenciales: primero un campo de texto con autocompletado para velocidad y validación, luego un pin arrastrable en el mapa para precisión de último metro. El usuario suele saber su calle pero no puede describir donde esta exactamente la entrada, sobre todo en edificios grandes o zonas sin nomenclatura formal. Separar texto y mapa en pasos explicitos reduce errores de entrega. Mapbox reporta que su autocompletado baja la captura a unas 10 pulsaciones frente a unas 35 en formularios tradicionales (dato auto-reportado de Mapbox sobre su propio producto).

Cada vez que el usuario mueve el pin (arrastrandolo o por geolocalización), ejecuta reverse geocoding y muestra la dirección legible en texto visible, no solo las coordenadas. Así el usuario verifica que el pin cayo en el lugar correcto antes de confirmar; sin esa confirmación textual no puede detectar errores de precisión del geocodificador. Guarda ambos: coordenadas (lat/lon) para routing y la dirección estructurada para display. Si el pin cae a más de unos 50 m de cualquier dirección validada, conserva el texto previo y actualiza solo coordenadas para evitar que el campo "salte" a una calle equivocada.

Solicita el permiso de geolocalización solo cuando el usuario hace una acción que lo requiere (un botón "Usar mi ubicación"), nunca de forma automática al cargar. Una solicitud sin contexto se rechaza con mucha más frecuencia y puede bloquearse de forma permanente, eliminando la posibilidad de recuperarse. Más del 90% de las solicitudes de permisos en Chrome para Android fueron infructuosas cuando se pidieron sin contexto (Chris Wilson, Chrome Dev Summit 2017). Muestra primero una explicación HTML del beneficio y dispara el prompt nativo solo si el usuario confirma; las solicitudes sin contexto se conceden hasta un 40% menos y un 75% de usuarios son más propensos a activar la localización si entienden el beneficio (criterio: fuentes secundarias).

Un pin arrastrable sin feedback de estado (cursor de agarre, sombra de elevación, animación de caida) deja al usuario sin saber si la acción se registro. Durante el arrastre el pin debe "levantarse" del mapa con cursor grabbing y sombra; al soltarse debe "caer" con confirmación textual inmediata. Ejecuta el reverse geocoding en el evento de mapa detenido (dragend u onIdle), no en cada píxel movido, para evitar llamadas y costos excesivos. El área interactiva del marker (en producción suele rondar 38x56 px, anclada en la base) debe ser suficiente para selección tactil sin errores.

No todos los casos requieren precisión de número de puerta. Un picker de delivery necesita coordenadas exactas a nivel de edificio o unidad, mientras que un picker de zona de cobertura o "cerca de mi" puede operar con precisión de barrio o ciudad. Exponer más precisión de la necesaria aumenta fricción; exponer menos genera errores de entrega. Declara el nivel de precisión en la UI y en los parámetros de API: para delivery, haz zoom automático a nivel de calle al confirmar (criterio); para busqueda por zona, basta geolocalización por IP (~5-50 km, silenciosa, sin permiso) frente al GPS con alta precisión (~5-50 m, requiere permiso).

Cuando el pin o la dirección cae fuera del área de servicio, notificalo de inmediato, no al final del checkout. La señal debe ser proactiva: el mapa indica visualmente que zonas están habilitadas (overlay translucido) en vez de reactiva (un error al confirmar). El pin sobre zona deshabilitada debe verse atenuado y mostrar un mensaje contextual al soltarse. Ofrece la alternativa más cercana o captura el email para avisar cuando se expanda la cobertura, en lugar de dejar que el usuario llene todos los datos de entrega para descubrir al pagar que no llegas.

El mapa interactivo es el camino óptimo para la mayoría, pero no para todos: usuarios con discapacidad visual, conexiones lentas, o que conocen su dirección exacta necesitan un fallback de texto completo que no requiera interactuar con el gráfico. NN/g recomienda que en location finders móviles la vista por defecto sea de lista, no de mapa. MDN documenta como fallback obligatorio ante denegación de permiso la entrada manual, la ubicación por IP o servicios de terceros. La alternativa no debe estar enterrada en un link diminuto: visible junto al mapa, con la misma confirmación que el flujo gráfico.

Los iframes y scripts de mapas son componentes pesados que no deben bloquear el render inicial. Los embeds pueden incluir más de 100KB de JavaScript y en algunos casos hasta 2MB (web.dev), y el mapa rara vez es el Largest Contentful Paint: el formulario o el CTA lo preceden en importancia. Usa el patrón de facade: una imagen estática del mapa como placeholder que se reemplaza por el mapa interactivo real solo al primer hover o clic. El atributo loading="lazy" en iframes no basta porque el browser aún los descarga temprano; en hover haz preconnect al proveedor y en clic monta el embed real.