El problema de la resolución de pantalla es uno de los dilemas eternos a los que nos tenemos que enfrentar los que nos dedicamos al desarrollo web. Si bien, desde la llegada del concepto de separación de diseño y contenido se trata de un dilema menos crítico y más subsanable, sigue ocupando cierto tiempo de debate y de toma de decisiones ¿Saltamos a X resolución? ¿Nos quedamos en X otra resolución?

Entre la gente que sabe, el debate suele quedar siempre en que las soluciones pasan por centrarse en una correcta disposición de contenidos (por supuesto, fundamental) y, o bien determinar un ancho fijo adecuado, en función las estadísticas, o bien encomendarse a porcentajes y layouts líquidos (que éstos últimos son como los unicornios – ¿alguien ha visto alguno?)

Sí, en realidad sí existen algunos sitios con layouts más o menos líquidos (porcentualmente no son demasiados) pero ¿Cuánto de efectivos son? ¿Son la solución? Para el que responda que sí, que lo son, le invito a navegar Amazon en mi pantalla, de 1920×1200 (¡yeh! ¡da grima!). Bueno, aunque en realidad no es layout puramente líquido, la barra del menú lateral es fija, pero cualquier layout líquido se vería igual de mal.

En la práctica, se demuestra que la solución aplicada por la inmensa mayoría se reduce a apostar por un ancho fijo y rezar por que el panorama de resoluciones no cambie demasiado.

Yo creo que todo el problema surje de que la inmensa mayoría estamos centrados en una idea muy obsoleta. Estamos tiranizados por el pixel.

Pensamos en pixels.

Quizás, hasta hace poco, podía tener cierto sentido pensar en pixels. Hay que tener en cuenta que durante más de diez años las pantallas de los ordenadores personales se movieron en el pequeño margen de 640×480 y 800×600. Dicho estancamiento se fundamentó en una cuestión de tecnología, espacio físico y coste. Pero, la introducción de las pantallas de cristal líquido ha cambiado radicalmente éste panorama. Y, por supuesto el avance no se va a detener aquí, estamos solo ante el principio de un desarrollo, que vendrá determinado por la llegada de nuevas tecnologías, que sustituyan a las actuales, y aporten mucha mayor definición. La tinta electrónica es solo un ejemplo.

¿Quién nos dice que una pantalla de portátil normal no pueda tener 3.000px o 5.000px de ancho, de definición, en unos pocos años? ¿Y por qué no?

En la siguiente gráfica (sin ningún valor científico) podemos observar aproximado el aumento de número de puntos en pantalla de las pantallas convencionales utilizadas a nivel de usuario.

Si bien los datos son a ojo, basados en mi observación, estoy seguro se corresponden de manera bastante fiel con la realidad. Desde los CRTs de 320×200 hasta los actuales y habituales TFTs de 19 pulgadas. La evolucióna es muy clara.

¿Qué vamos a hacer entonces con nuestros layouts? ¿Vamos a seguir encomendándonos al ancho de turno? (Por cierto, ¿y que pasa con el alto?)

¿Qué origina el que sigamos pensando en pixels?

Creo que uno de los motivos de que sigamos pensando en pixels es que aquellos que desarrollan las interfaces de los propios sistemas operativos siguen pensando en pixels. Y la influencia de los S.O. es pesada. Los usamos a diario durante muchas horas. Volviendo a mi ejemplo, si alguien ve un arranque de un Windows XP, recién instalado, en mi pantalla de 1920×1200 y de 15,4″, sé dará cuenta al momento de que hay algo que va mal. Para poder leer el nombre de los iconos se necesita de verdad una lupa. Por otro lado, si aumento el tamaño de la tipografía en todo el sistema, los elementos de la interfaz comienzan a deformarse horriblemente ya que están basados en mapas de bits. Lo mismo que ocurre con los iconos. Son mapas de bits ¡Pero bueno!, a éstas alturas, y con la potencia actual de las máquinas ¿Cómo es que, habiendo una amalgama tan grande de resoluciones, los iconos de los S.O. no son vectoriales? ¿Por qué la barra de inicio y demás elementos de la interfaz tampoco lo son? Desconozco verdaderamente si en Vista o en otros S.O. es así, pero según tengo entendido no lo es. Si todos estos elementos fueran vectoriales, la estupenda resolución, llamémosla mejor definición, de mi pantalla, por ejemplo, se convertiría en una ventaja para el usuario medio, y no en un contratiempo.

