Refonte de l'application - Look intérieur



Mobius bike est un service de location de vélos et de scooters développé pour Tallinn (une expansion géographique est actuellement prévue).

La première hypothèse de sortie est «une application de location de vélos sera demandée sur le marché européen». En décembre 2019, l'hypothèse principale a été révisée et elle ressemblait maintenant à ceci: «le service de location de vélos et de scooters peut-il être maximisé en raison de la commodité pour l'utilisateur final et le franchisé?» Afin de répondre à cette question, il était nécessaire de mettre en œuvre les éléments suivants:

  • effectuer des travaux sur l'optimisation de la structure de l'application (à la fois interne - backend, et externe - design et frontend) pour introduire un nouveau type de transport et une mise à l'échelle possible à l'avenir
  • rendre les conditions de location réglables dans le panneau d'administration

Lyubov Nikiforuk - chef de projet




Écrans clés de l'application de vélo Mobius avant la refonte

L'une de mes premières tâches en tant que concepteur de produits a été de préparer des schémas pour l'introduction d'un nouveau type de transport - les scooters électriques. Après avoir terminé les mises en page, j'ai décidé d'apporter quelques modifications à la conception et aux applications UX et de faire un petit concept de refonte. A montré de nouvelles dispositions à l'équipe. J'ai eu un retour: les gars ont donné des conseils et partagé leurs opinions. En conséquence, un certain nombre d'écrans clés ont été tapés.

Le refactoring de code prévu sur deux mois approchait et nous avons décidé de montrer le nouveau design au client afin d'optimiser le code de la nouvelle interface, à moins, bien sûr, que le client n'accepte la refonte. Nous avons présenté des dispositions, expliqué comment une nouvelle conception peut simplifier l'interaction avec l'application et quels avantages elle apportera à l'entreprise. Et déjà en cours de présentation, nous avons réalisé que le design "allait". La refonte a été approuvée, et maintenant nous avons commencé à refactoriser avec une nouvelle interface et une UX repensée.



Variantes des écrans clés créés lors du processus de refonte

Organisation du travail


Étant donné que nous n'avions pas de tâche technique clairement définie et que notre service s'était développé en même temps que l'entreprise, nous devions décider comment nous réaliserions le travail: quelles tâches entreprendre en premier lieu, comment suivre les progrès et évaluer le résultat. Surtout, la méthode agile convenait à nos tâches. Nous avons déterminé la durée de chaque sprint en deux semaines. Chaque jour, nous avons tenu des stand-ups - discuté des problèmes actuels, partagé des idées, résolu des problèmes. À la fin de chaque sprint, une démonstration a été effectuée - montrant au client les résultats du travail effectué pour le sprint.



Agile dans toute sa splendeur



Test scooter dans nos bureaux

La navigation


La première chose que nous avons décidé de changer était la navigation dans l'application. Au lieu d'un «burger», nous avons créé un menu à onglets inférieurs (navigation du bas). Vous avez probablement remarqué que de nombreuses applications passent à ce type de navigation. Et cela est compréhensible, car le menu à onglets simplifie l'accès aux sections principales de l'application, même si une personne tient le téléphone d'une seule main. Mais ce n'est pas la seule raison d'utiliser ce type de navigation. L'application est développée sur React Native, nous avons donc dû considérer les fonctionnalités de cette plateforme:

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

— front-end




— «». — (bottom navigation)

, , UI-kit


En plus de changer la navigation, nous avons abandonné les contrôles d'échelle sur l'écran de l'application. A gauche le zoom avec des gestes. Remplacement des fenêtres modales, des boîtes de dialogue et d'une partie des écrans par des écrans de balayage. Encore une fois, car il est plus pratique d'utiliser l'application d'une seule main - un tel écran peut simplement être «glissé» vers le bas et fermé.



Exemples d'écrans de balayage dans l'application de vélo Mobius après la refonte

Nous avons également simplifié le processus d'inscription dans l'application en vous connectant via Google et Facebook. En plus de lier les cartes bancaires, ils ont ajouté la possibilité de payer en utilisant Apple Pay et Google Pay.



L'écran de connexion et le paiement à l'aide d'Apple Pay

Afin de faciliter l'ajout de nouvelles fonctionnalités à l'application à l'avenir, nous avons créé une bibliothèque de composants et décrit leur application et les principes d'interaction.



Applications du kit d'interface utilisateur de vélo Mobius

Refactorisation et passage à GraphQL


Les principaux objectifs de la refonte étaient:

  • créer un système de composants plus flexible et évolutif qui permettrait facilement d'ajouter de nouvelles fonctionnalités, par exemple, un autre type de transport, sans compromettre l'apparence et la logique générale d'interaction avec l'application
  • alléger et simplifier l'interface autant que possible
  • "Rafraîchir" l'apparence de l'application


Mais en plus de mettre à jour l'interface de l'application, le côté visible de la refonte, la transition de l'API RESTful à GraphQL était une partie très importante.

