¿Por qué le toma meses a Asana entregar una aplicación móvil nativa con soporte fuera de línea?

Descargo de responsabilidad: esta es una respuesta larga.

En los últimos dos meses, he estado usando Asana intensivamente. También soy el propietario reciente de una cubierta de teclado para iPad, lo que me incitó a comenzar y usarla como una máquina de negocios, especialmente durante los viajes. Actualmente estoy escribiendo este artículo usando Elements, un editor de texto simple con soporte de sincronización a través de Dropbox.

Esto me llevó a pensar en las formas en que Asana actualmente admite el caso de uso fuera de línea en dispositivos móviles, y qué podrían hacer para que funcione mejor (spoiler: ¡mucho!). Por lo que puedo reunir, el servicio se creó en un mundo móvil pre ubicuo donde el acceso móvil y sin conexión no se veían como características clave.

• ¿Qué necesito para crear una aplicación como WhatsApp?
• ¿Qué debo construir, aplicaciones nativas o Xamarin.Forms?
• Si pudieras crear una aplicación para algo, ¿cuál sería?
• Cómo crear una aplicación móvil sin un SDK
• Muchos artículos afirman que el desarrollo de aplicaciones móviles morirá pronto y que PWA aumentará. ¿Es ilógico ahora comenzar a aprender el desarrollo móvil nativo?

Asana se trata de resolver el “trabajo sobre el trabajo”: dar a las personas una forma de rastrear, asignar y administrar lo que todos están haciendo ahora y lo que deberían hacer a continuación. Está orientado a definir y mostrar quién está haciendo qué en un momento dado. Esto es definitivamente algo que la gente quiere poder hacer con sus dispositivos móviles.

¿Qué hacen las personas sin conexión?

Como resultado, mucho:

“Ya estoy comenzando a arrepentirme de haber cambiado todo el equipo para hacer listas a Asana antes de que todos hayan adoptado el sistema, por la sencilla razón de que me sorprende no encontrar ninguna forma de manipular las listas fuera de línea”. [1]

“A la versión móvil le faltan opciones esenciales como editar la lista de seguidores, proyectos o etiquetas de una tarea. Sin estas opciones, uno se ve obligado a hacer un trabajo adicional una vez que regrese a su oficina”. [1]

“P. ¿Qué quieres hacer sin conexión? ¿Ver contenido? ¿Editar contenido? ¿Agregar?
A. Ver contenido, marcar tareas completadas, ajustar fechas de vencimiento, agregar tareas / proyectos, editar etiquetas “[2]

“La función fuera de línea de Asana, como veo, debería ser una verdadera ubicuidad, así que no me doy cuenta de qué estado estoy en este momento. Por ejemplo, si estoy en línea haría un cambio y se replicarían en todas las demás plataformas pero si no estoy conectado, ocurrirá lo mismo cuando la aplicación encuentre una conexión de red que funcione “. [2]

La gente es desordenada. Usan sus dispositivos en lugares donde sus computadoras no habían ido antes. Abordan aviones. Van donde la red no lo hace. Anotan ideas en los momentos más inapropiados. Viven sus vidas y esperan que sus listas de tareas los sigan donde quiera que vayan.

Principios rectores de Asana

Las dos premisas principales que presidieron el nacimiento de Asana (según lo detallado por Justin Rosenstein en una respuesta de Quora [3]) son las siguientes:

• Velocidad ( “haz que Asana sea realmente rápida” )
• Coordinación del equipo ( “Comunicación como un efecto secundario de mantenerse organizado” )

Es fácil ver cómo Asana en dispositivos móviles actualmente falla en ambas pruebas. Dada su lentitud y la falta de soporte fuera de línea, la aplicación no permite organizar eficientemente el trabajo mientras está en movimiento. En lugares con una excelente conexión wi-fi, el rendimiento de la aplicación es aceptable como mejor. Tan pronto como la conexión se vuelve irregular, se vuelve prácticamente inutilizable. La aplicación móvil actual de Asana está construida con HTML5. Como lo han reconocido ellos mismos, esto no es lo suficientemente bueno [4].

HTML ha progresado increíblemente en la última década. Se ha transformado de un lenguaje de marcado simple orientado a la presentación de contenido a una combinación de varias tecnologías que se pueden utilizar para crear interfaces de usuario increíblemente ricas y receptivas en el navegador. En el navegador web de escritorio que es.

Los navegadores móviles todavía están en su infancia relativa. Carecen del poder y la gama de características disponibles en sus contrapartes de escritorio. El soporte sin conexión aún no es sencillo. Los navegadores móviles llegarán allí, pero todavía no están allí.

Combinado con la facilidad de descubrimiento e instalación de aplicaciones nativas y su rendimiento superior, esto hace que las aplicaciones HTML5 sean la elección de los pobres cuando se vuelven móviles en el futuro previsible (al menos un par de años). Para lograr sus objetivos, Asana tiene que volverse nativa. Aparentemente han dado el salto, pero aún no se han obtenido resultados.

El desafío de sincronización

Hay un desafío al crear una aplicación móvil que funciona sin conexión: la sincronización. En comparación con esto, todos los demás aspectos son secundarios. Claro, necesitará una experiencia de usuario excelente y receptiva que se adapte a la forma en que los usuarios se comportan mientras están en su dispositivo móvil. Asana ha demostrado que podrían hacerlo correctamente en el escritorio. Tienen expertos en UX de clase mundial. Ellos pueden hacerlo.

Pero la sincronización simplemente no es fácil. ¿Debería llevar todos los datos de sus espacios de trabajo fuera de línea? ¿Debe seleccionar lo que desea tener disponible sin conexión? ¿Qué sucede si otras personas trabajan en tareas mientras estás fuera de la red? Echemos un vistazo rápido a la variedad de casos de uso que la aplicación podría encontrar al volver a estar en línea:

