Probar en dispositivos que no tienes
Un simulador te habla del maquetado. No puede decirte cómo se siente la página en un Android de hace cuatro años, y fingir lo contrario es como los fallos llegan a producción.
Simulator Panel previsualiza una página en varios tamaños de dispositivo a la vez, con DevTools integradas —consola, red y almacenamiento— además de captura de pantalla en todos los dispositivos, perfilado de rendimiento y accesibilidad, comprobador de contraste, validador de áreas táctiles y configuraciones de dispositivo propias.
Lo que cambia el flujo de trabajo es la parte multidispositivo. Redimensionar una ventana es una secuencia; ver cuatro anchos en paralelo es una comparación, y es en la comparación donde te das cuenta de que el diseño de tarjetas se desmonta justo en un punto de ruptura.
Qué tamaños conviene mantener abiertos
La tentación es añadir todos los dispositivos de la lista. Ocho vistas previas son ocho ventanitas y dejas de leer todas.
Cuatro es el número que sigue siendo útil:
- Un móvil pequeño: el ancho más estrecho que dices soportar. Aquí es donde el texto se parte mal y los botones chocan.
- Un móvil grande: donde realmente está tu tráfico móvil.
- Una tableta en vertical: el tamaño que todos olvidan y donde los diseños de escritorio aparecen en el momento equivocado.
- Un portátil, no un monitor de 27 pulgadas. La mayoría de visitantes de escritorio están en 13 o 14 pulgadas, y los diseños hechos en monitores grandes se rompen allí con regularidad.
Las configuraciones de dispositivo propias merecen la pena una vez si tienes un sesgo real de audiencia: una resolución de kiosco, una tableta concreta que usa un cliente. Hazlo una vez, guárdalo y deja de pensarlo.
Las dos comprobaciones que merecen la pena siempre
Las herramientas de accesibilidad tienen fama de producir cien avisos sobre los que nadie actúa. Estas dos son distintas, porque fallan por motivos que arreglas en un minuto y afectan a personas reales de inmediato.
Contraste. El texto gris sobre fondo blanco es el fallo de accesibilidad más común de la web, y suele aparecer cuando alguien aclara un color para que el diseño se vea más calmado. El comprobador te da un número; si suspende, oscurece el texto en lugar de discutir con el número.
Áreas táctiles. Un control que va bien con el ratón puede ser genuinamente difícil con el pulgar. El validador marca lo que es demasiado pequeño, y la solución suele ser relleno, no un rediseño. Esto importa sobre todo en la vista del móvil pequeño, que es justo la que se salta la gente.
Ejecuta ambas antes de la revisión, no después. Un fallo de contraste detectado en revisión cuesta una ida y vuelta; detectado en el panel cuesta una tecla.
Capturas de todos los dispositivos a la vez
La captura conjunta es más útil de lo que parece, por una razón concreta: es la forma más rápida de hacer discutible un problema de maquetado.
«En móvil se ve mal» abre una discusión. Cuatro capturas a cuatro anchos adjuntas a la tarjeta la cierran. Y como las capturas vienen del mismo momento, nadie puede sugerir que mirabas una compilación vieja.
Adjúntalas a la tarjeta en vez de pegarlas en el chat. La tarjeta es donde alguien mirará dentro de tres semanas cuando se pregunte por qué cambió el relleno.
Lo que un simulador no puede decirte
Esta es la parte en la que conviene ser honesto, porque el modo de fallo es silencioso.
Un simulador renderiza tu página a un tamaño dado, en tu motor de navegador, en tu máquina y por tu conexión. Es preciso con el maquetado e inútil con todo lo demás.
No te dirá que la página tarda once segundos en un Android de hace cuatro años, que la tipografía se ve distinta en un iPhone real, que la cabecera fija tapa el campo cuando se abre el teclado en pantalla, o que la animación se entrecorta en hardware sin una GPU decente. Esos son los fallos que llegan a producción tras un pase limpio del simulador.
Así que usa el panel para lo que es realmente bueno —maquetado, contraste y áreas táctiles— y ten un Android barato de verdad sobre la mesa para el resto. Un dispositivo físico captura una categoría de problemas que ningún simulador alcanza.
Para la parte de rendimiento, Web Analyzer mide una página tal como se sirve realmente, no como se renderiza en local. Esa es una pregunta distinta de «¿aguanta el maquetado?» y conviene hacerla por separado antes de un lanzamiento.
Preguntas que la gente hace
¿Cuántas vistas previas de dispositivo debería tener abiertas?
Cuatro: móvil pequeño, móvil grande, tableta en vertical y portátil. Ocho vistas son ocho ventanitas y dejas de leerlas todas. El portátil importa más que un monitor grande: la mayoría de visitantes de escritorio están en 13 o 14 pulgadas.
¿Qué comprobaciones de accesibilidad merecen la pena de verdad?
Contraste y áreas táctiles, siempre. Ambas fallan por motivos que arreglas en un minuto y ambas afectan a usuarios reales de inmediato. Ejecútalas antes de la revisión, no después: en revisión un fallo de contraste cuesta una ida y vuelta.
¿Puedo dejar de probar en dispositivos reales?
No. Un simulador es preciso con el maquetado y ciego a todo lo demás: rendimiento real, renderizado de tipografías, el teclado tapando un campo, la animación en hardware flojo. Ten un Android barato sobre la mesa.
¿Cuál es la forma más rápida de reportar un fallo de maquetado?
Captura todos los dispositivos a la vez y adjunta las imágenes a la tarjeta. Cuatro anchos del mismo momento convierten «en móvil se ve mal» de discusión en hecho, y la tarjeta es donde alguien lo buscará después.
