Mark Zuckerberg dijo una vez: “El mayor error que cometimos, como empresa, fue apostar demasiado por HTML5 en lugar de nativo… porque simplemente no estaba allí. Y no es que HTML5 sea malo. De hecho, estoy, a largo plazo, muy entusiasmado con eso”. ¿Y quién no estaría entusiasmado con la perspectiva de una única base de código que funcione en múltiples plataformas ?

Lectura adicional en SmashingMag:

• Una guía para principiantes sobre aplicaciones web progresivas
• Los componentes básicos de las aplicaciones web progresivas
• Creación de una aplicación web completa en Foundation For Apps

Desafortunadamente, Facebook sintió que HTML5 no ofrecía la experiencia que buscaba construir, y de eso se trata realmente: la experiencia. Creo que lo que Mark realmente estaba tratando de decir era que su mayor error fue tomar una decisión impulsada por la tecnología en lugar de una decisión impulsada por la experiencia del usuario. Al final del día, debemos tomar decisiones que brinden valor a nuestros clientes , y apegarse a una tecnología en particular generalmente no es la mejor manera de lograrlo.

Para nuestro cliente Beyond the Rack, un minorista de comercio electrónico solo en línea, nuestro objetivo principal era crear una aplicación con una gran experiencia de usuario. Al igual que Zuckerberg, también queríamos tomar la ruta HTML5: el enfoque de "escribir una vez, ejecutar en todas partes" para las aplicaciones que están escritas en interfaces web HTML5 es extremadamente atractivo. Pero en el mundo actual, donde las aplicaciones se están convirtiendo en la forma principal en que los usuarios interactúan con su producto, el rendimiento no es solo algo agradable, es una ventaja competitiva.

Sin embargo, casi nunca es el caso de que todas las características de su aplicación deban construirse con interfaces completamente nativas. Por ejemplo, si bien puede ser difícil hacer que las animaciones de navegación se sientan nativas en la web, una página web que contiene poca o ninguna animación compleja podría usarse fácilmente en la aplicación sin dejar de sentirse nativa. Esto es todo lo que realmente le importa al usuario. Lo que se requiere entonces es una estrategia de "tal vez escribir una vez, tal vez ejecutar en todas partes; realmente depende de la característica...".

En definitiva, no elijas entre interfaces nativas y web . Usa ambos.

En este artículo, lo guiaré a través de nuestra experiencia en la creación de una aplicación para Beyond the Rack en la que mezclamos contenido nativo y web para crear una aplicación que "se siente" nativa.

Estudio de caso: Creación de una aplicación para Beyond The Rack

Obviamente, era importante determinar qué problemas Beyond the Rack buscaba resolver para sí mismo y para sus clientes con su aplicación. La elección de si ir nativo o web para cada función vendría naturalmente de eso.

Nos dimos cuenta de que para crear una gran aplicación, necesitábamos hacer un gran trabajo con las tres cosas siguientes:

• Interfaz de compras
  Beyond the Rack es un minorista solo en línea; por lo tanto, tener una excelente interfaz para buscar ofertas y realizar compras es crucial. Debido a que estábamos creando una aplicación nativa, tuvimos la oportunidad de ir más allá de lo que puede ofrecer la experiencia web.
• Compartibilidad
  Debido a que un gran impulsor de ingresos para Beyond the Rack son los clientes que comparten varios artículos de venta con amigos, necesitábamos asegurarnos de que compartir entre iOS, Android y el navegador fuera lo más fluido posible.
• Visibilidad
  Beyond the Rack ofrece ventas por tiempo limitado a sus usuarios; por lo tanto, poder llegar a los usuarios rápidamente es muy importante. La mensajería push ofrece la mejor manera de involucrar a esos clientes leales y, en última instancia, fue el factor más importante en la decisión de crear la aplicación.

Profundicemos en cómo construimos algunas de las funciones más importantes de nuestras aplicaciones Beyond the Rack para iOS y Android: qué funciones de la aplicación se crearon con tecnología web, qué funciones son completamente nativas y cómo funcionan juntas.

