deliver.ee est une start-up parisienne dont le but est de rendre les livraisons aussi simples et rapides que possible. Ils permettent aux entreprises de réaliser des livraisons intra-urbaines le jour même, et le service est également accessible aux particuliers. La logistique des transporteurs est totalement gérée par deliver.ee.
Le produit fonctionne autour d'un service central, une API réalisée avec Ruby on Rails, et plusieurs applications web. Début septembre 2014, Sébastien (directeur technique de deliver.ee) recherchait quelqu'un pour l'aider à finir certaines de ces applications avant une deadline importante.
Trois applications étaient concernées, toutes réalisées avec ember.js. J'ai commencé a travailler sur le projet sous la guidance d'un autre développeur, et suis passé développeur principal une fois qu'il n'était plus disponible.
Pro
"Pro" est l'application utilisée par les entreprises pour commander des livraisons et suivre leurs progression. Un fois connectés à l'interface, les utilisateurs arrivent sur un tableau de bord où ils ont accès en un coup d'oeil à plusieurs statistiques utiles ainsi qu'aux dernières mises à jours de leurs "missions". Une mission est une demande de livraison, et évolue au fil du temps de "en attente" (la demande vient d'être effectuée) à "livrée" (le client a reçu son/ses colis).
La page principale de l'application est celle où les utilisateurs peuvent commander une mission. Cette page nécessitait de comporter toutes les fonctionnalités attendues d'un tel système tout en restant claire et concise, ce qui n'était pas toujours tâche facile.
Au final, nous sommes partis sur une logique de "blocs" pour délimiter les contenus, une logique qui sera réutilisée dans les autres applications. Tout en haut se trouvent les sections permettant de renseigner les adresses de départ et d'arrivée. Les utilisateurs peuvent soit entrer une adresse à la main, soit en choisir une précédente, ou bien en prendre une du carnet d'adresse ou d'entrepots. C'est aussi ici que se configurent la sécurisation du retrait et de la livraison et que le service vous notifie si la zone demandée n'est pas couverte.
Ensuite les utilisateurs peuvent choisir le délai de livraison, une date et une heure, ou bien un créneau prédéfini. Puis vient la sélection du type de véhicule et le renseignement du/des colis qui doivent être livrés, une seule de ces deux sections étant requise. Enfin, les utilisateurs peuvent préciser un numéro de référence interne et comment ils souhaitent être notifiés du suivi de cette mission.
Le reste de l'application permet principalement de suivre les missions et de gérer les différentes resources: les utilisateurs, leurs droits, les adresses/entrepots, les notifications et autres paramètres, ...
Cette application est disponible en anglais et français, et d'autres langues peuvent facilement être ajoutée. Les permissions sont finements gérées, aussi bien celles des utilisateurs que des entreprises au travers des quotas de missions.
Cockpit
"Cockpit" est l'application utilisée par l'équipe de deliver.ee pour consulter et gérer à peu près tout: missions, utilisateurs, entreprises, transporteurs, etc.
Tout peut être réalisé au travers du cockpit. L'équipe peut suivre et faire évoluer les commandes, y compris assigner un transporteur à la main si nécessaire, et même commander une mission pour le compte d'une entreprise au cas où elle ne peut le faire elle même.
Cockpit et Pro ont beaucoup de sections et d'écrans similaires, avec comme seules différences la gestion des permissions et des points esthétiques. C'est pourquoi dès le départ j'ai organisé les projets de façon à ce que le maximum d'éléments puissent être partagés entre les applications pour en faciliter la maintenance, plutot que d'avoir à effectuer la même modification à deux ou trois endroits différents.
Carrier
"Carrier" est l'application utilisée par les transporteurs pour recevoir, suivre, et mettre à jour les demandes de livraison. Cette application est optimisées pour les terminaux mobiles, notamment les smartphones. Elle n'est pas aussi remplie en fonctionnalités que les deux précédentes, mais contient des éléments bien spécifiques.
Les transporteurs peuvent consulter trois listes de missions: celles qu'ils sont autorisés à gérer, celles qu'ils gèrent actuellement, et celles qui leurs ont été directement assignées. Ils peuvent accepter et refuser ces dernières.
Une fois une mission acceptée, ils ont accès aux informations nécessaires pour passer à l'étape suivante: l'adresse et une carte indiquant où ils doivebt récupérer le colis, pour commencer, puis celles du client à livrer. La personne en charge de leur remettre le colis doit signer (sur le téléphone) pour valider la remise. Il en est de même pour le client qui reçoit son colis qui doit également signer afin d'accuser la réception.
Chaque action a un impact sur l'état de la mission, qui peut très bien être échouée (client absent), refusée (le client ne veut pas récupérer le colis), ou re-programmée plus tard. Etant donné que les erreurs arrivent assez facilement sur un écran tactile, les transporteurs disposent de 5 secondes après chaque action pour l'annuler.
Au bout de quelques semaines d'efforts la deadline fut respectée, et mon implication par la suite a consisté à maintenir les applications, intégrer quelques nouvelles fonctionnalités, corriger certains comportements non désirés, et aider Sébastien à prendre ses repères avec Ember.js et les différentes bases de code. Les projets étaient très intéressants et l'équipe très agréable à travailler avec. Je ne leur souhaite que du succès pour leur futur.
Besoin d'aide sur un projet Ember.js ?
- Durée: de septembre 2014 à february 2015
- Langages/outils: ember.js, ember-cli, node.js, ruby on rails
-
Quelques missions:
- Conversion d'une application ember de ember-appkit à ember-cli
- Partage de code via un addon privé ember-cli
- Internationalisation/localisation d'une interface
- Transmission des connaissances/mentoring de l'équipe