Aplicaciones Contextuales
En la primera parte de este artículo, hacíamos un análisis de la evolución del uso de Internet, de los dispositivos y de las tendencias del usuario, hacia un tipo de aplicaciones que se tienen que adaptar no solo a los diferentes dispositivos donde se visualizan, sino a los diferentes contextos en los que el usuario interactúa con ellas.
Citaba entonces como ejemplo Synctur, un proyecto en el que estoy involucrado desde hace años y que se basa totalmente en este concepto, no obstante, durante el desarrollo de una aplicación contextual siempre hay una serie de problemáticas comunes, que hay que solucionar, y que analizaremos a continuación.
Instalación
El primer proceso al que se enfrenta un usuario a la hora de usar una aplicación, es su instalación, es vital que este primer proceso sea fluido y limpio si queremos que la primera impresión (que cuenta y mucho) sea positiva. Es por tanto un paso crucial de la usabilidad y contextualización de nuestra aplicación, el integrarse al máximo con cada plataforma, como puede ser un instalador de escritorio, la App Store de Apple o el android market de Android.
Contenidos en la nube
Los contenidos son la clave de la aplicación, no necesariamente tienen que ser información convencional, o tener una relación con el usuario unidireccional, pero en una aplicación contextual es vital que estén independizados del desarrollo y de la presentación. Para ello, hoy en día, y teniendo en cuenta el acceso a Internet creciente desde dispositivos móviles, una solución basada en contenidos en la nube, es en mi opinión la más acertada. Esta decisión a nivel de arquitectura en tu aplicación te permitirá tener un control absoluto de los contenidos, solventar problemas sin interferir de manera directa en el usuario y portar la solución a cualquier nueva plataforma o lenguaje. Contenidos descontextualizados, para que sea cada versión la que los contextualice de manera óptima para el usuario.
Esta decisión no es gratuita, existen muchos factores que hay que tener en cuenta a nivel de desarrollo si te decantas por ella como: uso de precargas, optimización de contenidos para agilizar la descarga, consumo de datos, generación de contenidos al vuelo para lograr el anterior punto (como imágenes a medida), cacheado de contenidos en local para evitar repetir peticiones innecesarias y agilizar algunos procesos, sistemas inteligentes de carga en segundo plano, advertencias de descarga de contenidos especialmente pesados, etc.
Múltiples pantallas: resoluciones y dpis
Hasta hace no mucho tiempo, el principal problema de una aplicación multidispositivo, eran las diferentes resoluciones de las pantallas, y cómo abordar la distribución de los contenidos en rangos tan variados que iban desde 240x320px (resolución que durante muchos años fue un estándar en móviles) a 1024x768px (resolución que durante muchos años marcó la base en monitores). Hoy en día a esta problemática, que se ha visto acentuada con la aparición de los mini-portátiles y las tablets, hay que sumar una aún más compleja la densidad de píxel.
Los avances tecnológicos en pantallas han permitido mantener resoluciones de dimensiones considerables en muy pocas pulgadas, gracias a un aumento más que significativo en su densidad de píxel. Para hacernos una idea, comparemos tres terminales: Nexus One, Motorola Droid X e iPhone 4. El primero dispone de 254dpi, el segundo de 228dpi, y el tercero con su retina display ofrece al usuario 326dpi.
La consecuencia de esto es que ya no solo tenemos que solventar el problema de la interfaz a nivel de espacios, sino del tamaño de los controles para que al visualizarse a determinados dpi, no dejen de ser usables, ya que a más dpi, menos espacio “real” ocuparán nuestros controles en pantalla, y como ejemplo una imagen que vale más que mil palabras:
La solución para esta problemática pasa por la combinación de varias técnicas: interfaces diferentes para diferentes rangos de dispositivos, interfaces líquidas en resolución e interfaces líquidas en dpis. El primer paso sería crear grupos de dispositivos destino que tendrían diferentes interfaces adaptadas a sus capacidades, y el segundo aplicar un diseño líquido tanto en espacios como en dpis para adaptarse a las pequeñas variaciones dentro del propio grupo.
En el caso de los dispositivos casi siempre el ancho se trabaja al 100% (cabeceras, barras de herramientas, pies, listados…) y lo que hay que adaptar es el alto de los elementos. En el caso de la adaptación por dpis, además del tamaño en objetos gráficos, hay que tener en cuenta las tipografías. Una buena manera de abordarlo es diseñando para una resolución y dpi base, obtener del dispositivo sus valores, y aplicar una regla proporcional (el valor varía en función del diseño base y del dispositivo en el que se visualiza) a cada elemento de la interfaz, tamaños de tipografía, imágenes, etc. para corregir el propio “desfase” que implicarían las diferentes dpis. Así logramos aplicaciones visualmente “proporcionadas” independientemente del tamaño en pixel de los elementos.
Patrones de diseño: navegación, menús, listados, botones nativos…
Para afrontar en cada versión que hayamos delimitado para un grupo de dispositivos, es necesario adaptarse a su naturaleza y usabilidad. Cada marca y dispositivo impone al usuario un comportamiento para acceder a la información, unas convenciones implícitas que el usuario va adquiriendo con el uso del dispositivo, y que en ocasiones se regularizan y casi se convierten en estándares de facto. Nuestras aplicaciones normalmente no deberían desmarcarse de este camino, salvo que hubiera un motivo realmente importante detrás.
A la hora de diseñar las interacciones, las pantallas, los menús, listados… debemos analizar cómo son nativamente en ese dispositivo, y crear un paralelismo que ayude al usuario a que la curva de aprendizaje sobre la aplicación sea lo menos compleja posible. Además debemos combinar este hecho con el punto anterior, relativo a la distribución de contenidos, y analizar muy bien qué patrones de diseño aplicaremos para cada tipo de contenido.
Un ejemplo muy claro de esto es el menú de rejilla clásico que se emplea en iOS y Android, que no ha sido creado por casualidad. Este menú permite adaptarse perfectamente a diferentes tamaños de pantalla, aprovechando el espacio siempre al máximo, y pudiendo ofrecer en un terminal una rejilla de 3×3 por sus dimensiones, y aprovechar hasta una rejilla de 5×5 en uno de mayores dimensiones, lo que repercute en menos scroll para el usuario, y una experiencia consistente en ambos. Si extrapolamos esto entre un móvil y un tablet, el resultado es ideal en cuanto a la relación complejidad de desarrollo/funcionalidad para el usuario.
Al igual que los menús, los modelos de listados (con índices de acceso rápido, filtrados,…), páginas de detalle, sistemas de scroll, barras de navegación o herramientas, son vitales para que la aplicación se adapte en este caso al contexto a nivel de dispositivo, sin olvidar nunca los botones nativos con los que pueda contar el propio terminal (como por ejemplo el botón volver en Android, o el central en iOS).
Funcionalidades
Finalmente y más allá de las cuestiones puramente técnicas, existe otra parte clave de la problemática en la confección de las versiones de una aplicación contextual, que es la definición de funcionalidades para cada contexto. Aquí el contexto va mucho más allá del dispositivo donde se visualiza, abarcando aspectos del usuario como ubicación, entorno, tiempo, espacio, ambiente… y es que hay que tener en cuenta que una aplicación debería estar totalmente condicionada por el modo en el que el usuario quiere interactuar con ella. No podemos pedirle lo mismo a una aplicación de reservas, que a un visor de galerías de fotos familiares, porque sin duda la predisposición del usuario ante ella va a ser totalmente diferente en el lugar donde la consulta, en el tiempo que quiere invertir, en su actitud en el momento de emplearla, etc.
Es por ello que las funcionalidades de una versión de escritorio pueden ser muy diferentes a las de una versión en movilidad, pero también complementarias. Siempre hay que tener en mente que la experiencia en una aplicación contextual ha de ser continua para que el usuario la perciba como única. Por tanto es vital generar una lista de funcionalidades a partir de la información (que es la clave de todo esto) en relación a los diferentes contextos del usuario, y portar esas funcionalidades en cada versión adaptando su interactividad a las limitaciones del dispositivo. Esto es el punto clave del análisis, y donde se basa el éxito más allá de la capacidad técnica del equipo de desarrollo.
En esta línea siempre se deberían tener en cuenta funcionalidades como: mapas, servicios geolocalizados, búsquedas por proximidad, favoritos para acceso rápido, etc. en contextos en movilidad, y planificadores, sistemas de valoración, comentarios e inmersión en redes sociales, gestión de datos de usuario y preferencias, guardado local, etc. en contextos más cómodos para el usuario como escritorio
Cita recomendada: GONZÁLEZ SANCHO, Marcos. Aplicaciones Contextuales, parte II. Mosaic [en línea], junio 2011, no. 88. ISSN: 1696-3296. DOI: https://doi.org/10.7238/m.n88.1128.