El problema es el siguiente: si los monitores de sobremesa aumentan la resolución de 72ppp a valores similares a los que se utilizan en impresión, el desarrollador web no tiene herramientas prácticas para que su diseño se escale proporcionalmente a la resolución del dispositivo. (ver conclusiones más abajo)

Los que llevamos años trasteando con la informática vivimos los diferentes saltos de tamaño y resolución de pantallas. Para no irme más allá de los Intel 286, recuerdo que para 14″ la resolución era de 640*480 px. y se podían ver perféctamente los cuatro lados de cada pixel . En 15″ la cosa mejoró a 800*600 px. que todavía sirve como medida standar para ciertos desarrollos web. Luego llegó la hegemonía de las 17″ con sus inmensos 1024*768 px. que el tiempo ya ha empezado a destronar. Y todo esto referido a pantallas de CRT (Tubo de Rayos Catódicos).

la aparición de las pantallas planas supuso subir un paso la resolución con respecto al tamaño del monitor, y así en 15″ ya se pudo disfrutar de 1024*768 px.

Ahora el abanico de resoluciones para dispositivos de sobremesa ha aumentado significativamente, pero siempre guardando una proporción con respecto al tamaño. Esa proporción no es otra cosa que los 72 ppp. (pixels por pulgada).

En medios impresos la resolución estandar es de 300 dpi (dots per inch). de forma que no se aprecian los puntos o los escalonados en lineas diagonales. En pantalla, sin embargo, no son tan evidentes esos defectos y con 72 ppp. se guarda una equilibrada percepción con respecto a la cantidad de información.

Pero entraron en escena los ‘handheld’, dispositivos de mano, móviles sobretodo, que han ido incorporando pantallas cada vez más grandes, tanto que incluso han sacrificado los teclados por sus homónimos en versión táctil. y que además en un afán por mostrar cada vez más información han saltado esa proporción sagrada de los 72 ppp. Sacrílegos!

credit: Jordi Masagué

La palma se la lleva el iPhone 4, que con su Retina Display llega hasta los 326 ppp. Otros ejemplos:

• iPhone: 320×480 | 3.5 in | 164 ppp.
• Palm Pre | 320×480 | 3.1 in 186 ppp.
• Palm Pixie | 320×400 | 2.63 in | 194 ppp.
• T-Mobile G1 | 320×480 | 3.2 in | 180 ppp.
• MyTouch 3G | 320×480 | 3.2 in | 180 ppp.
• HTC Hero | 320×480 | 3.2 in | 180 ppp.
• Motorola Droid | 480×854 | 3.7 in | 264 ppp.
• Nexus One | 480×800 | 3.7 in | 252 ppp.
• HTC Desire | 480×800 | 3.7 in | 252 ppp.
• Nokia N97 | 360×640 | 3.2 in | 229 ppp.
• Nokia N900 | 800×480 | 3.5 in | 266 ppp.

Con ese aumento de resolución se logra más nitidez y definición permitiendo entre otras cosas que las tipografías no pierdan lectura a pesar de la disminución de su tamaño. Pero eso es así por que hablamos de pantallas de entre 3 y 4 pulgadas, que necesitan empequeñecer la información gráfica sin atentar contra la practicidad.

Ahora viene el ejercicio futurológico:

Adelantándome a los acontecimientos, es predecible que la mejora sucesiva del hardware se contagie del aumento de resolución de los dispositivos de mano. Los monitores planos ya son habituales. Los tamaños grandes y extragrandes son asequibles. ¿Cuantas pulgadas tendrá tu próximo monitor? ¿22″, 28″ quizás? El Full HD con sus 1920*1080 px. se convierte en la nueva resolución máxima estandar. Vale, hay monitores con más resolución, pero incluso estos mantienen los 72 ppp. Y además si el propio Youtube se ha preparado para poder servir videos en calidad 4K (4096*2304 pixels) es fácil vaticinar que va a aumentar la densidad de píxeles por pulgada. Calculo 4 ó 5 años para que se implante.

¿Qué pasará entonces si las pantallas de sobremesa aumentan su resolución?

