Web Your Daily Way

Constat d’Echec

Il m’arrive de temps à autre de relever la tête afin de regarder où j’en suis. C’est ce que j’ai fait hier soir et c’est un constat d’échec qui s’impose :

L’application ne sera pas prête dans les temps pour une participation au concours de google.

Le plus décevant est de voir l’état d’avancée actuel du projet par rapport au temps passé dessus.

J’avais pu atteindre quelque chose de presque démontrable pour le concours SFR. Cela n’est absoluement pas le cas pour le concours google. La partie serveur et backoffice ont pris énormément de retard. Aucun développement n’a été effectué sur la partie mobile.

A l’origine de ce constat d’echec, de mauvaises décisions prises en amont que je vais essayer d’analyser ici. Je me remonte le moral en me disant qu’un bon plantage correctement analysé vaut bien 10 réussites chanceuses.

J’ai inclu trop de nouvelles technologies

J’ai confondu projet avec un objectif précis et projet boite de pétri pour tester des technologies nouvelles qui m’attirent.

En soit, tout le projet WYDW est une boite de pétri pour tester et apprendre à développer sous android. Mais petit à petit, c’est également devenu un projet réel dans lequel je voyais un objectif de plus en plus précis. J’aurai donc du avoir une approche plus pragmatique.

J’avais eu  beaucoup de chances au cours de la première itération du projet (jusqu’au concours SFR). J’avais inclu plusieurs technologies que je connaissais pas avec beaucoup de succès (Android, et une connectivité au serveur très légère grace au design Rest). Le tout m’avait permis de développer une partie serveur très rapidement. Mise à part pour android et rest, j’étais dans les technologies que je manipule au quotidien et mon efficacité fut optimale.

Pour la seconde itération, j’ai voulu essayer d’utiliser la nouvelle infrastructure de serveurs proposée par Google : L’appEngine. Cette infrastructure possède l’énorme avantage de fournir gratuitement (jusqu’à un certain niveau) des serveurs java du même type que ceux utilisés par google. Cette infrastructure permet de répondre aussi facilement à 1 requete/seconde qu’à 10000 requête/seconde. Elle permet aussi d’avoir beaucoup moins d’arrêts de service que mon petit serveur loué sur dedibox. Son développement semblait également assez facile et son couplage très facile avec GWT (une technologie frontale très adaptée au backoffice que je souhaitais également utiliser) avait fini de me convaincre de l’utiliser.

Utiliser L’appEngine fut la plus grosse erreur du projet

Essayer l’appEngine était logique. Mais je n’aurai pas du insister face aux implications que l’utilisation de ce service imposait sur le projet. Cela m’a imposé de purement et simplement recommencer la partie serveur à zéro. Pire encore, j’ai plusieurs fois eu l’illusion de toucher au but avec des coeurs d’applications qui fonctionnaient mais au final une contrainte supplémentaire m’imposait de tout changer.

Quand j’ai finalement réussi, la semaine dernière, à avoir un backoffice prometteur qui fonctionnait sur ma machine de développement je me suis apperçu que cela ne fonctionnait pas sur les serveurs de google et ne pourrait pas fonctionner. J’ai du à nouveau tout changer.

J’ai le sentiment d’avoir passé mes dernières semaines à jongler avec les problématiques imposées par l’appEngine. C’est un peu comme d’essayer de recouvrir une grande table avec une nappe trop petite. Vous arrivez près d’un bord, vous tirez la nappe et ca découvre l’autre coté de la table. Vous en faites le tour, vous tirez la nappe et vous découvrez à nouveau l’autre coté. Après de nombreux essais, vous arrivez à tourner la nappe de façon à ce qu’elle recouvre toute la table. Mais au moment d’installer la nappe sur la vrai table, vous vous appercevez que la vrai table n’a pas la même forme que celle sur laquelle vous vous êtes essayé un certain nombre de fois.

Il y a quelques succès :

GWT fonctionne à merveille. Il me permet d’avoir un frontal web qui ressemble à une application executée par le système. Voici un exemple qui fonctionnait avec le code d’il y a quelque semaines (une contrainte supplémentaire a cassé le tout.) Cet exemple n’a rien d’impressionnant. Il s’agit juste de l’implémentation des mockup balsamiq dont je parlais dans un billet précedent. J’étais très enthousiaste après avoir réalisé cela car le code sous jacent à cet exemple est très simple à comprendre et possède beaucoup de potentiel. Je pensais arriver très rapidement à développer le reste. C’était faux car une contrainte n’ayant rien à voir avec la partie GWT m’a bloqué par la suite.

