La pregunta básica es: ¿Diseñamos una Web única, o realizamos dos versiones (una de escritorio y otra móvil)?

Y es aquí donde tengo pensamientos encontrados:

Si me dejo llevar por los estándares web

• Mejor adaptación al dispositivo final. Sea el dispositivo que sea: navegadores convencionales y especiales, lectores de pantalla, lectores braille, dispositivos móviles.
• Mejor adaptación al usuario, siendo él quien ajuste la presentación del sitio web a sus necesidades y en base a las opciones de su navegador.
• Abstracción más clara del estilo, estructura y comportamiento.
• Escalabilidad y mantenimiento. Pienso que sería más rápido y sencillo escalar posiciones que hacerlo manteniendo diferentes versiones del sitio Web.

Si nos fijamos el artículo esta escrito por Bruce Lawson, un desarrollador que trabaja en Opera. Empresa que esta a la vanguardia de los estándares web, y desde un principio muy volcados en HTML5, lenguaje que posibilidad este único camino para todos. En el 2009 había escrito sobre una conferencia de Chaals (evangelista de Opera) sobre las bondades de los nuevos estándares web con HTML5. Unos meses después la W3C anuncia que se volcará sus esfuerzos en HTML5. Si seguimos este camino me parece que al menos se intenta perseguir un Web único y estándar.

Ahora bien:

Si me dejo llevar por la usabilidad

• Se diseñara en base a las expectativas del usuario, a sus objetivos.
• Se demanda inmediatez, que el usuario pueda hacer/leer lo que le interesa rápidamente. Para ello es necesario ofrecer una versión menos densa de contenidos.
• Menos contenido = más velocidad a la hora de descargarlo.
• Hay ciertos contenidos y servicios que en una versión móvil no son viables, entonces para que tenerlos? confunden al usuario!

La experiencia de usuario y satisfacer sus objetivos son lo primero. Y por esto es necesaria una versión móvil. Jakob Nielsen y otros gurus de usabilidad van por este camino.

Por otro lado hay mucha información, muchos recursos, mucho dinero invertido en estas versiones web móvil, hay conferencias, hay patrones de diseño orientado a ello, todo centrado en la Usabilidad. Es un movimiento muy grande en esta dirección y eso da que pensar.

Pero…, si nos centramos en la usabilidad, el diseño del sitio Web móvil debería tener en cuenta muchos parámetros que incluso dependen de los fabricantes. Entonces, ¿hay que diseñar para varios dispositivos móviles?, ¿para cuales de ellos?

• Diferente hardware
  • Varios tamaños de pantalla.
  • Paleta de colores, contrastes, imágenes.
  • Diferentes teclados: caracteres, disposiciones, teclas-significados
  • Conexiones, memorias, etc.
• Diferentes métodos de interacción: joystick, click whell, touchpad, touchscreen, reconocimiento de voz o el clásico teclado.
• Diferente Software: Nos podemos encontrar múltiples sistemas operativos: Symbian, Windows Mobile, Mac OS, Android.

¿Hay que mirar estadísticas de acceso de usuarios, discriminando a la minoría?, ¿Y la usabilidad de estos pocos? Los estándares Web aquí reñirían con la Usabilidad y mirarían hacia la Accesibilidad.

Solución intermedia, las prosperas Apps

Ayer vi de casualidad el programa “La nube” en TV2, sobre el floreciente negocio de las apps. Por cierto que bien que vuelvan programas así.
Al hilo de esto, he observado que muchos sitios web, orientados a servicios, tienen su Web única y una app especial que sustituye esa otra web en versión móvil.
Bueno esto puede ser una solución intermedia a tener en cuenta. Puesto que la App esta diseñada, y destinada a satisfacer unos objetivos muy concretos, siendo dirigida a un target también muy concreto donde podemos centrarnos especialmente en la Usabilidad.

Conclusión

