Áreas táctiles y teclados móviles

El formulario se aprobó en una pantalla en la que nadie lo rellena

Los formularios se revisan como se construyen: en un monitor grande, con ratón, por alguien en un escritorio. Después se usan en un teléfono, en un pasillo, con un pulgar, por alguien que estaba en medio de otra cosa. Para la mayoría de las organizaciones, la versión de teléfono no es el caso límite. Es donde está buena parte del tráfico, a menudo la mayor parte. La versión de escritorio que su equipo aprobó es la experiencia minoritaria.

Un puntero de ratón es un único píxel que va exactamente adonde se apunta. Una yema es un instrumento blando e impreciso de más o menos un centímetro de ancho que esconde lo que toca en el momento del contacto. El toque fallido, la casilla equivocada, el enlace pulsado en lugar del botón de al lado: cada frustración móvil con un formulario empieza con un diseño dimensionado para el píxel y entregado a la yema.

Dimensione las áreas para dedos, y deje que la etiqueta reciba el toque

Las pautas de accesibilidad ponen números concretos a lo que necesita una yema. Los puntos de referencia habituales rondan los 44 píxeles para un área cómoda, con unos 24 como mínimo por debajo del cual los toques fallidos vienen prácticamente de serie. Las casillas y los botones de opción nativos no se acercan a eso por sí solos; sin ayuda, están entre los elementos interactivos más pequeños de la web, encargados de un trabajo de precisión en el dispositivo de entrada menos preciso que tiene la mayoría de la gente.

La solución más antigua sigue siendo la mejor, y es gratis: asocie la etiqueta con el control correctamente, y toda la etiqueta se vuelve táctil. El visitante deja de apuntar a una cajita y simplemente toca las palabras «Suscribirme al boletín». Es un área veinte veces mayor, conseguida con un marcado que el formulario debía tener de todos modos.

Es la misma asociación que hace que la etiqueta funcione para los lectores de pantalla, lo cual es un patrón que vale la pena notar: en los formularios, la construcción accesible y la construcción cómoda resultan ser una y otra vez la misma construcción.

El espaciado es la otra mitad del tamaño. Dos áreas de tamaño adecuado pegadas entre sí siguen produciendo toques en el botón equivocado, y el lugar más caro para eso es el que tiene todo formulario: Enviar junto a Cancelar o Restablecer. Si un centímetro mal colocado puede borrar el trabajo del visitante, el diseño (o la existencia misma de ese botón de restablecer) merece una segunda mirada.

Su marcado decide qué teclado aparece

Cuando un visitante toca un campo en un teléfono, el teclado en pantalla que sube no es cosa del destino: lo elige el tipo declarado del campo. Marque el campo como de correo y el teclado llega con @ y el punto en su primera pantalla. Márquelo como de teléfono y aparece un teclado numérico. Deje todo como campo de texto genérico y el visitante recibe el teclado genérico para todo, buscando entre capas de símbolos para escribir una dirección que su marcado podía haber hecho dos toques más fácil.

Las mismas declaraciones alimentan el autocompletado. Los campos que dicen qué son (nombre, correo, organización, dirección) dejan que el navegador ofrezca rellenarlos con lo que ya sabe, comprimiendo el tramo más tedioso de cualquier formulario móvil en un toque. Para un visitante en un teléfono, eso es con frecuencia la diferencia entre terminar ahora y abandonar para un «luego» que no llega.

Una trampa más específica del teléfono: algunos navegadores móviles amplían toda la página cuando el visitante enfoca un campo cuyo texto es más pequeño de lo que el navegador considera legible. El visitante termina de escribir, la página sigue ampliada y descentrada, y el formulario de repente se siente roto. Mantener el texto de los campos a un tamaño cómodo y honesto evita que la ampliación se dispare. Es un recordatorio de que en el móvil, el texto pequeño no solo es difícil de leer; tiene efectos secundarios.

Apague la ayuda que estorba

Los teclados de teléfono vienen con reflejos ajustados para la prosa: poner en mayúscula la primera letra, autocorregir las palabras desconocidas. Apuntados a un campo de mensaje, esos reflejos ayudan. Apuntados a una dirección de correo, la vandalizan: ponen en mayúscula la primera letra, «corrigen» un apellido o un dominio inusual convirtiéndolo en una palabra del diccionario, y fabrican exactamente el problema de dirección equivocada con el que abrió esta serie. El visitante escribió con cuidado; el teclado lo desescribió.

Los campos que contienen identificadores y no frases, como correos, nombres de usuario y números de referencia, deben decirle al teclado que se retire: sin mayúsculas automáticas, sin autocorrección. Es una decisión de una línea por campo, invisible cuando está bien, y silenciosamente corrosiva cuando está mal, porque el visitante rara vez nota la edición del teclado antes de pulsar enviar.

La auditoría está en su bolsillo

Nada de esto requiere un laboratorio. Saque su teléfono, abra su propio formulario y rellénelo de verdad, solo con el pulgar, a paso de caminata, sin caridad. Cada toque fallido, cada teclado equivocado, cada pellizco para ampliar y acertar a una casilla es una nota que un visitante real ya tomó en silencio. Diez minutos de esto son la prueba de usabilidad más barata que su organización hará jamás, y la lista de tareas que produce es refrescantemente concreta.

También cierra el círculo de esta serie hasta ahora: las etiquetas que siguen visibles son también las etiquetas que reciben el toque; los envíos que conservan el trabajo importan el doble cuando volver a escribir significa escribir con el pulgar; los errores que se explican importan más en una pantalla que muestra un campo a la vez. La siguiente entrega sigue con el tema de las cosas que se ven bien en la pantalla del diseñador: controles nativos de formulario en un tema oscuro, y la flecha del desplegable que se desvanece en el fondo.