Este es el segundo artículo en la serie que amplía los conceptos expuestos en la presentación Diseñar para móviles. En esta entrada repasaré el panorama actual de los smartphones en España y explicaré las decisiones previas que se han de tomar antes de comenzar a trabajar en un proyecto móvil.

Diseñar para móviles: regreso al pasado

Pantallas y resoluciones pequeñas, varios navegadores distintos con soporte de css y javascript precario, tiempos de descarga lentos y un nuevo medio en el que no terminan de encajar las soluciones que ya aplicabas en otros. Cada vez que comienzo un nuevo proyecto para dispositivos móviles me siento como si hubiera vuelto al 2000 (me consuela que al menos NO hay que maquetar con tablas).

El mayor dolor de cabeza lo provoca la diversidad de dispositivos y sus diferentes capacidades. Y es que, para sorpresa de muchos, diseñar para móviles no es diseñar exclusivamente para iPhone. En nuestro sector tenemos una visión sesgada de cuál es la verdadera penetración de los smartphones (especialmente el de la manzanita) en el grueso de la población. Según las últimas estadísticas de Nielsen para el primer trimestre de 2011 sólo 4 de cada 10 españoles tiene un teléfono inteligente y el sistema operativo predominante sigue siendo Symbian (es decir, Nokia) con un 65% de cuota de mercado.

Aunque es cierto que estos números cambian en cada campaña de Navidad e irá aumentando la proporción de smartphones (gracias a los terminales subvencionados por las operadoras) dudo que ningún s.o. vaya a imponerse sobre los demás a corto plazo. De manera que no podemos perder de vista a Android, a WP7, a Symbian o a Blackberry (que sorprendentemente triunfa entre los adolescentes además de en entornos corporativos) y quizás en algún momento llegue Samsung con Badá y HTC con su nuevo s.o. Todo diversión.

La conclusión es que los usuarios a los que queremos llegar poseen cientos de dispositivos diferentes, y la mala noticia es que es imposible realizar un único diseño que funcione en todos y cada uno de ellos. Por tanto nos veremos obligados a limitarnos a los terminales que sean más habituales entre nuestro público objetivo.

Decisiones previas

Ante la perspectiva de comenzar un nuevo proyecto para móviles (y con los tiempos “ajustados” que solemos manejar) el primer impulso es descargarte con entusiasmo una plantilla PSD de iPhone y empezar a diseñar pantallas como un loco. Sin embargo hay una serie de decisiones que afectan al diseño que se deben tomar antes de empezar, sobre todo si queréis ahorrar tiempo y disgustos a posteriori.

¿Para qué dispositivos?

Hemos visto que dentro del “ecosistema smartphone” existen cientos de móviles diferentes que varían en cuanto a tamaño, orientación y resoluciones de pantalla, soporte de css y javascript, detección de gestos y posición, botones de hardware, etc.  Sobre todo a la hora de realizar una página web en su versión móvil tenemos que asegurarnos que sea accesible para el mayor número de dispositivos.

Una buena solución es agrupar los terminales por familias para cubrir las 3 o 4 opciones más comunes, y realizar un diseño para cada una de ellas. Lo habitual es hacer la agrupación atendiendo a las características de interacción (táctil vs no táctil), resoluciones de pantalla y soporte de funcionalidades clave.

Un ejemplo de agrupación que hicimos para un proyecto web real fue:

• Táctiles con pantalla de alta resolución: cubre iPhone4, Samsung Galaxy, Samsung Omnia, Nokia N7, etc
• Resto de tactiles: iPhone3 e inferior, Androids de resolución media y baja, Blackberry Storm, Nokia 5800…
• Terminales con navegación por teclas/rueda/pad: Blackberry Curve, Nokia E7, Nokia N97…
• Terminales sin soporte javascript o con soporte limitado: Blackberry Pearl, Nokias antiguos y muchos más

Para este proyecto definimos un total de 34 pantallas, como cada una se diseñó en 4 variantes al final acabamos con 136 archivos PSD. Evidentemente primero se hizo una de las versiones y hasta que no estuvo completamente aceptada por el cliente no se comenzó con las demás. Podéis imaginar que hasta un simple “cambio de color” al final de un proyecto de este tipo puede resultar en cientos de horas de trabajo adicionales.

¿Aplicación o web?

Aplicamos diferentes patrones de diseño si se trata de una aplicación nativa o una página web. Por ejemplo en una web tendremos menos espacio de pantalla disponible pues hemos de reservar el que ocupan las barras del navegador, pero sin embargo no hará falta buscar un sitio para poner un botón de atrás/volver. Para los usuarios de iPhone es habitual encontrar en una app la navegación en el pie, pero en web la navegación a veces se pone en la cabecera, etc.