La interfaz de compras

Los bits nativos

Habíamos creado un sitio web receptivo para Beyond the Rack en tabletas y dispositivos móviles, uno del que estábamos orgullosos. Pero no fue suficiente simplemente poner el sitio web en una vista web y dar por terminado el día; el sitio web en sí mismo no se siente como una aplicación nativa. Una gran razón para ello es la navegación. En un navegador, tiene botones de avance y retroceso y una barra de URL. En las aplicaciones de iOS y Android, los usuarios tienen expectativas muy diferentes sobre cómo navegar, y queríamos cumplir esas expectativas para que nuestra aplicación se sintiera coherente con cada plataforma.

Hicimos un prototipo que carga contenido dinámicamente a través de AJAX y administra la navegación y las transiciones en los idiomas web, pero no pudimos lograr que se sintiera tan fluido como las transiciones que se ven en las aplicaciones nativas. Las animaciones de navegación en iOS y Android son bastante difíciles de igualar usando la tecnología web, y cualquier bloqueo en la navegación haría que nuestra aplicación se sintiera menos nativa. Si su aplicación no se ejecuta a 60 cuadros por segundo, los usuarios lo notarán.

Se nos ocurrió un enfoque que sentimos que combina lo mejor de ambos mundos: cargue el contenido principal de la web, pero use elementos de navegación nativos:

En iOS, implementar esto fue bastante simple. Aprovechamos el controlador de navegación, que administra una pila de vistas, así como una barra de navegación para controlar la navegación entre cada vista. En nuestro caso, la pila de vistas es realmente solo una pila de vistas web: cada vez que se produce una navegación, en lugar de navegar hacia ella en la vista web en sí, instanciamos una nueva vista web, la empujamos a nuestro UINavigationController y navegamos a la Nuevo destino. El uso de pilas de vistas web también significa que cada vez que el usuario regresa, no tiene que esperar a que la página se vuelva a cargar, lo cual es excelente para su experiencia. Si en el futuro decidimos reemplazar una función con una vista nativa, simplemente insertaremos una vista nativa en la pila, en lugar de la versión de vista web de esa función.

En Android, el equivalente del controlador de navegación sería usar pilas de actividades. Decidimos no utilizar múltiples actividades y fragmentos, porque ambos requieren una gestión del ciclo de vida extremadamente compleja. Terminamos administrando nuestra propia pila de vistas web para la aplicación y escribiendo animaciones nativas personalizadas para hacer la transición entre cada vista.

Varias otras aplicaciones aprovechan los elementos de navegación nativos para ajustarse a los patrones de diseño del sistema operativo. Mira esta imagen de la aplicación de Android de Basecamp, que aprovecha una barra de navegación nativa:

Además, compare la aplicación de Amazon con su sitio web móvil:

Con este enfoque, encontramos nuestro punto óptimo de tener una experiencia que se siente familiar para la plataforma , mientras seguimos aprovechando una excelente experiencia de compra central desde la web.

Esto puede ser una sorpresa para muchos, pero los desarrolladores de la aplicación de Facebook también encuentran constantemente el punto óptimo, aprovechando la versión nativa o la web cuando tiene sentido para cada característica. Según un artículo escrito por un ingeniero de Facebook: “Para las áreas dentro de la aplicación en las que anticipamos realizar cambios con más frecuencia, continuaremos utilizando el código HTML5, ya que podemos enviar actualizaciones del lado del servidor sin requerir que las personas descarguen una nueva versión de la aplicación. .” Parece que Facebook está adoptando el mismo enfoque que se recomienda aquí: elija la tecnología para cada función en función del rendimiento, el esfuerzo de desarrollo requerido y la rapidez con la que debe sacarlo a la luz.

Para su aplicación, considere caso por caso si tiene más sentido crear una función de forma nativa o aprovechar el contenido web. Dada la dificultad de construir una navegación que se sienta nativa, probablemente tenga sentido al menos construirla usando componentes nativos.

Los bits de la web

