Turns out that as web designers, we design interfaces. You can think of them as part of a complex set of interactions: between your site and your user. Most people will agree in naming interfaces and interactions components of a science called User Experience Design.

An interaction, on the web, is done within a set of interfaces. An interface is designed in function of the experience you want to achieve (”recommend a person in Linkedin” or “add a photo in Facebook”). We design interfaces per page, and it’s a misunderstanding to think a general template (for example, a 3 column page layout) will fit all cases successfully.

So, when designing in the browser, it is tremendously difficult to actually experiment with page layouts, copy placement (copy is interface) and imagery. It seems that we are eager to see how text renders in Safari, how a text-shadow adds (crappy) dimension to a typeface, and such. We tend to think in decoration, and not in interfaces.

Take a look at Badoo.com, for example (a site with one of the greatest interfaces for the web ever made). Badoo has different page layouts for different experiences: the experience of “signing up”, the experience of “browsing for friends”, and such. I’m sure they designed these interfaces in a sketchbook (or software, like Fireworks), previously to code them. Why? Because it’s faster to try and catch up on errors than just starting in the browser with a fixed, 3 column layout that should fit all cases.

What happens when you discover that the labels in your forms work better top aligned than left aligned? You proceed to modify your CSS in order to make it work. And then cames user research, showing you that left aligned labels in fact were working better for your users. You need to touch and modify your CSS (and probably HTML) again. Nuts. In Fireworks this is an easy task, and it’s even easier to present different options to potential users to choose in the first place. Flexibility is the concept, not getting married with your own design is the key.

To my eyes, all the recent efforts in showcasing the benefits of designing in the browser are only efforts on showcasing how decoration can be tackled in the browser. While pushing CSS to the next level is great (I have mixed feelings on progressive enhancement, though), I don’t think starting a site design right in your browser of choice will cut off design time, neither costs.

Don’t get me wrong, I’m all for the browser. In fact, my workflow is kind of akward: I start in Fireworks, when I get a workable mock (pretty much a basic type structure), I proceed to code some bits of it. Later, I find myself taking screenshots of Safari’s rendered text to paste in Fireworks, and start again. But this work well with simple sites, and not with critic, complex, user oriented sites. For the later, rapid prototyping tools are fundamental.

Because no CSS beats the speed of pointing with your mouse, selecting 3 layers and changing the look of a mockup in a breeze.

We design interfaces. Decoration is only superfluous.

The idea of the contest was to experiment mainly with type composition in a site layout. Being the type-freak that I am, I was very excited to get a new version of Modern Clix, my free WordPress theme, finished in order to apply.

This new version has improved typography and a new grid of 1080px wide, amongst other features. The new width is mainly an experiment on going beyond 960px, following the recent dicussions of designers such as Cameron Moll. I’m not too sold on 1080 though (neither on 960), but that’s a topic for another blog post.

So I qualified in the 3rd place amongst designers of all over the world. Big surprise, especially considering the high quality of work sent (I especially love the vintage magazine feel of the 1st. place, T-20, designed by Nikolaj Sokolowski).

Thanks to Smashing Magazine for picking up Modern Clix—err, Experimental, and of course, this new version is going to be released as a free WordPress theme very soon, so stay tunned.

This post is written in Spanish: It covers the redesign of the HTML and CSS code for Taringa.net, a site with over 13 million page views daily. In this article, I explain how to save thousands of dollars a day by using simple web standards techniques to reduce the size of the homepage by 50%. A version of this article will be published in English in the coming days.

Luego de leer este artículo en Alt Tab, en donde se entrevista a Alberto Nakayama sobre el funcionamiento de Taringa.net, quedé bastante impresionado con la red de servidores y recursos que el sitio consume actualmente. Para un sitio como Taringa, con más de 13 millones de páginas vistas por mes, mantenerse optimizado es crucial, en el sentido en que esto implica una reducción en el ancho de banda que se consume, y por ende, en los gastos mensuales en servidores y su mantenimiento.

La gran pregunta es, ¿pueden los estándares web ayudar a minimizar los costos de funcionamiento de Taringa? En este post explico como optimizé la página principal, utilizando técnicas simples de estándares web, logrando reducir su tamaño en aproximadamente un 50%, de esta manera, ahorrando miles de dólares mensuales en servidores y su mantenimiento.

El problema

