Desde el punto de vista del cliente, las preocupaciones u objetivos que más destacan en su feedback suelen ser estos tres:
- El servicio debe ser accesible desde el móvil
- Nuestro servicio debe poder ser consumido desde un canal móvil
- Nuestro servicio debe tener una buena experiencia desde el móvil
Hasta ahora, los desarrolladores web contábamos con la ventaja de poder desarrollar nuestra plataforma y mantenerla de forma centralizada en nuestros servidores, preocupándonos únicamente en la parte frontal de los detalles o soportes de diferentes navegadores.
Habíamos huido del trabajo que suponía el mantener y dar soporte a instalaciones de nuestro software en distintos entornos o sistemas operativos que controlaba el cliente. Esta sensación que creíamos olvidada, ha retornado con la revolución de las aplicaciones móviles que suponen una oportunidad para los negocios que construimos: la oportunidad de estar en el bolsillo del cliente vaya donde vaya.
Los usuarios pueden acceder a nuestro servicio mientras van en el metro o consumen los últimos minutos del día antes de dormir.
Sin embargo, aprovechar esta oportunidad, aumenta el coste del desarrollo y de su posterior mantenimiento ya que supone desarrollar una aplicación para cada uno de los sistemas implantados en los teléfonos disponibles, teniendo en cuenta versiones del sistema y la experiencia de uso.
Por lo tanto, un desarrollador web o un equipo de desarrollo web tiene que tener en cuenta:
Índice
Las cosas que no son programación
Asier Marqués
Aunque un desarrollador delegue la parte de definición del producto o el diseño de la interfaz, es imperativo ser consciente de que una aplicación móvil se utiliza de forma distinta a un sitio web y la arquitectura de información junto a la navegación deben cumplir las expectativas de un usuario.
La idea es que no se trata de que nuestra aplicación se “parezca” a una aplicación móvil sino de que lo sea y se comporte como tal.
Al margen del diseño, importan cosas como la estrategia de notificaciones, la cantidad de información a mostrar o pedir, el comportamiento táctil, las reducción de features a ofrecer en comparación a la plataforma web y sobre todo, las integraciones con el dispositivo móvil y las implicaciones del hacerlo (consumo de batería, tipo de conexiones a hardware externo etc.)
Lo que sí es programación
Y en lo referente a la programación, aquí debemos tomar decisiones importantes:
- Si nuestra aplicación debe instalarse en el dispositivo o no
- Si nuestra aplicación debe ser nativa o no
- En el caso de que optemos por desarrollar en nativo, si utilizamos una solución multiplataforma o no
- Si requerimos un acceso web
- Si en la parte web de nuestro servicio tiene sentido ejecutar una aproximación responsive Mobile First o por el contrario ser Tablet First y crear una webapp
- Voy a dar mi opinión sobre estos puntos comentando algunas de las herramientas que he probado empezando por el último punto.
Responsive sigue sin ser opcional pero el ‘mobile first’ es muy del 2011
A menos que tu servicio sea extremadamente simple, atacar una estrategia teniendo en cuenta la adaptación del diseño en la resolución móvil bajo mi punto de vista puede aportar mayor coste de desarrollo, diseño y mantenimiento sin llegar a cumplir las expectativas del usuario.
Hay excepciones, como los sitios web de contenido que no vayan a crecer en otros aspectos de negocio. Sin embargo, en una plataforma en la que tenemos mucha problemática de interacción, intentar llegar a la vista móvil a base de adaptar el diseño puede conllevar:
- Aumentar el peso de la página. Normalmente la técnica principal a la hora de hacer responsive es ocultar o mostrar elementos del HTML en base a la resolución de la pantalla, por lo que si nuestra plataforma crece también crecerá la cantidad de código a servir que tiene implicaciones como el tiempo de carga del sitio web.
- Aumentar la complejidad en el front. Si para evitar aumentar el peso, decidimos aplicar o crear soluciones de carga bajo demanda, estaremos aumentando la complejidad del código en el frontal que realmente no está aportando valor de negocio y encarece el mantenimiento.
- Mezclar problemáticas de experiencia de usuario. En ambos casos, estamos mezclando dos experiencias de uso totalmente distintas e intentando resolverlas prácticamente con calzador en el peor de los casos o intentando “parecer una aplicación móvil” en el mejor de ellos.
En mi opinión, si la plataforma es grande y planea crecer en requisitos de interfaz ya no es opcional el crear un acceso móvil separado con su propia experiencia de usuario.
Crear una webapp mobile
Como he comentado anteriormente, cuando atacamos el problema de desarrollar una aplicación móvil, aunque sea basada en web, tenemos que aprender a enfocar el diseño del servicio de una forma totalmente distinta a como lo platearíamos para una solución web en otras resoluciones y sobre todo, si estamos hablando de pantallas no táctiles.
En algunos servicios como Airbnb, Facebook, Badoo o Soundcloud tenemos buenos ejemplos de webapps.
Aunque el desarrollo sea web, no nos libramos de comprender cómo funciona cada plataforma, qué tipo de menús e interacciones el usuario espera encontrar y qué herramientas tiene el navegador para dotar a nuestra aplicación web de navegador de un comportamiento nativo.
Por ejemplo en iOS podemos hacer uso de los Smart Banners, las Safari notifications que permite enviar notificaciones al móvil aunque no este el navegador abierto o mejorar el rendimiento del scroll con un sencillo hack de CSS.
Para afrontar este tipo de desarrollos podemos optar por utilizar algún framework que nos facilite la tarea que ya implementan algunas de estos hacks a nivel de CSS.
Existen buenas opciones, algunas incluso adaptan el diseño dependiendo de la plataforma con la cual se acceda. Entre las más utilizadas están ionic, onsen ui, chocolat chip ui, ratchet y app.js.
Personalmente echo en falta una opción que no implemente javascript y sea una solución potente a nivel de css y html compatible con navegadores que no tengan que ser los más modernos.
Crear una aplicación instalable híbrida
Si queremos instalar nuestra aplicación en el dispositivo móvil la opción más socorrida por desarrolladores con experiencia web es la utilizar tecnologías como Phonegap/Cordova.
Básicamente estas aplicaciones se desarrollan de forma similar a una aplicación web móvil de navegador pero teniendo acceso a recursos del sistema como los sensores, cámara y almacenamiento.
Aunque parece la solución perfecta ya que el desarrollador puede aprovechar su experiencia en desarrollo web para ser productivo y crear aplicaciones con muy poca curva de aprendizaje inicial, disponemos de limitaciones con respecto a las aplicaciones nativas.
Al ser desarrolladas en HTML/CSS/Javascript es menos costoso también lograr implementar diseños con cierta complejidad o incluso imposibles de realizar en una aplicación nativa.
Simplificando mucho, una aplicación híbrida no es más una web en HTML y programación en javascript que funciona dentro de un navegador que el usuario no ve.
Sin embargo, si queremos realizar operaciones pesadas con el móvil (procesar video, componer música, mover mapas con gran cantidad de información) el rendimiento puede verse comprometido o incluso no poder hacerse con HTML o Javascript, teniendo que crear algún plugin nativo para cada una de las plataformas.
Normalmente, prácticamente el 90% de las aplicaciones que se desarrollan para un servicio online no requieren realizar tareas tan pesadas y una aplicación híbrida puede reducir mucho el coste de desarrollo.
Crear una aplicación instalable nativa
Esta es la opción que nos permite aprovechar todo el potencial del hardware del usuario.
Tenemos dos opciones cuando afrontamos un desarrollo de este tipo: desarrollar una aplicación por cada una de las plataformas (android, iOS, windows phone..) o utilizar una solución que nos quite el mayor trabajo posible de mantenimiento en cada una de ellas.
Hay que tener en cuenta que aunque desarrollemos para una plataforma en concreto podemos tener versiones que no tengan nada que ver. Por ejemplo en Android, una versión 3 difiere en tantas cosas de una versión 4 que podríamos tener que plantearnos tratar esas versiones como dos plataformas distintas y dos apps distintas. Es un problema que no afecta sólo a aplicaciones nativas sino también a webapps híbridas o incluso de navegador.
Si optamos por una solución que nos permita compartir código entre plataformas, las opciones más visibles en la actualidad son Appcelerator Titanium y Xamarin, la opción que más he investigado.
En mi caso descarté Titanium en favor de Xamarin porque todo el conocimiento que adquiría con la herramienta me ataba a ella. La forma de trabajar en Titanium no se parece ni se puede llevar al desarrollo de la plataforma en concreto.
Esto es especialmente importante en la parte de las vistas ya que sin lugar a dudas, la implementación del diseño es la parte más costosa en un desarrollo móvil nativo. En Xamarin puedes copiar y pegar todo el trabajo realizado en las vistas de una aplicación Android a una aplicación Xamarin.Android y funciona sin tocar absolutamente nada. Esto para mí significa no perder ni dinero ni conocimiento en el caso de que la herramienta en un futuro cambie de rumbo o desaparezca.
Otro punto en contra de Titanium es que aunque el código del framework es nativo, el código de tu aplicación en javascript es interpretado, perdiendo rendimiento en comparación al desarrollo nativo de cada plataforma o el desarrollo con Xamarin.
Xamarin tiene muchas más ventajas adicionales, por ejemplo se comprometen a dar soporte en el mismo día de las nuevas funcionalidades que salgan en las actualizaciones de los sistemas operativos soportados. También disponen de un framework (Xamarin.Forms) para construir vistas convencionales con una sola base de código.
Aunque no todo es maravilloso ya que tanto el IDE Xamarin Studio y las extensiones para Visual Studio deben mejorar muchísimo todavía. Tampoco te libra de conocer las particularidades de cada plataforma pero sí que te evita tener que dominar lenguajes específicos permitiendo centrarte en c#
Aunque sea de pago, merece mucho la pena evaluar el desarrollo con esta herramienta, sobre todo si no quieres mantener desarrollos en tecnologías distintas o tener en tu equipo desarrolladores especializados en cada lenguaje concreto de cada plataforma.
Conclusión
El camino para desarrollar aplicaciones móviles viniendo del desarrollo web, que es naturalmente multiplataforma, no es para nada trivial.
No sólo requiere que tomemos decisiones en cuanto a herramientas a utilizar para crearlas sino también pensar en su posterior mantenimiento.
También debemos cambiar la forma en la que diseñamos nuestros servicios para tener en cuenta las expectativas de nuestros usuarios fuera de su portátil o equipo de sobremesa.
Asier Marqués es arquitecto de software y desarrollador web, empresario en internet. Puedes seguirlo en Twitter en @asiermarques o contratar sus servicios en Simettric.