No podremos aplicar la misma carga gráfica de una aplicación a una web pues hay que tener mucho cuidado con el peso de las imágenes, aún quedan muchas zonas donde no llega la cobertura 3G y la conexión tira de GPRS (como muchos habréis descubierto estas vacaciones).

¿Gráfica propia o controles del S.O.?

Siempre que en una app se opte por una gráfica propia lo más probable es que tengas que realizar los recursos gráficos a 3 tamaños distintos (para resoluciones altas, medias y bajas). Además afecta a los tiempos y costes de programación.

Una solución chapucera que he visto más de una vez para ahorrar costes consiste en diseñar la aplicación para iPhone y luego replicarla pixel por pixel en Android. El resultado es un fracaso estrepitoso entre los dueños de un móvil Android que se sentirán incomodos ante un diseño visual y experiencia de usuario que les resultan totalmente ajenos.

¿Qué va a estar visible en la pantalla?

A la hora de decidir la cantidad de elementos que tengo que mostrar en la pantalla los factores que hay que tener en cuenta son:

• Presencia de botones de botones de hardware o teclado. Ej: botones de atrás/volver o de desplegar un menú que tienen los dispositivos con Android, Nokia y Blackberry.
• Interacción por rueda/pad o táctil. Ej: si el dispositivo es táctil no puedo mostrar opciones en “rollover”
• Reconocimiento de gestos del dispositivo. Ej: “drag” o “long press” para mostrar opciones ocultas.
• Patrones de interacción comunes. Ej: ¿debo poner un botón para actualizar datos o es conocido el gesto “pull to refresh”?
• Soporte de javascript. Ej: ¿tengo soporte suficiente para desplegar/plegar listas y capas?

¿Para qué resoluciones de pantalla?

Existen muchas resoluciones de pantalla diferentes, tanto en tamaño como en orientación. Si queremos soportar varias nos veremos obligados a generar los gráficos a 2 o 3 tamaños distintos.

Para páginas web es mejor pensar en un diseño fluido, que pueda adaptarse a pequeñas variaciones en las dimensiones de la pantalla e incluso al cambio de orientación de los dispositivos. En las aplicaciones nativas el cambio de orientación en los móviles puede servirnos para navegar entre diferentes pantallas o cambiar el modo de visualización (por ejemplo entre listado/gráfico de datos).

Si necesitamos ahorrar costes y sólo podemos hacer una versión de la aplicación/web no es recomendable hacerla para los dispositivos más potentes y con mejor pantalla, ya que los móviles más básicos tendrán problemas de rendimiento (almacenamiento en caché más limitado, procesador más lento, etc.). Si lo hacemos a la inversa (diseñar para los terminales básicos) perderemos calidad gráfica en los smartphones de última generación pero la app/web podrá ser usada por un mayor rango de usuarios.

Responsive design

Si estás trabajando en un proyecto web te puedes preguntar si es una solución viable recurrir al responsive design. En general el usuario no espera encontrar los mismos contenidos en una “situación móvil”, de forma que no basta con mostrar lo mismo pero con diferente distribución. Me parece una buena opción para webs pequeñas, como portfolios personales o páginas informativas de pequeñas empresas.

Si finalmente se opta por una solución de este tipo debe hacerse bajo la filosofía del progressive enhancement dado que las “media queries” de CSS en las que se basa este método no funcionan en todos los terminales. La versión base debe ser la que tenga el css básico, las imágenes pequeñas y sin javascript, y no la de PC. En la presentación Pragmatic Responsive Design podéis ver una explicación detallada de cómo se trabaja en un proyecto de este tipo y las dificultades que hay que resolver a lo largo del diseño y desarrollo.

En realidad, si se plantea correctamente, una web con responsive design puede llegar a ser mucho más cara que una versión móvil pensada y desarrollada desde cero. Cuánto más cara dependerá de los modelos de móvil que se quieran soportar. Una buena solución es combinar esta técnica con detección de dispositivo en el servidor para servir diferentes componentes clave dentro de la estructura de la página: RESS (Responsive Web Design + Server Side Components)

Subí una versión modificada de la presentación a SlideShare (la original tenía ejemplos de proyectos confidenciales) y parece que varias personas la encontraron bastante útil, de forma que he decidido escribir una serie de entradas explicando un poco más a fondo algunos conceptos.

