web

Google Chrome ahora con Web Sockets

La noticia del día en cuanto a desarrollo web sin duda ha sido la implementación de Web Sockets en Chromium. una tecnología de comunicación bidireccional para aplicaciones web.

Los Web Sockets son un borrador del W3C que, mediante una conexión TCP, permiten realizar fácilmente un Server Push, es decir, una petición iniciada desde el servidor central. Es un cambio notable en la programación web, hasta ahora dirigida por peticiones iniciadas desde el cliente.

Mejora progresiva

De un tiempo a ahora, cada vez leo con más frecuencia el término progressive enhancement, o en catellano, mejora progresiva. ¿Qué es exactamente? Como desarrolladores web, debemos lidiar con numerosos navegadores, cada uno con una serie de prestaciones y recursos. Como veremos a continuación, normalmente hay 4 formas de abordar esta situación:

  1. Impedir el acceso a determinados navegadores. Creedme, existen páginas a las que no se puede acceder con según qué navegadores. No me refiero a que se muestren defectuosas, es que directamente te muestran un mensaje de error. Tratad de acceder a una página de El Plural cambiando el user-agent de vuestro navegador y sabréis a qué me refiero. Ésta es una pésima solución.
  2. Quedarnos en el mínimo común denominador. Esto es, diseñar la página de modo que sólo contenga recursos disponibles por todos los navegadores. No es una solución muy escalable, puesto que se está limitando a las funcionalidades mínimas (Funcionalidades que, por otro lado, normalmente se corresponden con las de nuestro querido IE6). Visto con un enfoque más visual, esto significa que la manada debe ir a la velocidad del más lento. Por ejemplo, querémos posicionar un <div> de forma ‘fixed’. IE6 no lo permite, de modo que, o no lo hacemos, o dedicamos esfuerzos en buscar retorcidos hacks para lograrlo en este navegador. Mmmm no me gusta. ¿Qué más hay?
  3. Graceful degradation. Durante mucho tiempo ésta ha sido la tendencia reinante, y seguramente seguirá siéndolo. Consiste en partir del máximo de prestaciones de forma que, a medida que se usen navegadores menos avanzados, la página se mantenga usable con pequeños defectos. Un ejemplo perfecto es el uso de imágenes PNG con semitransparencias: Mientras que los usuarios de Firefox o Safari las verán sin problemas, los de IE6 se encontrarán con imágenes corruptas. En estos casos es frecuente dividir la página en dos niveles: El nivel 1 corresponde a una buena experiencia para el usuario, el nivel 2 con una versión degradada de la página. Encontramos un ejemplo en el servicio de correo de Google Gmail, con su versión avanzada (Por defecto) y una versión básica.
  4. Mejora progresiva. Y al fin llegamos a la mejora progresiva. ¿En qué consiste? Es exactamente igual que graceful degradation pero al revés. En lugar de partir de una versión avanzada, se parte de la versión mínima, de forma que, a medida que un navegador ofrece mejores recursos, la página también se ve mejorada. En este caso, se parte de un mínimo razonable, por ejemplo, que sea compatible con HTML 4. Podría, por ejemplo, usarse transparencias en GIF, y sin embargo, en aquéllos navegadores que sí lo soporten, semitransparencias en PNG.

Lógicamente las dos mejores soluciones son las dos últimas. ¿Cuál es mejor? Realmente depende del caso. Pero como método general yo prefiero la mejora progresiva, pues a diferencia de graceful degradation parte de una experiencia de usuario razonablemente buena. Además, con esto siempre ganaremos en accesibilidad.

Si bien cada día existen más navegadores con sus respectivas versiones, también es cierto que disponemos cada vez más de recursos que nos permiten abstraernos de ellos, como los numerosos frameworks javascript como jquery o mootools, además de brillantes soluciones como Google Chrome Frame.

Más información:

Nueva página web de Torrijos

captura5El pasado día 11 de junio se presentó en el salón de plenos del Palacio de Pedro I la nueva página web del Ayuntamiento de Torrijos. Este momento marcó un punto y aparte en este nuevo portal para el ciudadano. Durante los últimos meses hemos dedicado muchísimos esfuerzos, ganas e ilusión a este proyecto, y creo que hemos logrado nuestro objetivo: Ofrecer una web renovada con contenidos de actualidad que sustituyera a la antigua.