Pour le dire simplement, GraphQL est une syntaxe qui décrit comment un client (téléphone / application) reçoit des données d'un serveur à l'aide de requêtes spéciales. Selon la demande, le serveur donne telle ou telle donnée.

Artyom Bukhtoyarov - Développeur DevOps / Backend


GraphQL a trois caractéristiques principales:

  • permet au client de spécifier exactement les données dont il a besoin
  • facilite l'agrégation de données provenant de plusieurs sources
  • utilise un système de type pour décrire les données


GraphQL agit comme une couche d'adaptateur entre l'interface d'application et les services externes. Cela vous permet de transférer le traitement de nombreuses demandes différentes vers l'arrière. Autrement dit, lorsque vous connectez un nouveau protocole de transport, vous devrez le connecter à l'arrière, et la mise en page recevra toutes les données sous une forme unifiée de GraphQL. Ainsi, nous avons réduit le besoin de travaux de composition supplémentaires lors de l'ajout d'un nouveau type de transport et réduit le nombre de demandes traitées dans l'application.

De plus, dans le processus de refactoring, nous avons mis en évidence les avantages suivants de l'utilisation de GraphQL:

  • documentation pratique pour le développeur
  • une bonne solution pour WebSocket, à la fois pour le backend et le frontend
  • GraphQL facilite la navigation des développeurs dans la structure du code
  • un développement plus flexible, par rapport à l'API RESTful, vous permet d'ajouter quelque chose de nouveau plus rapidement et plus facilement (dans notre cas, il s'agit d'un nouveau type de transport)


C'était drôle quand le tout premier antivol pour vélo en provenance de Chine a déterminé sa géolocalisation en Chine, même s'il était physiquement à Saint-Pétersbourg. Et le logiciel de ce verrou était crypté et nous devions chercher une méthode de décryptage pour modifier les paramètres.

Initialement, lorsque nous n'avions qu'un seul type de transport, le serveur de connexion des vélos fonctionnait avec le backend principal. Ensuite, nous avons supprimé le serveur pour les antivols de vélo en tant que service indépendant qui peut être déployé sur des serveurs distincts - cela nous a permis de réduire la charge sur le serveur principal et a fourni des opportunités supplémentaires de mise à l'échelle. Pour transférer des messages entre services, nous utilisons RabbitMQ. Et c'était très pratique qu'il ait un plugin pour mqtt - le protocole sur lequel nos scooters fonctionnent, ce qui a facilité l'ajout d'un nouveau mode de transport.

Paiement dans l'application. Au départ, nous avions prévu d'ajouter des cartes bancaires dans l'application elle-même, mais finalement nous nous sommes installés sur une option de redirection vers la page de la banque et tout le processus d'ajout d'une carte s'y déroule déjà. Cette méthode s'est avérée beaucoup plus facile à mettre en œuvre.

Franchise et administration


Le propriétaire du service avait certaines exigences pour le panneau d'administration de l'application. Comme il est prévu que le service soit vendu en tant que franchise, chaque franchisé devrait être en mesure de modifier le coût du voyage, les paramètres tarifaires, les abonnements, etc.

Par conséquent, nous avons repensé le panneau d'administration pour pouvoir connecter de nouveaux propriétaires de parcs. Ajout de différents rôles - le propriétaire du parc et le propriétaire du réseau. Nous avons créé une section entière pour ajouter et modifier les tarifs, les abonnements et les amendes en fonction du temps. Dans chaque ville, le propriétaire du parc pourra fixer ses propres tarifs et les modifier. Ils ont également permis de modérer les modifications par l'administrateur réseau. Nous avons élargi la structure du panneau d'administration pour ajouter de nouveaux types de transport.

Problèmes


Bien sûr, il y a eu quelques difficultés. Depuis, nous avons refusé de visualiser l'itinéraire dans l'histoire des voyages. Le module GPS dans la serrure à vélo ne transmet pas toujours correctement les coordonnées. Et au lieu d'une belle ligne de route, comme sur un tir Dribble, nous avons obtenu ceci:



En attente de la réalité VS

Il y avait un problème dans la mise en œuvre technique de Google maps sous React Native. Le marqueur sur la carte doit être constamment redessiné afin de changer sa position sur la carte. Redessiner des graphiques vectoriels en grande quantité n'est pas optimisé et donc, avec certains paramètres, tout était très lent. Et nous avons décidé de remplacer les marqueurs vectoriels sur la carte par des marqueurs raster au format png. Cela a donné une augmentation significative de la vitesse de l'application.

De nombreuses questions concernaient la mise en œuvre du système tarifaire et l'abonnement. Nous avons essayé de fournir différents cas: que faire si l'abonnement se termine pendant le voyage, s'il faut donner la possibilité d'acheter différents abonnements pour un type de transport, s'il vaut la peine de faire un renouvellement automatique des abonnements, comment calculer le coût du voyage, etc.

