Probar, probar, probar

6 de noviembre, 2008 - por

En el desarrollo web una de las áreas posiblemente más descuidada es la de probarlo todo con diferentes navegadores. Descuidar cualquier cosa que tenga que ver con el elemento más crucial de todos (el navegador) es un problema bastante gordo. Aunque no hay una solución perfecta, sí existen formas de corregir parcialmente el problema.

Lo primero, antes de nada, es familiarizarse mucho con los navegadores; convivir con ellos; hacerse cargo de su diversidad; entender los distintos motores de renderización (“layout engines”) y cómo se apoyan los navegadores en ellos; comprender la forma en que se produce esa renderización… Todo esto siempre es mejor hacerlo, aunque sea un poquito, que no hacerlo. El resultado, además de los conocimientos concretos, es una actitud desde la que es más fácil resolver problemas y crear cosas, y desde la cual la diversidad dejará de ser percibida como un obstáculo para ser explotada como un beneficio.

Podemos empezar por echarle un ojo al listado que de navegadores que ofrece Wikipedia.

Una vez que ya estamos con esa “mochila”, podemos afinar un poco, distinguiendo las cosas que pueden variar de unos a otros navegadores: marcado, hojas de estilos, nivel del DOM, soporte de imágenes, etc.

Con todo eso, es razonable crear una plataforma mínima de pruebas. La complejidad y coste de la plataforma de pruebas estará en función de nuestras necesidades. En la red hay algunas cosas interesantes.

Por ejemplo, si queremos hacer alguna prueba puntual, y no necesitamos resultados inmediatos, browsershots.org está bastante bien. Es abierto, gratuito y fácil de utilizar, e íntegramente web. Utiliza una nube de ordenadores voluntarios a los que envía las peticiones, y que escupen capturas de pantalla que luego puedes visitar directamente en la web. No es muy rápido, y la captura es plana. En esta misma línea, hay soluciones comerciales como browsercam.com, y litmusapp.com, que funcionan bastante bien, y son más rápidas que la primera. El principal problema que le encuentro a todas ellas es que necesitan trabajar con urls públicas, lo que en entornos de desarrollo no es habitual.

Si, por el contrario, necesitamos realizar periódicamente pruebas y no sólo disponer de una captura de pantalla, sino poder analizar/modificar directamente el código, lo mejor es montarse un entorno de pruebas instalando diferentes sistemas operativos (so), diferentes navegadores y distintas versiones de cada uno de éstos. Esta gama puede variar; si se trata de algo que ya está en marcha y tiene unas estadísticas de uso muy concretas (por ejemplo, Windows XP con IE6 y Windows Vista con IE7), podemos concentrarnos en ese grueso; si se trata de algo nuevo (un portal, una aplicación, etc.), entonces dependería de la orientación que se le quisisera dar (¿pcs? ¿dispositivos móviles?…). En cualquier caso, es bueno habituarse a mirar las estadísticas de uso globales (por ejemplo, el XiTi Monitor), y de ahí extraer una idea sobre lo que se necesita.

La forma de montar un banco de pruebas de este tipo pasará casi siempre por tirar de máquinas virtuales, para correr los diferentes sistemas operativos, e intentar instalar el número máximo de versiones de un mismo navegador en una misma máquina virtual, de forma que minimicemos las complicaciones y la pesadez de tener levantadas varias.

Un tercer elemento importante es el de los dispositivos. Es bueno, para simplificar, considerar los monitores como un dispositivo más, como podría serlo un móvil, una pda o un tablet. Lo más importante es tener en cuenta la resolución de pantalla y la profundidad de color (bits por píxel). En ésto tambien es bueno habituarse a consultar las estadísticas sobre uso de dispositivos, que suelen incluir su resolución de pantalla y su profundidad de color. Como en el caso de los navegadores, hay diversidad; y como entonces, no debemos interpretarla como un obstáculo sino como un beneficio, adaptándonos a ella. Quizás la prueba más importante sea la de comprobar que la paleta cromática que estamos utilizando se ajusta igual de bien a profundidades de 24, 16 y 8. Y es ahí donde el uso los llamados “colores seguros para la web” así como de los “browser-safe colors” (Lynda Weinman) adquiere toda su importancia.

Como hay un montón de chicha en todos estos temas, voy a intentar ir escribiendo entradas para ir complementando esta información.

Tema: Desarrollo, Frontend

Etiquetas: , , , , , , , , , .


Otras entradas que pueden interesarte