• Se agregó un elemento (espacio de trabajo / proyecto / tarea / comentario)
• Se eliminó un elemento.
• Se actualizó un elemento (nueva fecha de vencimiento, nuevo cesionario, diferentes etiquetas)
• Si estuvo fuera de línea durante un período prolongado, la actualización de todas las entradas llevará algún tiempo

Aquí hay un escenario típico: antes de abordar su avión, toma una copia local de sus últimas tareas de desarrollo. Trabajarás en ellos mientras estás en el aire, ¡sí! Decide agregar una pequeña e ingeniosa nueva característica, que documenta en una tarea. Sin embargo, al mismo tiempo que está hackeando felizmente su teclado, su gerente de ingeniería decidió hacer una limpieza de proyectos y eliminó el proyecto en el que acaba de agregar su tarea, después de haber movido las tareas en ese proyecto a otros dos proyectos.

¿Qué debería suceder cuando vuelvas a estar en línea? ¿A dónde debe ir tu tarea solitaria? No hay una respuesta correcta a esta pregunta. La aplicación podría comportarse razonablemente de cualquiera de las siguientes maneras:

• Vuelva a instalar el proyecto eliminado y agregue la tarea en él.
• Ofrecerle mover la tarea a uno de los otros dos proyectos.
• Ponga la tarea en un proyecto temporal “para clasificar”

¿No estás seguro de cuál es el mejor? Tampoco la gente de Asana en este momento.

Dada su naturaleza en tiempo real, la aplicación de escritorio no enfrenta ninguno de estos problemas. Tan pronto como pierde su conexión a Internet, la aplicación se congela y le pide que se vuelva a conectar. Los conflictos no pueden suceder ya que todo se refleja en la interfaz de usuario tal como sucede. No existe tal seguridad con el caso de uso fuera de línea. Se deben hacer compensaciones.

Dos escenarios

Cuando se enfrentan a tales compensaciones, las aplicaciones tienen dos opciones: hacer que el usuario elija o use valores predeterminados razonables. En el primer caso, esto se traducirá en una serie de cuadros de diálogo con los que el usuario tendrá dificultades para lidiar: “No sé a dónde debe ir esta tarea, ¡solo póngala en algún lugar!”. En el segundo, el usuario probablemente se quejará del comportamiento de la aplicación: “¡¿dónde diablos fueron mis tareas ?!”. Ninguno de ellos es óptimo.

Alejarse de la simplicidad es un desafío que todas las aplicaciones no triviales tienen que resolver en algún momento para ofrecer un valor sorprendente a sus usuarios. Apple enfrenta actualmente muchos de los mismos problemas con iCloud. ¿Cómo domesticas el poder y la simplicidad de una sola vez?

Aquí es donde entra la magia. La magia es cuando una pieza de software hace algo que no creías posible de una manera tan elegante y perfecta que no puedes sentir que hay otra forma en que las cosas podrían (ni deberían) funcionar. Escribir en el mismo documento al mismo tiempo en Google Docs. Encontrar amigos en Facebook (no se equivoquen, se necesita una gran cantidad de ingeniería). Comprar e instalar una aplicación en su teléfono.

Complejidad hecha simple. En cierto modo, este es el desafío que Asana se ha propuesto desde el principio. Convertir a las organizaciones humanas en organismos eficientes de creación y entrega es una tarea tremenda.

Poder y magia

Supongo que los ingenieros y la gente de UX en Asana han estado pensando mucho sobre estos desafíos. Están tratando de encontrar la mejor manera de evitarlos. Estamos hablando de personas que pasaron 2 años construyendo su propio marco: no se apresurarán por hacerlo.

No estoy seguro de cómo analizaron las cosas, pero así es como las vería. El problema con los problemas complejos es ponerlos en funcionamiento. Es decir, conviértalos de conceptos abstractos a bits prácticos y procesables. Una buena forma de hacerlo es comenzar con los peores escenarios y ordenarlos por importancia relativa:

1. Perder datos: hice cosas sin conexión que no se llevaron a cabo
2. Datos en conflicto: alguien más editó las mismas tareas que hice y la fusión no funciona
3. Confundiéndome: hice cosas sin conexión y no puedo ver dónde se refleja una vez que volví a estar en línea
4. Conseguir problemas: la aplicación no sabe qué hacer con mis datos y sigue preguntándome, preguntándome dónde poner las cosas

No hay forma de resolver este problema de manera eficiente sin mirar primero los datos. Por lo tanto, esto es lo que haría:

1. Lanza una versión que maneja la sincronización de una manera básica y depende en gran medida del usuario para resolver conflictos a través de múltiples indicaciones. Asegúrese de que no se pierdan datos, nunca.
2. Ponga esta versión a disposición de un número seleccionado de personas (primero dentro de la empresa, luego con un pequeño número de beta testers) e instruméntela como el infierno.
3. Según los datos de uso reales, cree una nueva versión que intente y resuelva automáticamente los casos de conflicto más frecuentes. Intente reducir la cantidad de mensajes de forma incremental.
4. Enjuague y repita hasta que la aplicación esté lista para el horario estelar. Las tareas se sincronizan a la perfección. ¡Mágico!

No tengo idea de si este es el camino real elegido por Asana, pero explicaría en gran medida por qué les está tomando tanto tiempo implementar una aplicación móvil nativa.

Referencias

[1] http://help.asana.com/customer/p…
[2] http://help.asana.com/customer/p…
[3] ¿Qué es específicamente el edificio de Asana? ¿Puede alguien del equipo compartir información sobre sus planes de productos?
[4] http://blog.asana.com/2012/06/th…