Una rápida inspección al código HTML de la página principal muestra que el sitio no parece tan optimizado como uno quisiera. Algunos puntos que pude identificar:

• H1, el elemento más importante de una página no está siendo usado. Este elemento se encarga de describir el título de la página, además de proveer valiosos keywords a los buscadores. Tampoco hay una jerarquía de cabeceras (H1, H2, H3) coherente.
• Semántica pobre. No se usan los elementos de HTML para describir el contenido correspondiente. Una lista de ítems, que lógicamente se marcaría con el elemento UL, en Taringa se reemplaza por una serie de DIVs. DIV se usa para describir una sección de una página —como una cabecera, por ejemplo, o un conjunto de elementos. UL, en cambio, se usa para describir una lista no ordenada de elementos, en el caso de Taringa, podríamos usar UL para describir los últimos posts enviados.
• Poca optimización para buscadores (SEO). Esto es claramente una consecuencia del punto anterior. Los buscadores aman el contenido, pero también un contenido bien marcado y elementos de HTML bien usados. Mientras más limpio sea el código de una página, mayor indexabilidad tendrá.

En promedio, la página principal de Taringa pesa 50KB. El sitio sirve más de 13 millones de páginas vistas por día, en un cálculo rápido, más de 600GB son transferidos por día (50KB x 13M = 620GB). Haciendo un cálculo rústico de 1GB = 1 dólar, nos revela que Taringa gastaría 600 dólares por día solamente en servir HTML.

Es bueno aclarar que en este artículo no voy a rediseñar la parte visual de Taringa. Hace un tiempo trabajé en Trade2Win.com, un sitio con alrededor de 2 millones de impresiones al mes, y aprendí que en sitios similares con mucho tráfico, las decisiones visuales deben hacerse con muchísimo cuidado porque repercuten directamente en los hábitos de uso de millones de usuarios.

Un retoque pequeño, y al parecer inofensivo, como cambiar el ícono de búsqueda por otro que al parecer funcionaría mejor, puede traer consecuencias desastrosas. Por lo tanto, solo me voy a enfocar en rediseñar el código HTML y CSS de la página principal del sitio, tratando de ser fiel al estilo visual del sitio lo más posible.

Optimización para buscadores

Una de las ventajas de diseñar con estándares viene de regalo: la optimización del sitio en buscadores. Los estándares (en este artículo hablamos solamente de HTML, CSS y JS) fomentan la semántica, y los buscadores en general valoran a las páginas semánticas sobre aquellas que no lo son.

La semántica, en pocas palabras, trata sobre el uso de un elemento determinado de HTML para describir el contenido para el que fue creado: por ejemplo, es lógico que el título de una página se marque con el elemento H1, ya que es el elemento más importante, pero en Taringa se lo reemplaza por una combinación de DIVs y As. Google, en todo caso, no podría encontrar el título de la página ya que no hay un H1 disponible, penalizando su posición en los resultados.

Ahora bien, el listado de últimos posts en la página principal es tal vez lo más interesante del sitio. Cada ítem se describe con un título y uno o dos íconos para una mejor identificación visual de la categoría. Éste es el código que se usa actualmente en Taringa para mostrar los últimos posts:

<div class="link">
<div class="link_titulo">
<span class="categoria arte" alt="Arte" title="Arte"></span>
<a href="" target="_self" title="Firmas A Pedido" alt="
Firmas A Pedido" class="box_link">Firmas A Pedido</a>
</div>
</div>

Claramente, es demasiado. Se usa un serie de SPANs para cada ícono, todo agrupado en un conjunto de DIVs, resultando en código no optimizado. Una propuesta, utilizando estándares web y marcado semántico, podría ser de la siguiente manera:

<li class="icon-art" title="arte">
<a href="">Firmas A Pedido</a>
</li>

Como vemos, cada ítem es marcado con su elemento correspondiente, LI. Luego, el atributo class se encargará de mostrar los íconos correspondientes para cada ítem, salvando preciosos bits y eliminando DIVs sin función.

Este enfoque semántico, del ejemplo, se extiende a toda la página, desde la lista de posts nuevos, hasta los posts más votados e incluso los avisos de Taringa.

De ahora en más, Google no interpretará la página principal de Taringa como una serie de contenido tirado sin descripción, ya que cada elemento ahora describe perfectamente su contenido, proveyendo mejor información para su clasificación e indexación.