J’ai également pu découvrir gson, et dozer. Deux librairies que je ne présenterais pas ici mais qui m’ont agréablement surprises et qui sont un succès à garder.

Je n’ai pas mis assez d’effort dans le recrutement

Le billet sur le recrutement sur le site n’avait servit à rien. (en mm temps personne ne visite ce site ). J’en avais parlé sur twitter et mon post a été retwitté plusieurs fois. J’ai eu, suite à cette annonce, une vingtaines de visites inconnues sur le site. Pour recruter, j’ai surtout misé sur des gens de ma société de service (très portée sur les technos google) et j’ai effectivement eu une candidature interessée.

Après 3 semaines la personne n’avait toujours rien codé. Suite à une petite discussion il s’est avéré qu’elle preferait abandonner.

L’un des administateurs de Frandroid, un blog ayant plusieurs milliers de visites par jour, m’avais proposé de faire un post de recrutement sur frandroid. Je n’ai jamais saisi cette occasion et c’est un tord. J’aurai du.

De façon plus globale je me suis trop focalisé sur le développement et pas assez sur l’aspect managerial du projet.

Et maintenant ?

Même si le moral n’est pas vraiment là, je refuse de laisser partir en fumée tous les efforts que j’ai placés dans le développement de cette application. WYDW ne me rapportera toujours aucun copec, mais elle doit sortir pour que je puisse l’utiliser comme vitrine sur mon CV.

Coté développement, soit je continue à insister pour l’appEngine, soit je repasse sur mon ancien système et j’y ajoute GWT. Je pense que je vais choisir la deuxieme solution. Cela va engendrer des contraintes désagréables car GWT s’intègre assez mal à mon ancienne architecture, mais cela devrait avoir au moins l’avantage de fonctionner.

Changement de cap mon capitaine !

L’absence de spécifications commençait à se faire sentir avec WYDW.

J’étais donc prêt à me résoudre à sortir mon power point et à passer quelques heures avec des petites boites, des fleches et des zones de texte afin de pouvoir mettre en forme mes idées et avoir un objectif à atteindre. Pas toujours facile d’avoir quelque chose de précis et de compréhensible avec ce logiciel.

C’est là qu’est arrivé l’outil balsamiq. Spécialement fait pour créer des maquettes de sites, d’applications web et d’applications mobiles. J’ai pu mettre au point des maquettes stylisées de ce que je cherche à atteindre en quelques dizaines de minutes. L’outil est à utiliser en ligne, il est gratuit et à conseiller partout autour de vous.  (gratuit dans une version d’essai web qui possède déjà bcp de fonctionnalités)

Voici des maquettes réalisées avec Balsamiq décrivant l’organisation visuelle et comportementale de 2 pages du back-office de Web Your Daily Way. Ca me semble parlant…

Reste plus qu’à le coder…

Web Your Daily Way est une application qui vise à surveiller pour vous les transports que vous prenez au quotidien.

La localisation est une fonctionnalité centrale

Un certain nombre de ses fonctionnalités utilisent la localisation :

• Afin de savoir quand démarrer le suivi de votre trajet
• Afin de savoir quand stopper le suivi de votre trajet
• Tout le long de votre trajet, a chaque étape.

Il existe 2 types de localisations avec android : Le GPS et la network based localization. Le GPS consomme beaucoup d’énergie et est donc coupé la plupart du temps.  La network based localization se base sur une triangulation des cellules GPRS environnantes afin de déterminer votre localisation. Cette méthode est moins précise que le GPS mais même imprécise, elle a le mérite de pouvoir être disponible en permanence et même accessible depuis l’intérieur d’un bâtiment.

J’ai lancé le projet Web Your Daily Way sans avoir eu de retours sur la qualité de la réception et je m’attendais donc à ce que l’imprécision soit importante. Aucune faisabilité n’avais toutefois pu être faite pour la réalisation du prototype (actuellement fonctionnel).

Par ailleurs même si plus de la moitié de la population mondiale qui prend les transports en commun prend des bus, je souhaite que l’application fonctionne également dans les métro et les trains de banlieues (type RER)

Premiers tests de la network based localization