El tema no afecta solo al ámbito informático, si no también al doméstico. Una ‘peli’ full-hd podría verse sin perder un solo pixel en una pantalla de 15″ (o menos).

Enfocando la cuestión únicamente al desarrollo web se dan las siguientes circunstancias:

Los diseñadores web estamos acostumbrados a trabajar al píxel.

Si el píxel se hace pequeño en un dispositivo pequeño nuestro diseño se verá pequeño pero se verá.

Si aumenta la resolución en un monitor de sobremesa, nuestro diseño también se verá pequeño y eso es inadmisible.

Para resoluciones cercanas a las de impresión, diseñar al píxel ya no es tan importante.

¿Hay unidades de medida en CSS porcentuales respecto a la resolución?

NO

Las especificaciones CSS2, en el el punto 4.3.2 Medidas dice claramente:

Si la densidad de píxeles del dispositivo de salida es muy diferente de un típico monitor de computadora, la aplicación del usuario debe re-escalar los valores de los píxeles.

Y el CSS3 no vendrá a salvarnos de momento, por que al menos en ese punto no hay cambios.

Nos tocará añadir un detector de resolución via programación en cliente o servidor y cargar un CSS con las medidas adecuadas, amén de reescalar las imágenes del diseño adaptándolas al ‘pdp’ (piña de píxeles) del dispositivo.

Osea, doble o triple trabajo.

ACTUALIZACIÓN 16/DIC/2011:

W3C tiene en sus especificaciones la versión candidata de CSS3 Media Queries, que permite definir dentro de las etiquetas style o dentro de los archivos css, secciones condicionales según características de los dispositivos de salida.

Por ejemplo, en lo relativo a resolución de pantalla:

<style type="text/css">

#content{ background-image: fondo_100px_x_50px.jpg }