Reduciendo la cantidad de pedidos al servidor

Alberto inteligentemente implementa CSS Sprites para mostrar los íconos en cada post. La idea es utilizar un archivo GIF con todos los íconos, en vez de 50 o más archivos separados, de esta manera reduciendo la cantidad de pedidos al servidor y disminuyendo la carga.

En este ejemplo, fuí un poco más allá y extendí el concepto para todas las imágenes del sitio, incluyendo los logos de Taringa/Google en la caja del buscador y los logos del pie de página. Los íconos de los sponsors también fueron optimizados.

Una propuesta de organización de íconos para Taringa

En total, contando íconos, logos y otras imágenes, Taringa usa 14 archivos GIF. Esta optimización de imágenes me permitió reducirlos a solamente 2. En números fríos, una reducción de más del 85% en pedidos al servidor.

Flexibilidad a prueba de balas

Una mención aparte se merecen las imágenes con bordes redondeados, por ejemplo, el marco contenedor de la página, y muy especialmente, las secciones o módulos de Taringa. Es demasiado frustante para un diseñador no tener otra alternativa que aplicar artilugios varios para poder mostrar un simple borde redondeado.

CSS es un lenguaje con muchas fallas, pero en mi opinión, esta es la más grave. Sin embargo, siempre se puede optimizar y simplificar.

A modo de ejemplo, para mostrar el marco contenedor del sitio, en azul, Taringa usa 2 imágenes diferentes (rtopbg.gif y maincontainerbg.gif), además de código no semántico en el HTML para mostrarlas. Aunque este enfoque es totalmente válido, todavía se puede utilizar una sola imágen, y eliminar los DIVs extra en el HTML para una mejor interpretación del documento. Con un poco de CSS luego nos encargaremos de mostrar los bordes de la imágen, ya sea superiores o inferiores, reduciendo los pedidos al servidor en un 50%.

Otros criterios de optimización se aplicaron para otras partes de la página. La clave, siempre, es simplificar.

Las secciones, o módulos de Taringa, requiren una explicación aparte. En el sitio actual, se usan 4 imágenes para mostrar los bordes redondeados: 2 para cada esquina, uno para el fondo del título del módulo, y una imágen para los bordes inferiores (que tiene bordes inferiores para los diferentes anchos de las cajas). Además, claro, de código HTML extra para mostrarlas.

En el ejemplo, aplique lo que se conoce como Progressive Enhacement para reducir el uso de imágenes para módulos de 4 a 1. De hecho, simplificando más aún, podríamos incluso no necesitar imágenes.

La idea básicamente es proveer una mejor versión del sitio para aquellos navegadores avanzados. En este caso, los bordes redondeados para los módulos utilizan una propiedad específica de Safari y Firefox (-webkit-border-radius y -moz-border-radius, respectivamente); sin embargo, los usuarios que naveguen con Internet Explorer igualmente podrán disfrutar del contenido y la funcionalidad del sitio.

La página principal de Taringa con zoom x4.

Especial atención se puso para que la página y su contenido luzca mínimamente bien (sobre todo legible) al aumentar el tamaño de texto, como pueden ver en la captura siguiente:

El ejemplo de este artículo con zoom x4.

El rediseño de Taringa es ahora indestructible y soporta cambios en el tamaño de texto para aquellos usuarios que lo necesiten, aumentando su accesibilidad.

Si en el futuro se necesita agregar más opciones en la barra de navegación, llegando a las dos lineas de texto, podemos ver que la caja contenedora no se romperá, aguantando cambios en el texto.

Conclusiones

Este es un ejemplo rápido sobre como se podría optimizar el HTML y CSS de Taringa para minimizar los costos en servidores. Como extra, se recodificó la página para una mejor semántica y optimización en buscadores. El resultado es una optimización de 50KB a 26KB en el tamaño del archivo HTML, es decir una reducción del 50%.

Por cuestiones de tiempo, el ejemplo solamente está probado y funcionando en Safari y Firefox. Pero a los fines prácticos, una implementación para las diferentes versiones de Internet Explorer no agregaría demasiados bytes al resultado final.

En números:

Los valores son estimativos.

Este enfoque de optimización se puede aplicar a sitios con mucha demanda de servidor. Por ejemplo, Meneame, Fayerwayer, Clarín y La Nación y demás.

Pueden ver el ejemplo funcionando aquí.