Rediseño de aplicaciones - Mirada interior



Mobius bike es un servicio de alquiler de bicicletas y scooters desarrollado para Tallin (actualmente se planea la expansión geográfica).

La primera hipótesis de lanzamiento es "una aplicación de alquiler de bicicletas tendrá demanda en el mercado europeo". En diciembre de 2019, se revisó la hipótesis principal y ahora sonaba así: "¿se puede maximizar el servicio de alquiler de bicicletas y scooters debido a la conveniencia para el usuario final y el franquiciado?" Para responder a esta pregunta, fue necesario implementar lo siguiente:

  • llevar a cabo un trabajo para optimizar la estructura de la aplicación (tanto interna como backend y externa - diseño y frontend) para introducir un nuevo tipo de transporte y una posible ampliación en el futuro
  • hacer que las condiciones de alquiler sean ajustables en el panel de administración

Lyubov Nikiforuk - gerente de proyecto




Pantallas clave de la aplicación de bicicletas Mobius antes del rediseño

Una de mis primeras tareas como diseñador de productos fue preparar diseños para introducir un nuevo tipo de transporte: los scooters eléctricos. Después de terminar con los diseños, decidí hacer algunos cambios en el diseño y las aplicaciones UX y hacer un pequeño concepto de rediseño. Mostró nuevos diseños para el equipo. Recibí un comentario: los chicos dieron consejos y compartieron sus opiniones. Como resultado, se escribieron varias pantallas clave.

La refactorización del código planificada para dos meses se acercaba y decidimos mostrar el nuevo diseño al cliente para optimizar el código para la nueva interfaz, a menos que, por supuesto, el cliente esté de acuerdo con el rediseño. Presentamos diseños, explicamos cómo un nuevo diseño puede simplificar la interacción con la aplicación y qué beneficios traerá al negocio. Y ya en el proceso de presentación, nos dimos cuenta de que el diseño "se fue". El rediseño fue aprobado, y ahora comenzamos a refactorizar con una nueva interfaz y UX rediseñado.



Variantes de las pantallas clave que se crearon durante el proceso de rediseño

Organización de trabajo


Como no teníamos una tarea técnica claramente definida y nuestro servicio se desarrolló junto con el negocio, tuvimos que decidir cómo llevaríamos a cabo el trabajo: qué tareas tomar en primer lugar, cómo rastrear el progreso y evaluar el resultado. Sobre todo, el método ágil se adaptaba a nuestras tareas. La duración de cada sprint la determinamos en dos semanas. Todos los días realizamos stand-ups: discutimos problemas actuales, compartimos ideas, resolvimos problemas. Al final de cada sprint, se realizó una demostración: mostraban al cliente los resultados del trabajo realizado para el sprint.



Ágil en todo su esplendor



Prueba scooter en nuestra oficina

Navegación


Lo primero que decidimos cambiar fue la navegación por la aplicación. En lugar de una "hamburguesa", creamos un menú de pestaña inferior (navegación inferior). Probablemente haya notado que muchas aplicaciones están cambiando a este tipo de navegación. Y esto es comprensible, ya que el menú de pestañas simplifica el acceso a las secciones principales de la aplicación, incluso si una persona sostiene el teléfono con una mano. Pero esta no es la única razón para usar este tipo de navegación. La aplicación está desarrollada en React Native, por lo que tuvimos que considerar las características de esta plataforma:

(). , , , , , , . . . ,

— front-end




— «». — (bottom navigation)

, , UI-kit


Además de cambiar la navegación, abandonamos los controles de escala en la pantalla de la aplicación. Dejó el zoom con gestos. Reemplazó ventanas modales, cuadros de diálogo y parte de las pantallas con pantallas deslizantes. Una vez más, debido a que es más conveniente usar la aplicación con una mano, dicha pantalla simplemente puede "deslizarse" hacia abajo y cerrarse.



Ejemplos de pantallas deslizables hacia arriba en la aplicación de bicicleta Mobius después del rediseño

También simplificamos el proceso de registro en la aplicación al iniciar sesión a través de Google y Facebook. Además de vincular tarjetas bancarias, agregaron la posibilidad de pagar con Apple Pay y Google Pay.



La pantalla para ingresar la aplicación y el pago con Apple Pay

Para facilitar la adición de nuevas funciones a la aplicación en el futuro, creamos una biblioteca de componentes y describimos su aplicación y principios de interacción.



Aplicaciones de kit de interfaz de usuario de bicicleta Mobius

Refactorización y cambio a GraphQL


Los objetivos principales del rediseño fueron:

  • crear un sistema de componentes más flexible y escalable que permita agregar fácilmente nuevas funcionalidades, por ejemplo, otro tipo de transporte, sin comprometer la apariencia y la lógica general de interacción con la aplicación
  • aligerar y simplificar la interfaz tanto como sea posible
  • "Actualizar" la apariencia de la aplicación