J’ai récemment reçu mon HTC Magic et j’ai commencé à tester la network based localization fournie par défaut avec le téléphone. Premier constat : Elle est effectivement très imprécise (même à l’exterieur).

Devant la gare de RER de Nogent sur marne, elle se trompe d’environ 300 mètres.

Une fois arrivé devant la station du métro 1 chateau de Vincenne, elle a une bonne précision et me positionne effectivement à quelques dizaines de mètres de ma position.

Une fois arrivé à mon travail, mon téléphone se trompe d’environ une rue soit une centaine de mètres. ce qui est tout à fait correct.

Le problème viens de l’intérieur du métro : Mon téléphone passe en Edge et me situe au niveau du centre du 11° arrondissement alors que je ne suis même pas dans paris. Une telle utilisation à l’intérieur du métro se révèle donc totalement inutile car la précision est de l’ordre de 3 ou 4 km…

La bonne nouvelle est qu’une fois sorti du train, il me situe avant même d’être sorti de la station au bon endroit (à 200 mètres près)

J’ai également testé le GPS depuis un bus. Ce dernier a une précision absolument diabolique de l’ordre de 5 mètres en périphérie du bois de Vincennes.

Conclusion de ce premier test

Il s’agit d’un test préliminaire peu éloquent car je n’ai testé que les environs de Paris et le métro sur seulement 2 stations. Je pousserai donc les tests plus loin

La précision de la network based localization du téléphone a été en dessous de mes espérances et remet sérieusement en cause le suivi de temps inter stations à l’intérieur du métro. Je vais aller tester d’autres stations mais si ce diagnostique se confirme il sera impossible de surveiller la vitesse du trajet à l’intérieur d’un couloir de métro (même en station, tant que la personne ne sors pas du train)

Les points du trajet ayant une localisation exploitable seraient alors :

• Les stations nécessitant de sortir du train (pour un changement de ligne)
• Les points de départ et d’arrivée avec une imprécision de l’ordre de 300 à 500 mètres (suivant l’urbanisation de la zone)

Toutefois un point est encourageant: le GPS est bien plus précis que prévu. La network Based Localization pourrait donc être utilisée pour piloter l’activation du GPS afin d’être précis sur l’heure d’entrée dans la station de départ et d’arrivée.

Une autre piste serait d’utiliser la localisation fournie par l’API SkyHook qui est annoncée être plus précise que la localisation par défaut de google.

Affaire à suivre…

Les précédents concours

Il y a un an, google lançait l’android developper challenge. Il s’agissait d’un concours de développement android auquel 1800 applications avaient été soumises pour 50 gagnants. les 50 avaient gagnés au cours d’un premier tous 25k$ puis, au cours d’un second tour 10 avaient empoché 275k$ et une autre dizaine 100k$.

SFR, début mai cloturait un concours de plus petite ampleur : 4 applications sur 100 soumises avaient gagnées 5k$, 10k$, 15k$ et 20k$. Web Your Daily Way avait participé sans gagner.

Un nouveau concours

Google a annoncé hier le lancement d’un nouveau concours dont les applications devront être développées pour mi aout.

Le principe est simple : il y a 10 themes, 3 gagnants par theme puis 3 gagnants au classement général.

Pour chaque catégories :

1° place : 100k$
2° place : 50k$
3° place : 25k$
puis au général (s’ajoute au prix gagné pour le classement par catégorie)
1° place : 150k$ soit au total 250k$
2° place : 50k$ soit jusqu’à 150k$ (s’il a gagné sa catégorie)
3° place : 25k$ soit jusqu’à 125k$ (s’il a gagné sa catégorie)

Les conditions de participations stipulent que seules des applications qui n’ont pas été rendues publiques pourront participer.

Cela permet d’éviter que des applications qui sont déjà développées et publiques depuis un bon bout de temps ne puissent concourir. Je me suis heurté, durant le concours SFR, à des applications extrêmement bien finies car elles avaient déjà été publiées et avaient donc déjà eu des retours utilisateurs.

Et Web Your Daily Way ?

Web Your Daily Way peut donc vraisemblablement faire parti du concours.

J’ai bien envie de me lancer dans l’aventure. Il sera toutefois nécessaire que je m’associe avec au moins une personne.

J’envisage même une équipe de 3 personnes :