@media screen and (min-resolution: 300dpi){ #content{ background-image: fondo_400px_x_200px.jpg } }

</style>

 

También , los propios dispositivos con resoluciones importantes, léase iphone4, proporcionan sus propias soluciones propietarias:

<link rel="stylesheet" type="text/css" href="css/retinadisplay.css" media="only screen and (-webkit-min-device-pixel-ratio: 2)" >

El futuro se torna interesante.

photo credit: Guillermo Julián

Google está introduciendo de forma escalonada su nuevo sistema para mostrar resultados que denomina Google Instant Search. Consiste en mostrar resultados a medida que se añaden palabras en la caja de búsqueda.
Google lo defiende como un sistema más rápido para que el usuario encuentre lo que busca, pero advierto dos grandes problemas.

1.- Usabilidad
Tengo ganas de ver algún estudio serio al respecto (Jakob Nielsen, ¿estás ahí?), por que la intuición me indica que para el usuario medio debe ser mareante ver aparecer sugerencias de palabras al mismo tiempo que se renuevan los resultados muchas veces y a pantalla completa.

Vale que hayan puesto un link para desactivarlo, pero repito, el usuario medio quedará desconcertado y abrumado por el exceso de información. ¿Por que no lo dejan desactivado por defecto y hacen más visible el botón de activación con una leyenda tipo “PRUEBA NUESTRO NUEVO Google Instant Search“?

2.- Tráfico
El constante refresco de resultados se consigue haciendo peticiones continuas a los servidores de Google que a su vez va devolviendo los paquetes solicitados. Donde antes había una sola solicitud ahora se ejecutan diez veces más. Teniendo en cuenta que Google es una de las páginas más visitadas y por lo tanto responsable de la densidad de tráfico en Internet, esta claro que su nueva implementación podría ralentizar y saturar a la red.

Quizás haya razones técnicas para pensar que esto no será así, que los paquetes de información que mueven son de pocos kbites. Pero al multiplicarlo por las millones de búsquedas que se realizan diariamente con el buscador es evidente que la cifra no es irrelevante.

Barra Sidewiki

No lo he probado, por que no me interesa. Se trata de un sistema mediante el cual e instalando una extensión en tu navegador, puedes comentar acerca de una web, y ver otros comentarios,  pero sin el control del dueño de esa web, aunque si con el control de Google. Aqui hay más información de Google Sidewiki (en inglés).

La queja viene de los creadores o gestores de contenidos que ven como se puede desviar el posible feedback fuera de su dominio, y en consecuencia perder el control sobre la conversación con los usuarios, amén de recortar el “share” de aportaciones y descentralizar el “feed” de comunicación. Completamente de acuerdo. Y además es que Google se convierte en el gestor de esos comentarios paralelos, ordenando y eliminando según su criterio algorítmico y fuera de la linea editorial del sitio.

También es verdad que para algunas páginas que no contemplan, o han eliminado, la opción de comentarios, el Sidewiki puede venir muy bién. Me viene a la mente el dominio principal de Microsiervos que creo recordar eliminaron el formulario para comentar debido al problema de revisar el insufrible Spam.

Atando cabos pienso que el Google Sidewiki podría ser una herramienta sensacional si se crearan sistemas para incorporar esos comentarios a los que vienen por defecto, siempre y cuando al propietario del sitio se le permita tomar ciertas decisiones, como refiltrar los contenidos ya filtrados de Google, reordenarlos también, o aportar posicionamiento en función de cantidad y relevancia, y al fin y al cabo mezclar lo propio con lo ajeno.

Y una cosa más, si el control de spam de Gmail funcionara igual en Sidewiki, algunos cancelarián en seguida los sistemas propios de comentarios.

(Si comentas esta entrada con Sidewiki recuerda que solo los usuarios que también  lo instalaron podrán ver tus opiniones, pero si lo haces desde el propio formulario de Saltarintro, todo el mundo lo verá. )

Se nos quemaba el arroz a los desarrolladores web de Alicante. Menos mal que algunos son más inquietos que otros y no paran ni en boxes. Y así ha nacido ADWA, Asociación Desarrolladores Web de Alicante.

Este jueves 1 de octubre, deberías acercarte al CAMON para ver la presentación oficial. Y es lo mismo si eres freelance, trabajador por cuenta ajena, intrusista, diseñador o programador.

Si algo ha caracterizado al sector web en general es que somos demasiadas mentes independientes que nos vemos de tarde en tarde cuando hay algún evento, para después volver cada uno a su redil, y a su particular percepción de la realidad web.

Es muy importante para estar al día conocer lo que demanda el mercado, lo que sale de los laboratorios I+D, las tendencias en tecnologías, frameworks, lenguages, técnicas, puf…

¿Querías vivir haciendo páginas web? Pues te toca estar al día. Creo que no es muy habitual este tipo de asociaciones en otras provincias asi que es para no dejar pasar la ocasión.

A veces en mi trabajo me ha tocado hacer entrevistas a futuros compañeros de curro, y me he encontrado con desconcertantes faltas de conocimiento en tecnologías que aunque no se usen hay que saber al menos que existen.

Que sepas que ADWA ya ha conseguido también ser Adobe User Group. La cosa va en serio.

Asi que si quieres hablar de esos temas que nos apasionan pero que no puedes hacerlo con tu pareja o amigos por que te miran raro, ya sabes.

En CAMON el jueves a las 19:00. Date de alta en la página y apúntate a la presentación. Las plazas son limitadas, y no, no me dan comisión.

photo credit: justinsomnia

¡Google lo vueve a hacer!

El día de los inocentes (April Fool’s Day en Reino Unido y Estados Unidos) del 2004 sacó a la palestra su Gmail con su almacenamiento ‘Gibante’ y creciente, y sobre todo con Ajax, una tecnología característica y clave de la web 2.0, que hasta ese momento no había sido explotada. Y vaya si explotó. Desde ese momento el poder actualizar datos sin recargar las páginas casi es materia obligada.

Concretando. Google rescata el Ajax usándolo de forma magistral en una aplicación de correo, y a partir de ese momento todo el mundo descubre sus bondades y comienza a utilizarse.

El antes y el después del Ajax se llama Gmail.

Y ahora otra tecnología renace de sus cenizas, también de la mano de Google.

El antes y el después del HTML se llama Wave.

No hablaré de Google Wave que ya hay demasiada información por ahí, pero si sobre algunos acelerones impredecibles que se dan en desarrollo web.

En 1999  la W3C hizo pública la última revisión del HTML, la 4.01, la v.4 salió dos años antes. En esos momentos también se desarrollaba el XHTML como el paso siguiente, y que vería la luz en versión 1 en el 2000.

El XHTML es básicamente un XML con un DTD que cubre las etiquetas revisadas del HTML pero bajo una especificación más extricta en la sintáxis, lo cual lleva a la correcta construcción del DOM y por lo tanto permite la construcción sólida y fiable de aplicaciones web y comportamientos avanzados en javascript.

La evolución del XHTML pasa por su versión 2, que en la actualidad está en desarrollo. En el 2004 el Web Hypertext Application Technology Working Group (WHATWG) empezó a desarrollar el sustituto del HTML 4.01 como versión 5.

Y las dos líneas han ido paralelas con sus fans y detractores desde entonces. En el 2007, la W3C empezó a colaborar junto al WHATWG en HTML5, y a lo largo del tiempo la tecnología que parecía más lógica en la sucesión (el XHTML2) se ha quedado atrás en favor de la que parece más popular entre desarrolladores, el HTML5.

Pero todo indica que como Google ha abrazado el HTML5 abiertamente, haciéndolo rendir bajo su nueva aplicación Google Wave, en el momento en que salga de su beta privada a beta pública, como no, y además será este mismo año, parece claro que por narices los navegadores tendrán que añadir la interpretación de HTML5, y se empezará a usar (y abusar) de sus carácterísticas, aunque todavía no llegue a Versión Candidata a Recomendación. Juas.

Todo esto será muy positivo. Supondrá una actualización del parque de navegadores para que puedan soportar la nueva especificación (las versiones más modernas, o en beta, de el IExplorer, Safari, Firefox, Chrome, u Ópera ya lo hacen parcialmente).

Se mejorará la compatibilidad con estándares, por que el parque de navegadores obsoleto bajará drásticamente.

¿Pero que le pasará al XHTML2?

Que no se convierta en un Betamax el tiempo lo dirá.

Google te pone la miel en los labios el primer mes, 30$, y luego va bajando estrepitosamente cada mes hasta el nivel actual, 1$ y medio.

Ya sé que debería postear más, pero es lo que hay.

Y así aprovecho y actualizo la versión del blog y cambio el theme.

¡Casi todo son ventajas!

photo credit: mil8

Hacía tiempo que no entraba en ask.com a buscar nada pero lo que me he encontrado es bastante inquietante.

Después de leer un artículo en Capire.info sobre el mal uso de la publicidad textual me encuentro que la SERP (Search Engine Result Pages) de Ask.com es un ejemplo perfecto.

Buscando los términos “Diseño web” en Ask.com, el primer resultado es una entrada hacia la wikipedia, y después un listado de 10 enlaces (diez¡¡¡ ni más ni menos) en formato similar al de los resultados normales, pero que son “resultados patrocinados”. Se pueden identificar por que están dentro de un cuadro con un color de fondo azulado tan claro que en la pantalla del portátil casi no se identifica, y por que en la esquina superior derecha, de dicho cuadro, aparece el texto “resultados patrocinados” en un tipo de letra pequeño y gris, que por otro lado me parece normal y correcto.

La cuestión es que la lista de resultados patrocinados se confunde completamente con la de resultados naturales por que estos quedan ocultos en la parte no visible de la página, salvo que se haga scroll, y ello conlleva que muchos usuarios hagan click sobre los anunciantes sin darse cuenta.

Pensando mal diría que el buscador no pasa por buenos momentos económicos y pretende ofrecer a sus anunciantes unos buenos porcentajes de clicks/impresiones para que sigan confiando en ellos. Pero si esa situación se alarga en el tiempo, el número de usuarios de Ask bajará ya que las búsquedas serán confusas y en absoluto útiles.

¿Se está disparando Ask en su propio pié con balas patrocinadas?