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 )

<style type='text/css'>
    #{$selector} {
    	margin: auto;
    }
    #{$selector} .gallery-item {
    	float: {$float};
    	margin-top: 10px;
    	text-align: center;
    	width: {$itemwidth}%;
    }
    #{$selector} img {
    	border: 2px solid #cfcfcf;
    }
    #{$selector} .gallery-caption {
    	margin-left: 0;
    }
</style>

Este fragmento de código se encuentra en:
wp-includes/media.php (Line 833)

El problema es que se incrusta estilo en pleno documento, donde se ha insertado la galería. Lo cual no resulta muy limpio si atendemos a la abstracción de las 3 capas: diseño, función y contenido.

Si volvemos a media.php veremos entorno a la línea 831:

if ( apply_filters( 'use_default_gallery_style', true ) )

Por tanto una opción elegante podría ser:

add_filter('use_default_gallery_style', FALSE);

Colocando este filtro en el fichero functions.php del theme usado, indicamos a WordPress que no debe usar por el estilo CSS por defecto para las galerías, y relegamos el CSS necesario al fichero style.css donde tengamos centralizado todo el estilo del blog.

Usando filtros se puede cambiar altamente el comportamiento por defecto de WordPress.

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.

En su Manifiesto podemos leer:

Pensamos que el fenómeno de la digitalización de la sociedad, las industrias y el mundo no solo es inevitable sino que además es POSITIVO, DIVERTIDO, APASIONANTE y LLENO DE OPORTUNIDADES. Nuestra actitud ante esta nueva era debe de ser de CURIOSIDAD, EXPERIMENTACIÓN y de DISFRUTE.

No podría expresarlo de mejor forma, la idea es sentirnos optimistas ante la era digital en la que ya estamos inmersos

Los artículos que se van publicando son acertadísimos, y para comenzar ya han posteado gente de Google, Yahoo, Banco Popular, INGDirect, FXInteractive, BuyVip, etc.
Me encanta lo que estoy leyendo, os dejo únicamente 3 joyitas:

• “¿Facebook? Es una tontería, yo no tengo tiempo”
• Internet y el cambio de modelo productivo
• En internet, si eres capaz de imaginarlo: es posible.

Pues bien, por aquí creemos que la ilusión es capaz de mover el mundo. Así que para esta Navidad vamos a ponerla en marcha entre todos, porque pensamos que la ilusión no se crea ni se destruye, se intercambia.

Y es por eso que nace en España el Almacén de la Ilusión. Partiendo de una gran iniciativa de Coca-Cola y tomando como base truequi, junto con el trabajo de grandísimos profesionales como Paco, Pilar, Carmen, Marie-la, Sertxu (equipo digital de Coca-Cola), la gente de Genetsis (infraestructura, servidores), Correos, Chonoexpress…, y luego estaba Marcos y la gente de Q-Interactiva, Israel y yo mismo que hemos dado forma y vida al sitio web. Un montón de gente persiguiendo un mismo objetivo, y la verdad es que nos hemos entendido muy bien desde el primer momento. Al final ya parecía aquello una gran familia

¡¡En el Almacén hay sitio para todo!! Puedes aportar tus ilusiones, aquellos artículos que han formado parte de tu vida y pienses que ahora pueden hacer feliz a otra persona. A cambio de subir tus ilusiones podrás escoger otras de personas que como tú quieran compartir las suyas.
Actualmente ya hay libros, películas, música, videojuegos, y otros objetos curiosos.

Y la cosa no acaba aquí, gracias a un acuerdo alcanzado entre Coca-Cola y Correos España, los 40.000 primeros envíos serán gratuitos. Vamos, que debido al amplio margen financiado todos podremos enviar y recibir nuestros regalos sin coste alguno.

Con todo esto se aprovecha la sinergia entre dos grandes empresas, como Coca-Cola y Correos, con gran capacidad para generar ilusión y hacer realidad el envío de paquetes en unas fechas marcadas por el gran incremento de actividad postal.

Para seros sinceros… no recuerdo una iniciativa tan bonita y valiente como esta en los 12 años que he vivido Internet. Pienso que toda España puede sentirse orgullosa de participar en ello

Así que toca olvidar por un momento la crisis, en el Almacén de la Ilusión el dinero no tiene cabida, solamente la ilusión de artículos que puedas ofrecer y recibir

Bienvenidos al Almacén de la Ilusión.

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.