Pero además de actualizar la interfaz de la aplicación, el lado visible del rediseño, la transición de la API RESTful a GraphQL fue una parte muy importante.

En pocas palabras, GraphQL es una sintaxis que describe cómo un cliente (teléfono / aplicación) recibe datos de un servidor mediante consultas especiales. Dependiendo de la solicitud, el servidor proporciona esta o aquella información.

Artyom Bukhtoyarov - Desarrollador DevOps / Backend


GraphQL tiene tres características principales:

  • permite al cliente especificar exactamente qué datos necesita
  • facilita la agregación de datos de múltiples fuentes
  • usa un sistema de tipos para describir datos


GraphQL actúa como una capa adaptadora entre la interfaz de la aplicación y los servicios externos. Esto le permite transferir el procesamiento de muchas solicitudes diferentes a la parte posterior. Es decir, cuando conecta un nuevo protocolo de transporte, deberá conectarlo en la parte posterior, y el diseño recibirá todos los datos en forma unificada de GraphQL. Por lo tanto, redujimos la necesidad de trabajo de composición adicional al agregar un nuevo tipo de transporte y redujimos el número de solicitudes procesadas en la aplicación.

Además, en el proceso de refactorización, destacamos las siguientes ventajas de usar GraphQL:

  • documentación conveniente para el desarrollador
  • Una buena solución para WebSocket, tanto para el backend como para la interfaz
  • GraphQL facilita a los desarrolladores navegar la estructura del código
  • Un desarrollo más flexible, en comparación con la API RESTful, le permite agregar algo nuevo más rápido y más fácil (en nuestro caso, este es un nuevo tipo de transporte)


Fue divertido cuando el primer candado para bicicletas de China determinó su ubicación geográfica en China, aunque fue físicamente en San Petersburgo. Y el software para este bloqueo estaba cifrado y tuvimos que buscar un método de descifrado para realizar cambios en la configuración.

Inicialmente, cuando solo teníamos un tipo de transporte, el servidor para conectar bicicletas funcionaba junto con el backend principal. Luego, sacamos el servidor para cerraduras de bicicleta como un servicio independiente que se puede implementar en servidores separados; esto nos permitió reducir la carga en el servidor principal y proporcionó oportunidades adicionales para escalar. Para transferir mensajes entre servicios, utilizamos RabbitMQ. Y fue muy conveniente que tenga un complemento para mqtt, el protocolo en el que trabajan nuestros scooters, que facilitó la adición de un nuevo modo de transporte.

Pago en la aplicación. Inicialmente, planeamos agregar tarjetas bancarias en la aplicación en sí, pero al final nos decidimos por una opción de redireccionamiento a la página del banco y todo el proceso de agregar una tarjeta ya está teniendo lugar allí. Este método resultó ser mucho más fácil de implementar.

Franquicia y Administración


El propietario del servicio tenía ciertos requisitos para el panel de administración de la aplicación. Dado que está previsto que el servicio se venda como una franquicia, cada franquiciado debería poder editar el costo del viaje, los parámetros de tarifas, las suscripciones, etc.

Por lo tanto, rediseñamos el panel de administración para poder conectar nuevos propietarios de parques. Se agregaron diferentes roles: el propietario del parque y el propietario de la red. Hicimos una sección completa para agregar y editar tarifas, suscripciones y multas basadas en el tiempo. En cada ciudad, el propietario del parque podrá establecer sus propias tarifas y cambiarlas. También permitieron moderar los cambios por parte del administrador de la red. Ampliamos la estructura del panel de administración para agregar nuevos tipos de transporte.

Problemas


Por supuesto, hubo algunas dificultades. Nos negamos a visualizar la ruta en la historia de los viajes, desde entonces. El módulo GPS en la cerradura de la bicicleta no siempre transmite correctamente las coordenadas. Y en lugar de una hermosa línea de ruta, como en un tiro de Dribble, obtuvimos esto:



Esperando a la realidad VS

Hubo un problema en la implementación técnica de los mapas de Google en React Native. El marcador en el mapa necesita ser redibujado constantemente para cambiar su posición en el mapa. Volver a dibujar gráficos vectoriales en grandes cantidades no está optimizado y, por lo tanto, con ciertas configuraciones, todo fue muy lento. Y decidimos reemplazar los marcadores de vectores en el mapa con marcadores de trama en formato png. Esto dio un aumento significativo en la velocidad de la aplicación.

Muchas preguntas estaban relacionadas con la implementación del sistema tarifario y la suscripción. Intentamos proporcionar diferentes casos: qué hacer si la suscripción finaliza durante el viaje, si dar la oportunidad de comprar diferentes suscripciones para un tipo de transporte, si vale la pena hacer una renovación automática de las suscripciones, cómo calcular el costo del viaje, etc.