Los smartphones no son ordenadores personales

Parece de perogrullo ¿no? Pero cuando uno se enfrenta por 1ª vez al diseño de una web/app para móvil lo que hace es tirar de los conocimientos y recursos que ya domina. Y las habilidades que tenemos son para diseñar “una web que se ve en una pantalla más grande que mi mano, manejada con teclado y ratón”. Es inevitable.

Entre las principales características de los dispositivos móviles que afectan al diseño encontramos:

• Uso en exteriores
  Puedes estar con tu móvil tranquilamente en tu salón… o en la playa bajo un sol de justicia. La luz solar directa sobre la pantalla afecta a la legibilidad y no puedes confiar en que el usuario busque una posición o lugar mejor para ver tus contenidos. El contraste entre los elementos del diseño es clave, hay que tener cuidado con los textos, los elementos que están seleccionados, los iconos sobre los fondos, elementos gráficos sutiles que sirven para agrupar items, etc.
• Las pantallas son pequeñas
  Por muy grande que sea la pantalla de tu móvil siempre será más pequeña que la de un ordenador, se ven menos líneas de texto y menos caracteres por línea. Una imagen demasiado grande puede lanzar el contenido por debajo de la línea de scroll (más aún en las Blackberrys con formato de pantalla horizontal), y en los dispositivos no-táctiles hacer scroll no es “tan cómodo”.
• No se realizan tareas largas o complejas
  Puedes consultar las redes sociales, leer un artículo, escribir un mail, jugar un rato… pero no vas a crear un Excel, diseñar un portal o hacer la declaración de la Renta (y si lo haces… háztelo mirar). Mucha gente huye al ordenador a registrarse en la App Store cuando ve el formulario en su iPhone (porque es un auténtico coñazo rellenarlo en un móvil). Diseña los procesos o tareas de forma que no requieran mucho esfuerzo.
• No dispones de la atención del usuario
  Al menos no al 100%. En cualquier momento puede entrar una llamada, o llega el autobús que estaba esperando, o su pareja le pide que le haga caso de una puñetera vez. También es habitual que se agote la batería o se pierda la cobertura. Una vez que el usuario vuelve a la tarea tras la interrupción tiene que quedar muy claro en que punto se encontraba y qué estaba haciendo.
• No están optimizados para la entrada de datos
  Los teclados son pequeños y muchas veces incompletos (es tedioso escribir una combinación de números y letras en las pantallas táctiles). Además no se pueden usar todos los dedos y mucha gente usa los pulgares, que no son los que más precisión tienen. Siempre hay que primar la selección sobre la inserción de texto, y dar opciones predefinidas cuando que sea posible.
• Distinta percepción de privacidad y seguridad
  Son más personales que los ordenadores ya que no se comparten entre amigos o familiares. Por otro lado se roban y pierden con mayor facilidad. En aplicaciones/webs financieras o que almacenan datos personales hay que saber transmitir al usuario que se encuentra en un área segura.
• Se manejan con menor precisión
  En los dispositivos con pantallas táctiles se usan mucho los pulgares. En los que tienen botones de dirección (up, down, left & right)  el foco salta a determinados elementos. Los que usan pad táctil o rueda son muy sensibles y cualquier pequeño desplazamiento del dedo genera un gran desplazamiento en pantalla. Puede ser realmente difícil acertar en un elementode interfaz determinado si es demasiado pequeño.

Hace un par de semanas, en una reunión con un cliente para revisar una propuesta de diseño web, se producía la siguiente conversación:

- Cliente: Y en esta opción… ¿por qué has puesto un enlace en lugar de un botón?
- Yo: Bueno, realmente te lleva a otra sección y al ser su jerarquía inferior a las otras dos opciones… blablebli (léase justificación de diseño más o menos válida)
- Cliente: Es que en general no queremos enlaces en este diseño, entendemos que últimamente los enlaces están pasados de moda y ya no se utilizan
- Yo: …

Este diálogo que parece más propio de una agencia de publicidad offline se producía ni más ni menos que con el departamento de innovación de una gran empresa.

Tras salir de la reunión le estuve dando vueltas al tema ¿de dónde surgía la impresión (equivocada) de que ya no se utilizaban los enlaces? La respuesta era evidente: de la proliferación de dispositivos con pantallas táctiles y aplicaciones nativas para los mismos. Estas aplicaciones utilizan botones para la navegación para invitar al clic, más aún al no existir el estado de rollover cuando interactuamos directamente con la pantalla.

Las pantallas táctiles están por todas partes