Llegados aquí, creo que ya se me ve el plumero. Yo abogaría por una Web única. Sobre el diseño sensible, todavía no me encuentro con conocimiento suficiente de ello, pero si se realmente se consigue que un único sitio Web se adapte a los distintos dispositivos, cambiando el tamaño de elementos, su posición, eliminandolos y haciendo una versión reducida mas sencilla. Entonces, “yo” iría en ese camino.

*Nota: Casa de herrero, cuchillo de palo. Espero zambullirne en este tema cuando tenga tiempo para afrontar el tan deseado rediseño de este sitio web (que se remonta al 2007 )

Código jQuery

jQuery(document).ready(function($) { 	
 
	//open external links in new window
	$('a:not([href^="http://aurea.es"]):not([href^="#"]):not([href^="/"])').addClass('external');
	$('a[class="external"]').click(function(){ $(this).attr('target','_blank'); });
 
});

Explicación

1. Comenzamos el mítico método ready de jQuery, encargado de comprobar si el DOM esta cargado y preparado para usarse. Tengamos en cuenta que deben estar todos los tags de enlaces ya descargados en el navegador para luego lanzar las operaciones sobre ellos.
2. A continuación hacemos 3 comprobaciones basadas en el atributo “href”. Que el link no comience con el “dominio del sitio web” (link absoluto), que no comience por “#” (link ancla), y que no comience por “/” (link relativo). A todos los enlaces que cumplen esto se les añade la clase “external”, ejemplo: class="external".
3. Una vez tenemos identificados todos los enlaces externos, ya solo queda preparar un evento .click() que añada el atributo target con valor blank (nueva ventana/tab) cuando el evento se dispare.

Antes de seguir, es bueno recordar la historia de los elementos IMG, EMBED y OBJECT.

OBJECT como sustituto de IFRAME

Con IFRAME podemos embeber un tipo de documento HTML. Pero si atendemos a la definición de OBJECT veremos que podemos embeber varios tipos de documento como: HTML, SWF, VIDEO, IMAGEN (ver ejemplos).
Teniendo en cuenta lo anterior, IFRAME puede verse como un TAG redundante.

Por otro lado en la versión XHTML Strict, el DTD no admite el tag IFRAME. Al fin y al cabo forma parte del pasado y la W3C siempre ha recomendado el uso de un OBJECT para incrustar los diferentes documentos, tanto si es vídeo, como imagen, como una página html.

Además hay que tener cuidado con IFRAME en Firefox, generado de forma dinámica podemos tener problemas (Bug 279048).

IE como de costumbre va contracorriente

Si usamos OBJECT en Internet Explorer, debemos tener en cuenta que no reconoce el atributo type:

<object type="text/html" ...

En su lugar tenemos que indicar un atributo classid:

<object classid="clsid:F08DF954-8592-11D1-B16A-00C0F0283628" ...

De todas formas con varias pruebas que hice he comprobado que el comportamiento es irregular en las diferentes versiones de la familia Internet Explorer (6, 7, 8, 9).
En cambio con IFRAME, Internet Explorer se maneja de maravilla todas las versiones interpretan y dan el mismo resultado.

IFRAME para IE, OBJECT para el resto

Al final pienso que la mejor opción cross-browser es mantener el IFRAME para la familia Internet Explorer y recuperar el OBJECT para el resto de navegadores (Firefox, Opera, Safari, Chrome).

Para hacer la bifurcación he recurrido a los comentarios condicionales de IE:

<!--[if IE]>
    <iframe src="page.htm">contenido alternativo</iframe>
<![endif]-->
<!--[if !IE]> <-->
    <object type="text/html" data="page.htm">contenido alternativo</object>
<!--> <![endif]-->

Conclusión, voy abrazando OBJECT mientras digo adiós al IFRAME a excepción de IE

Para ello, (1) pondremos un CSS base que sea compatible para todos los navegadores y a continuación (2) haremos uso del array $_SERVER y del campo donde se cargan las cabeceras con información del navegador del usuario “HTTP_USER_AGENT”.