_Une personne qui s’occupe de la partie web (GWT) et de la population des données (cf post precedent)
_Une personne qui s’occupe de la partie Android
_Une personne qui s’occupe de la partie serveur (maven2, Spring, Hibernate, Jersay/JSON. Il n’est toutefois pas encore trop tard pour prendre un virage à 90° et passer sur l’app-engine…)

S’il y a des postulants, merci de m’écrire à arnaudweb [at] webyourdailyway.com

La création de lignes est le point noir actuel de l’application. Il n’y a pour le moment en base qu’une branche du RER A, la ligne 1 et le T2. Je les ai rentrés à la main en utilisant des feuilles Excel mais il est nécessaire de développer un outil permettant de créer et d’éditer des lignes. Par ailleurs, comme je vise toute la France (dans un premier temps) il m’est impossible de rentrer les lignes entièrement par moi même.

Ancienne approche

Mon approche originelle était de dire : l’utilisateur rentrera lui même sa ligne. Mais arriver à rendre ergonomique cette fonctionnalité est un vrai casse tête. Créer une ligne doit prendre en compte les paramètres suivants :

• Il faut Géolocaliser chaque arrêt de façon précise
• Un arrêt est associé à une station. l’utilisateur ne fait pas la différence entre station et arrêt mais c’est pourtant bien différent. Un arrêt est associé à une seule ligne. une station peut contenir plusieurs arrêts de plusieurs lignes. (par exemple Chatelet-les-halles est une station composée de nombreux arrêts de différentes lignes. La ligne 4 possède même 2 arrêts associés à cette station ayant pour l’un le nom “chatelet” et pour l’autre le nom “les halles”)
  Le cas le plus généralement utilisé est pourtant que l’arrêt et la station soient confondus et qu’une station ne possède qu’un seul arrêt. 
• Le cas le plus simple est juste d’avoir une ligne composée d’une branche sur laquelle le moyen de transport fait l’aller retour. Il y a toutefois de nombreuses exceptions: La ligne peut se scinder en plusieurs branches, un trajet aller peut être différent du trajet retour (c’est très fréquent dans les bus qui passe par une rue à sens unique à l’aller et une autre rue à sens unique au retour). 
• Si on se base sur du communautaire, on s’expose à des erreurs et des sabotages. Il faut donc mettre en place un système de modération.

Mon approche d’il y a encore quelques jours était de chercher à créer cette fonctionnalité dans l’application. Or rentrer une ligne et ses arrêts sur un aussi petit écran de façon ergonomique et en gérant toutes les exceptions citées plus haut est un véritable casse tête.

Nouvelle approche

Suite à la soirée SFR, il m’a été soufflé une idée que j’avais éludé trop vite à l’époque de mes premières reflexions : 

Ne pas créer cette fonctionnalité dans l’application android et le faire en version WEB. En effet, sur un écran d’ordinateur, la gestion de toutes ces exceptions sera beaucoup plus facile.

Je vais donc retirer cette fonctionnalité de la première version de l’application et la créer en version WEB (en GWT vraissemblablement) 

Une fois cet outil web créé, j’aurai besoin de volontaires pour m’aider à remplir les différents réseaux des différentes villes de France. (des volontaires ?)

Autre approche

Utiliser un système d’insertion totalement automatisé en me basant sur des bases de données libres de droit.

Cette approche ne me permettra probablement jamais de tout couvrir d’un coup et nécessitera surement quelques ajustements avec l’outil web mais un préremplissage d’une grosse partie des données est une approche que je continue de creuser.

Je recherche à ce titre des gens qui pourraient m’indiquer où trouver de telles bases de données (API google??) Si vous avez des infos n’hésitez pas à commenter ce billet ou à m’écrire directement par mail.

Les fonctionnalités principales de l’application WYDW se basent sur l’aspect communautaire. Le concept actuel nécessite donc d’avoir une masse critique d’utilisateurs pour rendre ces fonctionnalités communautaires intéressantes.

Je me retrouve donc face à un dileme : Au démarrage de l’application, il n’y aura pas assez de monde pour que cette communauté soit présente. Or sans cette communauté, l’utilisateur risque de ne pas trouver l’application interessante.

Je suis à l’écoute de toute idée.

Voici les miennes :

Avoir une communauté déjà présente dès le départ

A l’aide de ce blog, de buzz au moment du lancement. Le concours SFR était un vecteur interessant mais le timing fait que ce vecteur sera froid au moment de la sortie de l’application.