Como resultado, nos decidimos por la siguiente opción de calificación: el tiempo de viaje se divide en segmentos desiguales y cada intervalo de tiempo se cobra por separado. Por ejemplo, los primeros 15 minutos del viaje cuestan 2 €, si viajas durante más de 15 minutos, pero menos de media hora, el costo del viaje es de 3,5 €, de 30 minutos a una hora, 5 €, etc. Y para que sea más fácil para el usuario navegar por las tarifas, decidimos visualizar el cálculo de costos y lo convertimos en una barra de progreso. Ahora el usuario puede ver cómo cambia el costo del viaje en tiempo real.



Visualización de costos en forma de barra de progreso



Pantallas con tarifas y suscripciones

Algunos usuarios encontraron la opción de no pagar el viaje: agregaron una tarjeta bancaria, luego la eliminaron y viajaron gratis. Cuando descubrimos esto, comenzamos a bloquear € 1 para verificar nuestra solvencia y eliminamos la capacidad de retirar la tarjeta durante el viaje o si hay una deuda impaga.

También a veces hubo problemas para completar el viaje. Para completar el paseo en bicicleta, debe cerrar la cerradura, que transfiere información al servidor. Pero el castillo no siempre transmitía datos a tiempo. Y al final, la gente podría acumular una deuda de varios cientos de euros por viajes supuestamente sin terminar. Decidimos que verificaríamos grandes cantidades manualmente y eliminamos la grabación automática para ellos. Casi no hubo quejas, ya que en Europa pocas personas tienen alertas por SMS. En Rusia sería diferente.

recomendaciones


Interfaz


Una de las principales características del desarrollo en React Native es el seguimiento del rendimiento de los componentes. Para evitar una disminución de fps, vale la pena:
  • supervisar el número de renderizadores (redibujos). Un componente debe redibujarse solo si los nuevos datos que ingresan realmente necesitan cambiar el estado de la interfaz
  • use animación animada nativa del paquete React Native estándar usando la tecla useNativeDrive en la configuración de animación o el paquete Reanimado
  • revise el código JS de paquetes o componentes agregados al proyecto. No todos los paquetes disponibles se pueden optimizar o utilizar correctamente las características de React Native. También en desarrollo en React Native vale la pena considerar las diferencias de plataformas. El mismo código en iOS y Android puede funcionar de maneras completamente diferentes

La fuerza de React Native se puede llamar su versatilidad. No es necesario tener 2 equipos de desarrollo diferentes en iOS y Android. Además, a menudo, puede implementar conceptos de diseño que son más difíciles de desarrollar en plataformas nativas.

La debilidad de React Native no es su natividad completa. Debe asegurarse constantemente de no sobrecargar JS-thread. El dolor de actualizar e instalar paquetes nativos hasta la versión 0.60 hasta que se introdujo el autolinker.

Backend


Cambiar a GraphQL en la mayoría de los casos simplificó el desarrollo de la API. Se ha vuelto más claro tanto para el desarrollador como para el cliente.

Ventajas de GraphQL:
  • es posible documentar automáticamente la API y es muy conveniente
  • permite un trabajo más flexible con la API. El cliente selecciona solo los datos que necesita en este momento
  • Soporte inmediato para sockets web, lo cual fue muy importante ya que a menudo actualizamos datos en tiempo real
  • podemos escribir fácilmente tipos escalares si es necesario y reutilizarlos más tarde


Debilidades de GraphQL:
  • características más difíciles de hacer por tipo de paginación. Tengo que aplicar tecnologías adicionales.
  • Fuera de la caja no hay espacio de nombres. Debes ocuparte de la separación de la API tú mismo. Al mismo tiempo, hay soporte para campos en desuso, lo que simplifica aún más la vida del desarrollador.
  • necesita monitorear los niveles de anidamiento para consultas. Puede escribir una solicitud con una gran cantidad de anidamiento y luego esperar mucho tiempo para obtener una respuesta


Interfaz


Al trabajar en un rediseño, debe recordar que no debe diseñar por el diseño. En nuestro caso, la nueva interfaz permitió simplificar la interacción del usuario con la aplicación, incluso si una persona sostiene el teléfono con una mano. Tomamos en cuenta las características de React Native y, para reducir el anidamiento, cambiamos de una "hamburguesa" a una navegación inferior. También es necesario establecer la posibilidad de escalar la estructura de la aplicación. Crear una biblioteca de componentes y aplicar diseño atómico puede ayudar aquí.

Tenemos la intención de introducir la gamificación (obtener bonificaciones bonitas por kilómetros recorridos), un tema oscuro, que se conecta a los contactos telefónicos y notifica a los amigos que viajan cerca e introduce nuevos modos de transporte. Pero lo más importante, el rediseño debe estar justificado: beneficiar al negocio y simplificar el trabajo con la aplicación para el usuario.

All Articles