1. Código CSS base:

<link rel="stylesheet" href="base.css" type="text/css" />

2. Código PHP:

$browser = $_SERVER['HTTP_USER_AGENT'];	
if (preg_match('/MSIE.8/i', $browser)) { echo '<link rel="stylesheet" href="msie8.css" type="text/css" />'; } 
elseif (preg_match('/MSIE.7/i', $browser)) { echo '<link rel="stylesheet" href="msie7.css" type="text/css" />'; }
elseif (preg_match('/MSIE.6/i', $browser)) { echo '<link rel="stylesheet" href="msie6.css" type="text/css" />'; }
elseif (preg_match('/MSIE.9/i', $browser)) { echo '<link rel="stylesheet" href="msie9.css" type="text/css" />'; }
elseif (preg_match('/Firefox.2/i', $browser)) { echo '<link rel="stylesheet" href="firefox2.css" type="text/css" />'; }
elseif (preg_match('/Firefox.3.5/i', $browser)) { echo '<link rel="stylesheet" href="firefox35.css" type="text/css" />'; }
elseif (preg_match('/Firefox.3/i', $browser)) { echo '<link rel="stylesheet" href="firefox3.css" type="text/css" />'; }
elseif (preg_match('/Chrome/i', $browser)) { echo '<link rel="stylesheet" href="chrome.css" type="text/css" />'; }
elseif (preg_match('/Safari/i', $browser)) { echo '<link rel="stylesheet" href="safari.css" type="text/css" />'; }
elseif (preg_match('/Opera/i', $browser)) { echo '<link rel="stylesheet" href="opera.css" type="text/css" />'; }
else { echo '<link rel="stylesheet" href="unknown.css" type="text/css" />'; }

El código escribirá el link con la hoja de estilo correspondiente al navegador empleado por el usuario basándose en la comparación de cadenas.

Si lo que queremos es únicamente discernir la versión de MSIE, podemos también recurrir a los comentarios condicionales de Internet Explorer.

Para hacer las pruebas necesarias con los diferentes navegadores, podemos descargarlos o emularlos.

La misión de esta etiqueta es pre-formatear su contenido, con lo cual mantiene en el texto los espacios en blanco, saltos de línea, etc. Y es justamente por esa razón por la que debemos tener mucho cuidado (no soy muy amigo de emplearla).

En Gmail, por ejemplo se producía un desbordamiento horizontal, donde salia el scroll y el texto continuaba a lo largo y ancho de la ventana

Como solución, sustituir pre por un simple div en conjunción con una de estas dos opciones para el contenido que albergará:

• Formatear el contenido con PHP: Podemos ayudarnos de la función nl2br que insertará los saltos de línea.
  
  Ejemplo:

      nl2br('texto con formato');

• Formatear el contenido con CSS: Podemos usar la regla white-space: pre; para simular el comportamiento de la etiqueta pre.
  
  Ejemplo:

      <div style="white-space: pre;">
          texto con formato
      </div>

5 errores típicos

• Un 42% de páginas no comprimen su contenido con GZIP.
• Un 44% de páginas enlazan a más de 2 ficheros CSS.
• Un 56% no sirven el CSS con cookies (o no la entiendo, o esta la veo complicada de evitar sin CDN).
• Un 63% no minimiza sus ficheros con herramientas como YUI Compressor.
• Un 21% de páginas tienen ficheros CSS con más de 100K de peso (esta es de escándalo).

Si en nuestros CSS sumamos: demasiada atomicidad, normas, duplicación, conflictos y lo aderezamos todo con algo de impredecibilidad, tendremos por resultado un enorme e incontrolable CSS.

5 buenas maneras

Lo que debemos evitar es:

1. La Atomicidad

Imaginemos una página Web como si fuera un coche. Para crear ese coche usamos piezas de lego, una a una las vamos posicionando hasta crear la figura del coche.