Je suis à l’écoute de toute idée et d’aide sur ce point.

Par ailleurs, si vous lisez ce post, n’oubliez donc pas de vous abonner au flux RSS afin d’être tenu au courant et d’installer l’application sitôt celle ci sur la market place

Offrir des services ne necessitant pas de communauté d’utilisateurs

Afin de fidéliser les utilisateurs de lignes peu ou pas encore couvertes par la communauté, il serait interessant de leur fournir des services qui n’ont pas besoin de cette dite communauté.

• En fournissant des statistiques sur le temps mis par la personne
• En utilisatnt des webservices RATP/RTM ou autre afin d’avoir de façon non communautaire des informations clés sur la ligne
En partageant le trajet et les statistiques du trajet sur des réseaux sociaux. Par exemple en twittant automatiquement le temps de trajet mis lorsqu’il est anormalement lent ou anormalement rapide “Aujourd’hui, j’ai mis que 30 minutes (contre en moyenne 40 minutes) sur mon trajet Boulot” ou “Aujourd’hui j’ai mis 1h30 (contre en moyenne 40 minutes) sur mon trajet Boulot”

Simplifier l’utilisation

L’idée est de rendre l’utilisation la plus simple possible en diminuant au maximum la barrière de prise en main.

• En ayant un maximum de données déjà présentes au lancement. L’utilisateur n’aura donc pas à créer de ligne. elle sera déjà présente
• Travailler l’ergonomie de l’enregistrement du trajet. En utilisant notamment la géolocalisation et les cartes plutot que le nom de la station de départ.

Hier soir se tenait la soirée de cloture du concours SFR

A l’origine, ce concours m’avait donné l’impulsion pour démarrer le projet et j’étais convaincu que le concept de WYDW remporterait l’adhésion du jury. 

Cette soirée a donc réuni une grande partie des développeurs des 104 applications déposées pour le concours. Même si WYDW  n’a pas été retenue par les juges, elle a reçu beaucoup de soutien de la part des gens présents.

Cela fait chaud au coeur. Discuter et échanger avec les autres participants m’a permis de faire avancer ma reflexion sur plusieurs points qui viendront dans d’autres posts.

Web Your Daily Way est une application mobile vous permettant de surveiller votre trajet quotidien dans les transports en communs.

En cours de développement au moment où j’écris ce billet, l’application devrait sortir d’ici quelques semaines et apparaître sur la market place de google.

Principales fonctionnalités

Vous entrez une première fois le trajet que vous effectuez quotidiennement.

Suite à cela, lorsque vous vous approchez de votre station de départ ou le matin ou le soir, le téléphone va le détecter et se mettra à surveiller pour vous ce trajet.

• Durant tout le trajet, votre téléphone vous avertira si un incident a été déclaré sur une des lignes que vous vous apprêtez à prendre (dans votre sens d’utilisation de la ligne). Vous avez alors la possibilité d’avoir un suivi de l’incident et de discuter avec les gens concernés par cet incident.
• L’application vous permettra d’anticiper le temps mis sur votre trajet en se basant sur les statistiques envoyées par tous les utilisateurs de la ligne.
• L’application  vous permettra de surveiller le temps de trajet que vous mettez et avez mis au cours des jours précedent. Il enverra par ailleurs régulièrement (anonymement) ces données au serveur afin de les partager à la communauté d’utilisateurs.

Le système se mettra automatiquement en veille une fois arrivés à votre station finale.

Fonctionnalités secondaires

Lors de la création de votre trajet, il est possible qu’une des étapes ou une ligne ne soit pas encore présente dans le système. Vous avez alors la possibilité d’ajouter cette ligne et ainsi de la partager avec la communauté. Tout est basé sur le partage de l’information entre utilisateurs. 

L’application n’a pas vocation à l’origine à être un moteur de calcul de trajet. Toutefois, cela sera certainement une fonctionnalité secondaire future. Vous aurez alors la possibilité de calculer le trajet le plus court entre 2 points en prenant en compte le traffic et les ralentissement du réseau.

Histoire

Créée à l’origine sous l’impulsion du concours SFR. L’application n’a malheureusement rien gagné. Mais l’aventure ne s’arrête pas là et même si l’application n’est pas encore terminée, ce site blog a été mis en place afin de vous permettre de suivre l’évolution du projet et d’échanger avec moi sur sa création.

Stay Tuned

Arnaudweb