En conséquence, nous avons opté pour l'option de notation suivante: le temps de trajet est divisé en segments inégaux et chaque intervalle de temps est facturé séparément. Par exemple, les 15 premières minutes du voyage coûtent 2 €, si vous roulez plus de 15 minutes, mais moins d'une demi-heure, le coût du voyage est de 3,5 €, de 30 minutes à une heure - 5 €, etc. Et pour permettre à l'utilisateur de naviguer plus facilement dans les tarifs, nous avons décidé de visualiser le calcul des coûts et d'en faire une barre de progression. L'utilisateur peut maintenant voir comment le coût du voyage change en temps réel.



Visualisation des coûts sous forme de barre de progression



Écrans avec tarifs et abonnements

Certains utilisateurs ont trouvé l'option de ne pas payer le voyage: ils ont ajouté une carte bancaire, puis l'ont supprimée et sont partis gratuitement. Lorsque nous avons trouvé cela, nous avons commencé à bloquer 1 € pour vérifier notre solvabilité et supprimé la possibilité de retirer la carte pendant le voyage ou s'il y a une dette impayée.

Parfois aussi, il y avait des problèmes pour terminer le voyage. Pour terminer la balade à vélo, vous devez fermer la serrure, qui transfère les informations au serveur. Mais le château n'a pas toujours transmis les données à temps. Et au final, les gens pourraient accumuler des dettes de plusieurs centaines d'euros pour des voyages prétendument inachevés. Nous avons décidé de vérifier manuellement de grandes quantités et de supprimer l'enregistrement automatique pour eux. Il n'y a eu pratiquement aucune plainte, car en Europe, peu de gens ont des alertes par SMS. En Russie, ce serait différent.

résultats


L'extrémité avant


L'une des principales caractéristiques du développement sur React Native est le suivi des performances des composants. Pour éviter une diminution des fps, il vaut la peine:
  • surveiller le nombre de rendus (redessins). Un composant ne doit être redessiné que si les nouvelles données qui y entrent ont vraiment besoin de changer l'état de l'interface
  • utiliser une animation animée native du package React Native standard en utilisant la clé useNativeDrive dans la configuration d'animation ou le package réanimé
  • examiner le code JS des packages ou des composants ajoutés au projet. Tous les packages disponibles ne peuvent pas être optimisés ou utiliser correctement les fonctionnalités de React Native. Également en développement sur React Native, il convient de prendre en compte les différences de plates-formes. Un même code sur iOS et Android peut fonctionner de manière complètement différente

La force de React Native peut être appelée sa polyvalence. Pas besoin d'avoir 2 équipes de développement différentes sur iOS et Android. De plus, vous pouvez souvent implémenter des concepts de conception plus difficiles à développer sur des plates-formes natives.

La faiblesse de React Native n'est pas sa pleine nativité. Vous devez constamment vous assurer de ne pas surcharger le thread JS. La douleur de la mise à jour et de l'installation de packages natifs jusqu'à la version 0.60 jusqu'à l'introduction du lien automatique.

Backend


Le passage à GraphQL dans la plupart des cas a simplifié le développement de l'API. Il est devenu plus clair pour le développeur et le client.

Avantages GraphQL:
  • il est possible de documenter automatiquement l'API et c'est très pratique
  • permet un travail plus flexible avec l'API. Le client ne sélectionne que les données dont il a besoin pour le moment
  • prise en charge prête à l'emploi pour les sockets Web, ce qui était très important car nous mettons souvent à jour les données en temps réel
  • nous pouvons facilement écrire des types scalaires si nécessaire et les réutiliser plus tard


Faiblesses GraphQL:
  • plus difficile à faire des fonctionnalités par type de pagination. Je dois appliquer des technologies supplémentaires
  • Hors de la boîte, il n'y a pas d'espace de noms. Vous devez vous occuper de la séparation de l'API. Dans le même temps, les champs obsolètes sont pris en charge, ce qui simplifie encore la vie du développeur
  • vous devez surveiller les niveaux d'imbrication des requêtes. Vous pouvez écrire une demande avec beaucoup d'imbrication puis attendre longtemps une réponse


Interface


Lorsque vous travaillez sur une refonte, vous devez vous rappeler que vous ne devez pas faire de conception dans un souci de conception. Dans notre cas, la nouvelle interface a permis de simplifier l'interaction de l'utilisateur avec l'application, y compris si une personne tient le téléphone d'une seule main. Nous avons pris en compte les fonctionnalités de React Native et, afin de réduire l'imbrication, nous sommes passés d'un «burger» à une navigation par le bas. Il est également nécessaire de définir la capacité de mettre à l'échelle la structure de l'application. La création d'une bibliothèque de composants et l'application de la conception atomique peuvent aider ici.

Nous prévoyons d'introduire la gamification (obtenir de beaux bonus pour les kilomètres parcourus), un thème sombre, la connexion aux contacts téléphoniques et la notification aux amis voyageant à proximité et l'introduction de nouveaux modes de transport. Mais le plus important, la refonte doit être justifiée: au profit de l'entreprise et simplifier le travail avec l'application pour l'utilisateur.

All Articles