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)

Etiquetas: consejos, diseño, diseño móvil, dispositivos móviles, smartphones