Y Facebook superó a Tuenti

O al menos para mí ya está bastante claro. Hace unos dos meses Alexa nos decía que Facebook los había superado. Por aquel entonces Facebook estaba en la posición #7 y Tuenti en la #8. Sin embargo las métricas de Alexa son bastante dudosas, y para más inri Google Trends nos decía que Tuenti seguía siendo superior a Facebook. Pero las cosas han cambiado…

Actualmente, según Alexa, Facebook ya ha alcanzado la posición #5 de España, mientras Tuenti se mantiene en la #8. Pero eso no es lo más importante. En mi opinión lo más significativo es que según Google Trends, desde la actualización de hoy, Facebook supera a Tuenti.

tuenti-facebook1

Ahora sí. Para mi ya es oficial.

Facebook como plataforma de usuarios

Facebook es un monstruo que cada día gana más y más adeptos. Por suerte o por desgracia parece que se está convirtiendo en una necesidad para todos los usuarios contar con una cuenta en este sistema. Uno de las razones de su éxito es la de facilitar a los desarrolladores interactuar con su plataforma. Todo comenzó permitiendo el desarrollo de aplicaciones dentro de su web. Ahora ofrecen mucho más. ¿Qué podemos hacer gracias a Facebook?

Lejos quedan aquellos tiempos en los que una página web era autocontenida. Hoy todos entendemos como normal relegar ciertos servicios en manos de terceros, como por ejemplo mapas, vídeos, audios, encuestas o fotografías. Sin embargo hasta ahora ninguna plataforma de usuarios ha llegado a cuajar del todo.

Si bien existe OpenID y su uso está muy extendido, poca gente lo utiliza o entiende cómo funciona, ni siquiera mediante la ayuda de Google y Yahoo! En cambio Facebook, con su conocido Facebook Connect parece estar ganando la batalla.

Facebook Connect

Facebook Connect en funcionamiento

Es un todos ganan:

  1. Facebook, porque hace más necesaria e ubicua su plataforma.
  2. Desarrolladores, porque se agiliza la programación, se invita a participar con facilidad, y se cuentan con fichas más exactas y completas.
  3. Usuarios, ya que no necesitan registrarse en otra nueva página para participar.

La gran pega, como ya se sabe, es la dependencia de terceros para algo tan crítico como son los usuarios. Además que no todo el mundo tiene cuenta en Facebook.

Igualmente curioso es el hecho de que esta misma tecnología consiste básicamente en lo mismo que Microsoft siempre ha querido hacer con Windows Live ID (Anteriormente Microsoft Passport), que no es mas que un servicio de Single Sign-On: Utilizar una misma cuenta para acceder a diferentes servicios.

Pero ahora Facebook no sólo nos ofrece su sistema de autenticación de usuarios, sino que desde hoy también permite añadir un sistema de comentarios sencillo de administrar y sin necesidad de programación. En esto tampoco son pioneros, pues con Google Friend Connect ya podíamos hacerlo.

Con todo esto, si utilizamos Facebook como plataforma de usuarios obtendríamos:

  • Agilidad. En unos minutos tendríamos el sistema de usuarios listo en nuestra web.
  • Exactitud de información. Los datos que los usuarios completan en Facebook suelen ser de bastante calidad.
  • Mayor presencia. Podríamos añadir notas en su muro.
  • Comentarios. Gracias a la nueva herramienta.
  • Red social. Por supuesto los enlaces de usuarios dentro de Facebook puede funcionar dentro de nuestra web.
  • Más participación. Puesto que no es necesario registrarse para participar en nuestra web.

Pero como dije antes, puede resultar un precio demasiado caro.

A título personal, todas las páginas que he creado funcionaban con un sistema de usuarios propio. Tengo bastantes ganas de poner en práctica una visión distinta, y Facebook hoy por hoy me parece la opción más sencilla y con posibilidades de éxito.

Cómo escribir un archivo CSS