Dicho ésto, es cierto que existe un problema añadido a la conversión de textos y pequeños elementos en objetos vectoriales, y que nos sigue reteniendo en cierta forma atados al pixel. Por contra de lo que pasaba con los CRTs, en los monitores TFT cada pixel se corresponde con un diodo (¿diodo?), lo que ocasiona que los TFTs tengan una resolución nativa única. Ésto origina que cuando un punto tiene que ser representado en un espacio que no se corresponda con un número entero de pixels, aparezca un molesto efecto de difuminado (todos hemos experimentado ese efecto al asignar una resolución de pantalla menor a la nativa de una pantalla TFT). Pero a medida que las tecnologías avancen, y con ellas el aumento de definición, ésto debería dejar de ser un obstáculo.

El segundo problema, que origina nuestra esclavización a los pixels es puramente psicológico. Se ha creado hábito. Ese inmovilismo de resoluciones durante tantos años, a mi parecer, ha pesado. Y en realidad, para nosotros, es, ciertamente, bastante cómodo hacerlo así: todo como mapas de bits. Aunque también es verdad que mucha parte de la culpa la tiene la siguiente cuestión.

El tercer problema es quizás el más obvio de todos: El impedimento que suponen las imágenes que no pueden ser vectoriales. Es decir, las fotos. Y hoy por hoy, y mientras CSS3 no sea una realidad palpable y/o SVG se extienda definitivamente, a las fotos se añaden también todos los elementos gráficos decorativos que utilizamos, como gradientes, sombras, etc, y que hoy por hoy son mapas de bits. Con éstos no hay escalado que valga, si pretendemos que la calidad de los diseños y contenidos sea la correcta.

¿Soluciones?

Yo creo que la solución podría pasar por el desarrollo un nuevo concepto en la presentación visual de los contenidos. Más cercana a la renderización de Flash, pero por supuesto manteniendo los estándares y las convenciones actuales.

La idea sería que el tamaño de todos los elementos se determinara en base a un cálculo relativo de porcentaje, imágenes incluídas. Y por tanto que un sitio web se viera exactamente “igual” y con las mismas proporciones en pantallas de mismas dimensiones, fuera cual fuera la resolución nativa o utilizada. La diferencia visual estribaría en la mejor o peor calidad de lo que viésemos, según la definición de la pantalla, pero nada más.

Para solucionar el problema de las imágenes, éste nuevo concepto debería venir acompañado con nueva tecnología de servidor, y en la comunicación de agente de usuario – servidor. Los agentes de usuario solicitarían los mapas de bits adaptados al tamaño asignado a un mapa de bits (obtenido previo cálculo en base a un porcentaje). Por supuesto en éste supuesto en el servidor se almacenarían las imagenes con la mayor resolución y calidad posible, para así poder ofrecer versiones adecuadas a cualquier definición.

También, si me apuran, ésta tecnología podría venir combinada con tecnologías de redimensionamiento como Seam Carving, la cual independiza el redimensionamiento del factor relación de aspecto.

Ésta solución mataría además dos pájaros de un tiro con el problema de las imágenes. Se acabó redimensionar las imágenes para cada uso “a mano” o mediante programación y componentes específicos en el servidor.

Además todo ésto podría ser configurable. En función del ancho de banda disponible, por ejemplo, podríamos optar por navegar sitios con imágenes en la definición máxima adaptada a nuestras pantallas, o a menor definición. También serviría, indudablemente, para la mejora de la accesibilidad.

Hoy por hoy se podría experimentar con algo “parecido”, pero tendríamos que recurrir a artimañas, javascripting, AJAX y/o al redimensionado de imágenes en el lado del cliente. Vamos, una locura.

También, a día de hoy, tenemos el caso del iPhone, que hace uso de un sistema de escalado pero a la inversa, en éste caso para presentar layouts que representan más pixels que los que contiene su pequeña pantalla. Lo que comento debería servir en ambos sentidos.

En definitiva y resumiendo, en mi opinión, una futura solución pasaría por la utilización de porcentajes para todos los contenidos y elementos, lo que incluiría imágenes vectoriales para aquellas que pudieran serlo y fotografías/vídeos redimensionados por el servidor bajo demanda.

Se acabaría nuestra pixeldependencia.