… o esa es la impresión que tenemos.

Los profesionales del sector online hemos recibido con entusiasmo la llegada de estos nuevos dispositivos, todos queremos planificar, diseñar, desarrollar para ellos, y en las agencias digitales, departamentos de estrategia online, departamentos de innovación, etc somos minoría los que no tenemos un smarphone o una tableta. Pero creo firmemente que esto nos está provocando una visión sesgada de cual es la verdadera penetración de esta tecnología en el resto de la población.

En el primer trimestre de 2011 las estadísticas decían que sólo 4 de cada 10 usuarios de móvil tienen un smartphone (Nielsen). Dentro de los smartphones Symbian sigue copando el 70% del mercado (aunque estos números cambian rápidamente en cada campaña de Navidad) y no todos los móviles de Nokia tienen pantalla táctil. Es más, en muchos grupos de población son mayoría los móviles con teclado, si os fijais un poco veréis que en el segmento de 13 a 20 años triunfan las Blackberrys (sorpresa!).

Es decir, para la mayoría de la gente la experiencia con pantallas táctiles sigue siendo la de interactuar con los cajeros automáticos. Mientras tanto nuestros diseños se llenan de botones y los transacionales de bancos, aplicaciones web y redes sociales cada vez se parecen más a los mandos del Enterprise. ¿De verdad es el momento de trasladar alegremente los modos de interacción de iPhone/Android a las páginas web? ¿lo entenderán bien todos los usuarios?

¿Cuándo usamos un enlace o un botón?

Las recomendaciones de usabilidad dicen:

• Los botones indican una acción (las acciones cambian datos)
• Los enlaces indican navegación (navegar no cambia datos, es reversible)

Evidentemente estas normas son elásticas y no se deben aplicar en modo talibán, pero tampoco debemos perderlas de vista simplemente porque hace 3 años que todo el mundo en la oficina tiene un iPhone. No olvidemos además que el peso visual de un botón es mucho mayor que el de un enlace.

Me llama la atención que, mientras la web cada vez se “butoniza” más, los sistemas operativos mayoritarios (Windows / Mac OS) van en dirección contraria: cada vez utilizan más enlaces en lugar de botones para moverse entre ventanas, estados, etc.

Los diseñadores visuales trabajamos día a día en proyectos grandes (portales de noticias, de ecommerce, transaccionales, comunidades online, etc) que se prolongan a lo largo del tiempo e implican cientos de plantillas de diseño. En este tipo de proyectos el mayor reto (aparte de tener paciencia y no aburrirte) es mantener la coherencia de la línea gráfica a lo largo de todas y cada una de las plantillas, más aún si se forma parte de un equipo de diseño que trabaja en paralelo.

El problema

Es fácil ser constante y mantener invariables los elementos más evidentes como la cabecera, el pie, la navegación… que al final vamos duplicando de un PSD a otro. Más complicado sin embargo es ser igual de rígido con los iconos, tamaños y colores de botones, tamaños y estilo de textos. etc. Más de una vez he terminado un proyecto y el maquetador ha tenido que indicarme amablemente que había definido 10 estilos de módulos para el mismo contenido en diferentes maquetas.

Los problemas que surgen de una falta de coherencia son múltiples y comprometen la calidad del resultado final

• Dificulta incorporar un nuevo diseñador al proyecto o que el equipo trabaje en paralelo en varias plantillas. Las dudas sobre qué solución gráfica aplicar a cada componente surgen continuamente.
• Aumenta el tiempo que se tarda en diseñar cada plantilla, pues olvidamos o ignoramos que ya se ha definido un elemento y nos encontramos reinventando la rueda una y otra vez
• Afecta a la calidad del código HTML/CSS pues se necesita declarar nuevos estilos para elementos que no comparten el diseño. El código crece de manera exponencial y acaba repercutiendo en los tiempos de carga de la web

Si tienes suerte y el proyecto se desarrolla “in house” pueden detectarse a tiempo las incoherencias y enmendarse directamente en maquetación aunque evidentemente esto provoca un retraso en los tiempos planificados. Por desgracia es algo que no siempre es posible.

La solución

La solución más sencilla a este problema es mantener un único archivo con todos los patrones de diseño que van surgiendo a lo largo del proyecto. Aunque supone un esfuerzo adicional a la hora de afrontar el trabajo nos ayuda principalmente en dos aspectos:

1. Actúa como memoria colectiva (y propia) del proyecto, reduciendo las desviaciones de la línea gráfica
2. Seremos más reacios a desarrollar una nueva solución gráfica si hacerlo implica tener que trasladarla a este archivo. En este caso la pereza nos hace mejores diseñadores.