A veces trucos sencillitos nos ayudan mucho en el día a día de la maquetación web. En este minipost voy a intentar convenceros de que es mejor escribir todas definiciones de una clase en una sola línea, en lugar de en varias.

Partamos de un ejemplo cualquiera. Tenemos un estilo CSS para un párrafo que utiliza la clase “foo”:

p.foo {
   border: 1px solid red;
   background-color:#EEE;
   font-size: 12px;
   padding: 20px;
   width: 300px;
   float: right;
}

Si digo que es más cómodo ponerlo todo en una línea muchos pensaréis “no… Es incómodo y queda mal estructurado”:

p.foo { border: 1px solid red; background-color:#EEE; font-size: 12px; padding: 20px; width: 300px; float: right; }

Pues después de mucho tiempo funcionando con este tipo de sintaxis he de decir que es muchísimo más cómodo trabajar con estilos en una sola línea, que tabulados y multilínea. El motivo a continuación :)

Normalmente una página web cualquiera puede tener más de 50 clases de estilos como la que he puesto en el ejemplo de arriba. Sin embargo prácticamente nunca se tienen más de 10 estilos dentro de una clase. De ese modo, cuando tenemos que modificar algo en nuestra hoja tenemos primero que localizar el lugar en el que se encuentra aquéllo que queremos actualizar.

El grueso de nuestra búsqueda está en localizar la clase, ya que tenemos más de 50, y no el estilo, ya que rara vez sobrepasan los 10. Echémos números.

Vamos a suponer 70 clases, con una media de 6 estilos. Si nuestra hoja utiliza el primer método tendrá 9 líneas por clase (Añadimos una línea en blanco entre ellas), por lo que el fichero resultante tendría la friolera de 630 líneas!

Ahora lo codificamos con el segundo método. Una linea por clase, y en total… 70 líneas. Eso es un gran ahorro en búsqueda!

Dicho de otra forma. En lugar de buscar entre 630 “campos”, tendremos que buscar entre 70 y entre 6. Esto en algoritmia se llama optimización :)

SVG y la web

Los mapas de bits no escalan (Y nunca mejor dicho), por lo que en numerosas situaciones es preferible utilizar imágenes vectoriales. Por ejemplo, los escritorios de Linux ya están permitiendo emplear iconos vectoriales, de modo que se vean siempre bien definidos independientemente de su tamaño o de la resolución de la pantalla. Existen muchos formatos propietarios, pero, como siempre, para garantizar la interoperabilidad es preferible utilizar estándares, y ese es el formato SVG, que es un lenguaje para describir imágenes y aplicaciones gráficas en XML.

En el mundo web es igualmente interesante poder empotrar imágenes dinámicas generadas mediante SVG. Por ejemplo, hace un tiempo quise hacer unos mapas de densidades de población por municipios generados de forma automática para la Wikipedia. En realidad es muy sencillo. En ese caso podemos partir de una imagen con un objeto por cada término municipal, y mediante un editor de SVG (Por ejemplo, Inkscape) editar las propiedades del objeto y establecer como ID el código postal del municipio. De ese modo, podremos acceder mediante DOM al objeto que representa cada término municipal para posteriormente establecer el color de fondo dependiendo de su densidad (Expresiones regulares al rescate).
Mapa de España por provincias generado utilizando PHP y SVG

Y es que a veces nos complicamos mucho la vida, como por ejemplo dibujando a pelo polígonos sobre la API de Google Maps, cuando incluso podemos empotrar directamente imágenes SVG en un mapa de Google.

A día de hoy, la mayoría de los navegadores permiten visualizar directamente imágenes vectoriales SVG dentro de un documento XHTML, pero como a menudo sucede, Internet Explorer no renderiza de forma nativa SVG. ¿Qué podemos hacer en esos casos? Muy sencillo. Convertir dinámicamente a un mapa de bits. En el caso de PHP no he encontrado ninguna biblioteca o clase que permita la conversión de forma eficaz, sin embargo existen utilidades en la línea de comandos a las que podemos llamar para que realicen conviertan al formato deseado (Como el propio Inkscape o la utilidad convert de ImageMagick).