Registro

• Resulta pesado rellenar varios campos para una mera suscripción a newsletter. Es suficiente con tener el e-mail y nombre del usuario.
• Para evitar e-mails falsos u otros problemas de seguridad, el registro al newsletter podría ser a partir de una confirmación de correo enviado al buzón del usuario.
• El borrar la suscripción debería ser algo fácil, un clic y bien visible en el propio newsletter enviado. De lo contrario puede que el usuario (por no buscar) acabe marcando el newsletter como spam, perjudicando a la dirección de envió.

Spam

• Evitar los filtros spam no incluyendo palabras como: gratis, free, descuento, etc. Algo que puede ser difícil teniendo en cuenta el sitio web y el target al que vaya dirigido.
• Encabezar o situar en posiciones superior la fecha del newsletter. Esto podría evitar el ser confundido con Spam.
• Chequear los enlaces enviados en el contenido del newsletter. No pueden existir enlaces que lleven a un “not found” y menos aún enlaces que puedan llevar a sitios web penalizados por los buscadores.
• El envió de e-mails debe ser distribuido en periodos, no debe hacerse nunca de forma masiva y simultanea.
• Si se compran o se venden listas de e-mails lo más probable es que se acabe cayendo en una lista negra, con su consiguiente penalización como Spammer. Es complejo y lento salir de listas negras.
• Si varios e-mails chequean como spam al newsletter se puede caer en el riesgo de que un proveedor identifique la IP como Spammer.
• Una forma de asegurarnos que el newsletter sea leído en inbox y no pase directamente a spam, es hacer que la dirección de envió figure en listas blancas (desconozco como llegar a ello).
• Quitar URGENTEMENTE aquellos suscriptores que están eliminando, no abren, o marcan como spam el newsletter. Lo están perjudicando en cada acción.

Comunicación

• Estar en contacto con los lectores. Tras el registro al newsletter no pueden pasar los primeros 10 días sin ninguna noticia.
• Dar algún enlace hacia una web/email para contactar con el soporte.
• Se puede enviar el newsletter desde una dirección a la que el usuario pueda responder y así obtener con ello feedback directo del lector. Incluso invitarles a realizar ese feedback.
• Usar un lenguaje que tenga que ver con el target (edad, sexo, estudios, etc). Por ejemplo puede ser un lenguaje llano, natural o espontaneo que resulte muy cercano e invite a leer y participar.
• Los lectores parecen se más receptivos los Martes y Miércoles de 2 a 3 PM. Según he leído las razones pueden deberse a que los usuarios en el Lunes tienen la bandeja algo saturada del fin de semana, y los Jueves/Viernes ya vuelven a preocuparse más del fin de semana que del correo pendiente.
• Personalizar los e-mails para resultar más cercano y menos automatizado. Esto puede realizarse con variables para el saludo y despedida:
  • Hola [username]
  • Saludos [username] del equipo [nombre-proyecto]

  Incluso se podría personalizar en función de la hora del envió:

  • Buenos días [username]
  • Buenas tardes [username]
  • Buenas noches [username]

Contenido

• Poner un link para ver la versión web del email enviado (una alternativa).
• Pensar en títulos adecuados para cada newsletter.
  Ejemplo: Compañía – Asunto [Ref.12]
  • Primero la compañía/empresa/marca que enviá el newsletter.
  • A continuación el asunto/titulo del newsletter.
  • Finalmente podemos incluir el número (referencia) del newsletter.

  *nota: el asunto debe tener menos de 50 caracteres por razones de compatibilidad con el mayor número de gestores posible.

• Indicar al usuario que ha recibido el email debido a que esta suscrito en [nombre-proyecto] (enlace a la web).
• Los newsletter deben ir relacionados con la temática que se espera. El contenido debe ser de gran valor para no perder suscriptores.
• Dar muy buenas razones para permanecer suscrito al newsletter. Esto puede hacerse con descuentos, promociones, noticias, secretos, en definitiva cosas que no puedan obtener por otros medios.
• Incluir un enlace a la política de privacidad.
• Incluir datos para saber que detrás hay una empresa real. Por ejemplo la dirección, el teléfono, etc.
• Invitar al usuario a seguir leyendo contenidos con enlaces hacia la página web.

Diseño

Merece un post aparte debido a las peculiaridades: Código para el diseño de e-mails y newsletters.

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”!