• Con CSS básicamente hacemos lo mismo, podemos ir pieza a pieza posicionando y creando el sitio web. Y es justamente el planteamiento que debemos cambiar.
• La idea es evitar pensar en pequeñas piezas (átomos) y pensar en objetos que se puedan reutilizar. De esta manera podemos por ejemplo crear con CSS una rueda del coche, que a su vez bastaría para simular las otras tres restantes.
• Esto se podría considerar una evolución de la forma de pensar en el CSS.

2. Normas desfasadas

Que van acumulandose, que no se reutilizan, que son incrementales en el tiempo, muy especificas, etc.

3. Normas imprevisibles

Que no pueden ser reutilizadas y que son totalmente dependientes de su ubicación.

4. Guerras de especificidad

Nodos hijos de hijos de otros hijos, hacks, estilos con #ID que no pueden ser reutilizados, la sentencia !important no tiene cabida (si se usa bien la cascada), etc.

5. Duplicidad

Definir en numerosas ocasiones reglas como: margin, float, font-size, etc. Como solución tenemos:

• Algunas técnicas para resetear el CSS.
• Pensar en global, en todo el sitio web. Para ello ayuda mucho seguir una metodología como la DCU, para abstraer el futuro marcado de los mockups y ejecutar nuestro “CSS kung-fu”!

• A través del filtro Directx AlphaImageLoader.
• Con Behaviors.
• El conocido pngfix (con la ayuda de JavaScript).
• Algunas implementaciones pngfix para frameworks de JavaScript, como jquery.pngFix.js

Todas ellas presentan pros y contras. Dependiendo del proyecto puede que venga mejor uno u otro, o que simplemente alguno no funcione por conflictos de JavaScript o misteriosas razones que solo las meigas de IE conocen. Así que la única solución es probar y probar…

A continuación voy a desarrollar la primera de ellas.

AlphaImageLoader

#logo  { 
	background-image: none;
	filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(
		src='http://..../logo.png', 
		sizingMethod='crop'
	); 
}

El primero de los pasos es indicar que no hay ningún fondo background-image: none;, a continuación usamos filter y la llamada Directx de Microsoft para cargar imágenes que incorporan factor alfa. En el parámetro src va la ruta absoluta al fichero png.

Conflicto con los enlaces

Con lo dicho anteriormente el PNG es mostrado con transparencia y sin errores, pero los enlaces no realizan el comportamiento adecuado si se encuentran en el interior de un elemento que tenga aplicado el filtro AlphaImageLoader.

Para solucionar este último problema podemos recurrir al siguiente código CSS:

#logo a { 
	position: relative; 
	z-index: 1; 
}

Cuando se aplica un filtro el elemento tiene una posición estática y esto presenta problemas en los enlaces, por ello se fuerza por medio de CSS a que los enlaces dispongan de una posición relativa y con z-index en una capa inferior.

Solo para Internet Explorer

Otros navegadores modernos (Firefox, Opera, Safari, Chrome) soportan perfectamente el formato PNG y su grado de transparencia, por tanto sería bueno pensar en ofrecer esta técnica únicamente cuando el usuario se encuentra navegando con Internet Explorer. Para lograrlo podemos recurrir a los comentarios condicionales:

<!--[if lt IE 7]><link rel="stylesheet" href="ie6.css" mce_href="ie6.css" type="text/css" media="screen" /><![endif]-->

Mediante este comentario condicional ubicado en el head podemos indicar que solo aquellos navegadores que sean inferiores al Internet Explorer 7 [if lt IE 7] se enlace el fichero de esitlo “ie6.css” que a su vez contiene los códigos comentados para esta técnica.

De esta forma:

• No obligamos a que se interprete código propietario (no estándar) como el filtro AlphaImageLoader por parte de otro navegador que no sea IE6 o inferior.
• El sitio Web será estándar y válido según el W3C – Validator.
• Reducimos el código CSS innecesario para otros navegadores y con ello logramos una mejor optimización.