Hoy en día, casi todo el mundo está de acuerdo en que es una buena idea mejorar progresivamente los sitios web : use una base de marcado para el mínimo común denominador de los navegadores y colóquela en capas con funcionalidades y mejoras usando JavaScript y CSS, según el contexto, sin bases de códigos ni plantillas separadas. para diferentes dispositivos requeridos. Al igual que no tiene sentido crear plantillas separadas para la web móvil y la de escritorio, queríamos usar las plantillas de sitios web en vivo dentro de la propia aplicación. La aplicación es solo otro contexto.

Llamo a este edificio sitios web receptivos "conscientes de aplicaciones" . Al crear nuestro sitio web teniendo en cuenta el contexto y el rendimiento de la aplicación, estaremos listos para enviar a todos nuestros usuarios a través de varias plataformas más temprano que tarde.

Los sitios web deben poder detectar el contexto de la aplicación en tres lugares: CSS, JavaScript y el servidor. Creamos una clase de app para escribir CSS condicional y un método isRunningInApp para escribir JavaScript condicional, y agregamos la App al agente de usuario para la lógica del lado del servidor condicional.

Un ejemplo de dónde usamos la mejora progresiva dentro de la aplicación es en nuestra página de visualización de productos. Lo optimizamos agregando un botón de posición fija "Agregar al carrito" solo para aplicaciones:

También podríamos haber agregado un botón de posición fija "Agregar a la bolsa" en el navegador, pero no lo hicimos porque, en Safari, al hacer clic cerca de la parte inferior se abrirá la barra de navegación de Safari. Tener esta barra abierta accidentalmente cuando el usuario intenta agregar un producto a su carrito sería una falla de usabilidad inaceptable, a pesar de las ventajas de tener un botón "Agregar al carrito" persistente en la parte inferior de la página:

Otra área en la que hicimos ajustes específicos de la aplicación en el sitio web es en el carrito de compras. La lógica del carrito suele ser uno de los aspectos más complicados de cualquier sitio web de comercio electrónico, y como estábamos bastante satisfechos con la experiencia del carrito en el móvil, decidimos reutilizarla en la aplicación, aunque con una apariencia ligeramente modificada:

Compartibilidad

La capacidad de compartir enlaces y abrir enlaces compartidos es una característica crítica que tiene que funcionar bien para Beyond the Rack. Queríamos que compartir fuera perfecto. Si alguien comparte un enlace desde su escritorio y su amigo lo abre en la aplicación, el enlace debe abrirse correctamente; asimismo, si alguien comparte un producto desde la aplicación, debe abrirse correctamente en el escritorio; y si el amigo está en el móvil pero no tiene la aplicación instalada, debería abrirse en el navegador. Estábamos decididos a hacer de esta una experiencia increíble porque esto suele ser algo en lo que las aplicaciones son débiles.

Hacer que el contenido se pueda compartir entre la web y la aplicación puede ser difícil . Para hacerlo con éxito, deberá mapear los enlaces de su aplicación y los enlaces web. Esto era doloroso en los días previos a la respuesta, cuando abrir una URL de escritorio lo llevaría a la página de inicio de una URL móvil, debido a redireccionamientos y demás. Estamos viendo exactamente el mismo problema hoy con las aplicaciones: los banners en Safari y Chrome le piden que abra un enlace en una aplicación, solo para que la aplicación no muestre lo que estaba buscando, dejándolo buscarlo de nuevo. Afortunadamente, manejar enlaces web en la aplicación de Beyond the Rack es muy sencillo, porque todo lo que tenemos que hacer es cargar esa URL en una vista web. Solo tenemos que asegurarnos de que los enlaces web lleven a los usuarios a la aplicación en lugar del navegador.

En Android, abrir una URL en una aplicación es simple. Solo necesita configurar un filtro de intención para cargar la aplicación cada vez que un usuario intente cargar la URL especificada (en nuestro caso, www.beyondtherack.com ). Una vez instalada la aplicación, los usuarios tendrán la opción de abrir la URL en la aplicación o en el navegador:

iOS ha tenido un camino un poco más difícil para permitir que las URL web se abran directamente en las aplicaciones. Anteriormente, iOS solo permitía registrar un esquema de aplicación para cada aplicación (por ejemplo, beyondtherack:// ). Debido a que era imposible saber qué aplicaciones estaban instaladas, la única opción era abrir un enlace determinado en Safari y, desde allí, intentar abrir ese enlace en la aplicación. Esto vino con una molestia menor: si la aplicación no estaba instalada, el usuario recibiría un mensaje de error molesto, "Safari no puede abrir la página porque la dirección no es válida". Afortunadamente, un truco te permite suprimir ese error usando iframes. Si desea admitir enlaces profundos en iOS 8, esta es la mejor opción.

Afortunadamente, iOS 9 introdujo la vinculación universal, que permite que las aplicaciones intercepten enlaces web antes de que pasen por Safari. ## Visibilidad La puntualidad es extremadamente importante para una empresa como Beyond the Rack. Tradicionalmente, la forma principal de la empresa de informar a los clientes sobre las ventas era a través de campañas de correo electrónico. Pero con las aplicaciones, puede **comunicarse directamente con sus clientes sobre las ventas**, lo cual es muy poderoso. (Por supuesto, las notificaciones push están llegando lentamente a los navegadores, con [Chrome a la cabeza](https://gauntface.com/blog/2014/12/15/push-notifications-service-worker). Pero para dispositivos Android más antiguos y para iOS, la elección de usar tecnología nativa o web ya estaba hecha para nosotros). Al igual que con el uso compartido, nuestra decisión de aprovechar el contenido web directamente en la aplicación hizo que configurar **notificaciones automáticas** fuera muy sencillo. Debido a que cada producto y venta se pueden identificar con la misma URL tanto en el sitio web como en la aplicación, educar a los especialistas en marketing sobre cómo enviar notificaciones a sus clientes es simple: todo lo que necesitan hacer es compartir las mismas URL que están acostumbrados a compartir. en campañas de correo electrónico. Una diferencia interesante entre iOS y Android es el **sistema de permisos** para las notificaciones automáticas. En iOS, el sistema operativo controla el permiso para las notificaciones, mientras que en Android no se necesita permiso. Aún así, sentimos que solicitar permiso era lo correcto desde la perspectiva del servicio al cliente. Entonces, cuando el usuario inicia sesión en la aplicación por primera vez, le preguntamos si desea recibir notificaciones:

También decidimos crear esos **cuadros de diálogo de notificación** con interfaces web. Nada sobre ellos requería un rendimiento avanzado, por lo que crearlos con interfaces de usuario web y reutilizarlos en todas las plataformas tenía sentido. Este es otro ejemplo de cómo hacer que el sitio web reconozca la aplicación: estos cuadros de diálogo son parte del sitio web, pero se muestran condicionalmente en la aplicación.

Resultados

Después del lanzamiento de la aplicación, queríamos comparar su rendimiento con la experiencia del navegador. Comparar directamente sus análisis no fue suficiente porque, según nuestra experiencia, cualquier persona que hubiera instalado la aplicación probablemente era un cliente más leal y, por lo tanto, probablemente convertiría mejor. Para evitar sesgos de selección, configuramos una prueba A/B; la mitad de los usuarios se mantuvieron en la aplicación y la otra mitad fueron expulsados ​​​​al navegador, lo que aseguró que los únicos participantes en el experimento fueran los usuarios que tenían la aplicación instalada (los usuarios más leales).

• Las transacciones por visitante único fueron un 76 % más altas con la experiencia de la aplicación que con la web.
• Los usuarios únicos diarios de la aplicación tenían un 20 % más de probabilidades de convertir .
• Los usuarios de la aplicación dedicaron un 63 % más de tiempo a navegar que los usuarios de la web .

Victorias de rendimiento rápido

Hacer una aplicación que cargue contenido web y se sienta nativa no sale de la caja en iOS o Android. Estos son algunos de los desafíos de rendimiento que enfrentamos y que vale la pena compartir:

• En iOS, el impulso de desplazamiento en una vista web no coincide con el impulso de desplazamiento en una vista de desplazamiento nativa. Esto se descubrió en las pruebas de usuario. Aquí hay una sola línea para resolver eso: webview.scrollView.decelerationRate = UIScrollViewDecelerationRateNormal;
• Tenga cuidado al cambiar el tamaño de las vistas web . Nos encontramos con problemas en los que cambiar su tamaño provocaba repintados completos, lo que acababa con el rendimiento del desplazamiento en dispositivos más antiguos.
• Tratar con cientos de implementaciones de vistas web diferentes en Android puede ser doloroso. El problema más doloroso con el que nos encontramos es un error conocido de vista web en Android 4.4.2, que arroja una excepción fatal en Chromium que hace que la aplicación se bloquee. Eliminar transform: translate3d en esa versión de Android parece funcionar. Alternativamente, puede usar Crosswalk para enviar su propio tiempo de ejecución web compilado con su aplicación (no lo hicimos, pero planeamos hacerlo para proyectos futuros).
• Use FastClick, no solo porque elimina el retraso de clic de 300 milisegundos, sino también porque corrige un error de clic de vista web introducido en iOS 8.4.1. Para nosotros, el error se manifestó al no permitir que la página cambiara si el clic era demasiado lento.
• Haz todo lo posible para que el desplazamiento se sienta increíble. Puede eliminar eventos de desplazamiento, evitar repintados innecesarios y más. Si el desplazamiento no se ejecuta a 60 cuadros por segundo, los usuarios lo notarán, incluso más en una aplicación que en la web.
• Haz todo lo que puedas para que las páginas se carguen en menos de 1000 milisegundos.

Herramientas para crear una aplicación aprovechando su sitio web

Tiene varias opciones para crear una aplicación que aproveche su sitio web existente. El enfoque que hemos tomado es crear la aplicación específica para cada plataforma (usando Xcode y Android Studio), aprovechando las vistas web o las vistas nativas cuando sea necesario.

Al cargar una vista web para una función en particular, recomendamos integrar la vista web de Cordova, en lugar de usar directamente las bibliotecas de vista web proporcionadas por iOS y Android. Esto le dará a sus vistas web una serie de funciones que de otro modo tendría que crear usted mismo, como un puente de web a nativo para comunicarse desde JavaScript a código nativo y viceversa, la capacidad de acceder a eventos del ciclo de vida, así como acceder a una gran cantidad de complementos de Cordova. Alternativamente, algunos otros puentes de web a nativos están disponibles para las diversas plataformas si desea evitar depender de Cordova.

Existen algunos marcos para ayudarlo a crear aplicaciones de esta manera, como Supersonic y Astro, un marco de aplicaciones nativo que estamos creando para que sea más fácil administrar la complejidad de crear aplicaciones usando interfaces nativas y web.

Conclusión

Con Beyond the Rack, nos propusimos crear una aplicación en la que pudiéramos enviar valor fácilmente a los usuarios sin sacrificar la experiencia. Al seguir un enfoque que pone la tecnología en un segundo plano , permitiéndonos usar la tecnología adecuada para la tarea, creemos que hemos logrado precisamente eso. Con cualquier cambio o introducción de una función, siempre nos preguntaremos: “¿Qué experiencia queremos diseñar aquí que resuelva mejor el problema del usuario? ¿Esa experiencia requiere el uso de animaciones o actuaciones avanzadas?”

La respuesta a esa pregunta determinará si creamos la función con tecnología web y la reutilizamos en el navegador y en Android e iOS o la creamos a medida para cada plataforma.

En última instancia, creo que así es como se deben construir las aplicaciones. Pero va a hacer falta un cambio de mentalidad. En lugar de tratar de determinar si la web triunfará sobre la nativa o se convertirá en una reliquia del pasado, debemos aprovechar lo mejor de ambas. Debemos reconocer sus respectivas ventajas y desventajas y utilizar la tecnología que tenga más sentido para la característica dada.