Otras ventajas que obtenemos manteniendo este archivo son

• Funciona como una biblioteca de todos los elementos de diseño, agilizando la creación de nuevas plantillas que se pueden montar como si de un puzzle se tratara
• Ayuda a definir y unificar los estados de interacción (rollover, pulsado, activo, desplegado…) de todos los elementos. Un requerimiento en cualquier proyecto interactivo que suele olvidarse y resolverse de mala manera en el último momento.
• Facilita la tarea de los maquetadores que pueden ver de un vistazo todos los elementos que van a tener que definir en el código y qué estilos pueden ser reutilizados sin tener que bucear en distintos archivos y capas ocultas.
• Agiliza el desarrollo de una guía de estilo, un documento imprescindible para desarrollar nuevas plantillas o secciones, mantener la calidad del diseño a lo largo del tiempo y más aún si el proyecto será mantenido por el cliente.

Aunque lo más cómodo es comenzar con este archivo al inicio del proceso de diseño ningún momento es tarde para empezar a utilizarlo. Y vosotros ¿qué métodos empleais para no perderos a lo largo de un proyecto?

Recursos

• Modular Web Design: Creating Reusable Components for User Experience Design and Documentation
• Standards, Reuse, Consistency, & Libraries

El mejor ejemplo que he visto nunca de este tipo de archivo, por Yaron Schoen para Kontain

Nunca he comprendido a los diseñadores web que no tienen ningún porfolio online en absoluto. La mayoría suele poner como excusa la falta de tiempo, te dicen que están trabajando en ello o que como no buscan empleo no lo necesitan. La verdad es que a mí siempre me huele a una falta total de compromiso con su trabajo, yo desde luego nunca contrataría a un diseñador que no tuviera ningún tipo de información online. Es cierto que la mayoría de los diseñadores nos solemos estancar en un bucle infinito a la hora de desarrollar nuestra web personal pero existen opciones muy dignas que nos permiten tener una presencia online mientras dura el parto del porfolio definitivo.

Redes creativas

Existen muchas webs que funcionan como plataformas para que los creativos expongan sus trabajos y ganen visibilidad. La mayoría tienen un diseño muy cuidado y sencillo, aceptan distintos formatos de archivos (incluido audio o vídeo) y permiten mostrar tus trabajos a gran tamaño. Mi favorita es Behance pero otras opciones son Computer love o Domestika (aún en construcción). Darte de alta en alguna de ellas, rellenar algunos datos personales y subir unos cuantos archivos apenas lleva una tarde.

Web minimal

Otra opción es poner en tu dominio una página con un diseño muy sencillo y una breve descripción de quien eres. Dependiendo del tiempo (o esfuerzo) que quieras dedicarle a esta página puedes mostrar tus trabajos de diferente manera:

• Una simple lista de enlaces a tus trabajos publicados.
• Un enlace a tu cuenta de Linkedin, Xing o similar para mostrar tu CV y otro a una cuenta de Flickr donde subas tus diseños. 
• Un enlace a un PDF con tu CV y trabajos seleccionados.

Algunos ejemplos de este tipo de web son la portada de la web de Miguel Ripoll o la página de Alejandro Monge. En la sección de Coming soon de Design Meltdown podreis ver más ejemplos.

Galería de imágenes

Existen galerías muy vistosas tanto en  javascript (Galleria, FS Gallery o Slideviewer) como en flash (Slideshowpro). Fáciles de configurar y rápidas de personalizar te permitirán tener una muestra de tus trabajos en tu dominio en apenas unas horas.

Webs especializadas

Estas webs te permiten crear un porfolio de forma rápida y sencilla . A diferencia de las redes creativas este tipo de páginas no suelen poner su propia identidad corporativa en tu porfolio, ofrecen la posibilidad de escoger entre distintos diseños y éstos suelen ser más asépticos (tu trabajo destaca más). Dos buenas opciones son Carbonmade y Finalcrit. 

Cómprate un diseño

Si necesitas de manera rápida algo con más funcionalidad puedes optar por comprar una plantilla de diseño sencillo, tunearla ligeramente con tu identidad corporativa y rellenarla con tus trabajos. Existen muy buenas opciones a un precio razonable tanto en HTML plano como para WordPress o Flash. ¿Es triste ser diseñador y usar el diseño de otro? Sí, pero más triste es no tener nada de nada y al final lo que cuenta es el trabajo que vas a mostrar.