Ejemplo de abreviatura – abbr

<p><abbr title="Teléfono">Tel</abbr></p>

Ejemplo de acrónimo – acronym

<p><acronym title="Real Academia Española">RAE</acronym></p>

Abreviaturas o acrónimos en otro idioma

Si el idioma de la abreviatura o el acrónimo es diferente al del documento, se debería indicar con los atributos lang y/o xml:lang.

Por ejemplo en el caso del documento siguiente en XHTML Strict en Inglés:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr" lang="en" xml:lang="en" >

El marcado de la abreviatura sería:

<p><acronym title="Real Academia Española" lang="es" xml:lang="es">RAE</acronym></p>

Y ahora viene lo bueno…

Según la nueva escuela todo es abreviatura

• Se llama acrónimo a la palabra que se forma a partir de las letras iniciales de un nombre compuesto y a veces por más letras. Por ejemplo: RADAR (RAdio-Detection And Ranging).
• Se llama sigla al término que se forma a partir de la inicial de las palabras claves que forman el título o el nombre completo de algo. Por ejemplo: RAE (Real Academia Española).

Ambos casos (acrónimos y siglas) son considerados abreviaturas y por ello en la práctica se permite usar abbr para todo tipo de formas abreviadas.

Además, en las especificaciones HTML5 y XHTML2 queda eliminado el elemento acronym a favor de estándarizar únicamente abbr.

Me parece bueno todo lo que sea ahorrar confusiones y malos usos, por eso me gusta la interpretación de la nueva escuela

* A tener en cuenta: Como no podía ser de otra forma las versiones anteriores a Internet Explorer 7 no reconocen abbr.

Este mecanismo fue “un invento” de Microsoft (Internet Explorer), que en númerosas ocasiones no han seguido los estándares y pautas marcadas por la W3C. Mediante los comentarios condicionales podremos crear estilos propios atendiendo a las diferentes versiones de este navegador.

Las condicionales llevan un operador: “!” (negación), “lt” (menor que), “lte” (menor o igual que), “gt” (mayor que), “gte” (mayor o igual que). Con los operadores y las diferentes versiones del navegador ya podemos definir estilos atendiendo a las diferencias de cada caso.

Ejemplos

<!--[if !IE]> Cualquier navegador pero NO (!) Internet Explorer <![endif]-->

<!--[if lt IE 6]> Solo versiones MENORES de la 6 <![endif]-->

<!--[if lte IE 6]> Solo versiones MENORES o IGUAL a la 6 <![endif]-->;

<!--[if gt IE 5.5]> Solo versiones MAYORES a la 5.5  <![endif]-->

<!--[if gte IE 5.5]> Solo versiones MAYORES o IGUAL a la 5.5  <![endif]-->

1. Selectores ID, Classes, Tags

#logo { margin-top: 1em; }
.ico { margin-left: 1em; }
a { text-decoration:none; }

Los Selectores ID es la forma más eficiente y rápida que hay en CSS para otorgar estilo. Por contra no podemos sobrecargar nuestro CSS usándolos para cada elemento que requiera un mínimo de diseño. En este punto tenemos que pensar de forma creativa y global para usar los selectores de clase, las propias etiquetas y los principios de la cascada.

2. Un identificador no necesita más

h1 #logo { margin: 1em; }

Las etiquetas con un atributo de identificador son irrepetibles, solamente hay uno por página, por tanto es redundante añadir cualquier referencia adicional.
El ejemplo anterior más optimo sería:

#logo { margin: 1em; }

3. Agrupar selectores con mismas propiedades

En vez de:

h2 { font-weight: 700; }
h3 {  font-weight: 700; }
.bold { font-weight: 700; }

Mejor usar:

h2, h3, .bold { font-weight: 700; }

Este es un ejemplo muy obvio pero puede ser más complejo dependiendo del tamaño de la hoja de estilos.

4. Escribir el CSS de formas abreviada

Las llamadas Shorthand es una forma de escribir las reglas de forma abreviada, lo cual repercute directamente en la optimización (siguiendo el principio menos es más).
Este asunto lo he tratado en un post anterior llamado “Formas abreviadas para optimizar CSS“.

5. Más restrictivo a la derecha

ul li span.linklist a { border: 1px solid red; }

Ante un ejemplo como este podemos pensar que el navegador interpreta de izquierda a derecha los selectores, cuando en realidad es justamente a la inversa. Primero analiza A, luego mira que se su padre sea SPAN.linklist, su abuelo LI y su bisabuelo UL, si esto se cumple se pone la propiedad de estilo border: 1px solid red;.

El problema es que pueden existir muchas etiquetas de enlace en una página y la cantidad de proceso será mayor, por lo tanto tendríamos que poner el selector más restrictivo más a la derecha. Ante esto se me ocurren dos soluciones:

• Disminuir las descendencias, por ejemplo: span.linklist a
• Otorgar una clase a.linklist y prescindir del resto

6. Menos descendencia y más herencia

Es aconsejable no recurrir a selectores con descendencias, hijos, hermanos, etc. Siempre que sea posible usar únicamente Selectores ID, clases y etiquetas.

En cambio si es positivo heredar (inherit) el mayor número de propiedades posibles entre diferentes elementos. Tengamos en cuenta también la herencia por defecto para no escribir reglas redundantes.

7. Poner el CSS en HEAD

El situar los estilos en el HEAD hace posible que la página muestre el contenido-estilo de forma progresiva, lo que mejora la experiencia de uso.

Por otro lado la especificación HTML también recomienda la etiqueta LINK dentro del HEAD para incorporar nuestras hojas de estilo.

8. CSS como fichero externo (style.css)

Esto hace que la cache pueda hacer su trabajo, de lo contrario si incorporamos el CSS en linea, será descargado una y otra vez con la página.

Otra ventaja es la mejora en la escalabilidad pudiendo gestionar todos los estilos y el diseño de una forma más centralizada.

9. LINK mejor que @import

En algunas versiones de IE usar @import es parecido a usar LINK fuera de HEAD, por esta razón y teniendo en cuanta lo dicho anteriormente, es recomendable usar un enlace al fichero y no importarlo.

Más información en Don’t use @import.

10. Minimizar el número de peticiones LINK

Supongamos el siguiente ejemplo:

<link rel="stylesheet" href="style1.css" type="text/css" media="screen" />
<link rel="stylesheet" href="style2.css" type="text/css" media="screen" />

En el fichero style2.css a penas hay unas pocas lineas de código y su gestión no lleva a confusiones, entonces es mejor tener un solo fichero style.css con todas las reflas CSS, reduciendo el número de peticiones LINK al servidor.

En este sentido tener en cuanta también la modularidad, pueden existir ficheros CSS que por esta razón es mejor mantenerlos bien separados y organizados.

11. Evitar las “CSS Expressions”

No son estándares y se procesan repetidas veces para establecer sus propiedades dinámicas.
En No me gustan las CSS Expressions planteo algunos problemas que derivan en la falta de optimización.

12. Evitar filtros

Siempre que sea posible evitar el uso de filtros como por ejemplo “AlphaImageLoader“, estos filtros consumen una gran cantidad de memoria para su funcionamiento.

Herramientas para la optimización y compresión

Existen muchas, pero las que más uso son:

• CleanCSS – Limpiar y optimizar nuestras hojas de estilo
• Firebug + PageSpeed + YSlow
• YUI Compressor

Las dos primeras te ayudarán a chequear y encontrar mejores formas de optimización, la tercera se encarga de comprimir el fichero CSS.

La experiencia hace que en cada proyecto tengamos menos trabajo que optimizar e invertir menos tiempo delante de estas herramientas.

Por cierto, ¿se os ocurren más formas para optimizar CSS?