L’oeuf ou la poule?
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.
#1 by Jayce at May 15th, 2009
| Quote
La poule, c’est une évidence !
Pas de solution miracle, mais :
Pour avoir une communauté déjà présente dès le départ :
- Tu payes des téléphones fonctionnant sous Android à tes amis pour qu’ils créent une communité… ^^
- Tu attends qu’il y ait déjà un nombre élevé de téléphones compatibles en France avant de faire ton lancement, le plus buzzéen possible. Mais il faut aussi faire attention à ne pas se faire choper la place.
Tu pourrais aussi faire en sorte que le nombre de personne minimum pour que ton application soit intéressante soit la plus faible possible :
En croisant les durées “statiques” que tu aurais déjà (tous les trajets possibles …), ainsi que des indications rapides et simples provenant de tes utilisateurs : En 2 clicks, il signale qu’il est actuellement bloqué. Par déduction (géo ou temporelle ?) tu conclus que c’est la ligne X qui pose problème….
A moins que ce soit l’oeuf….
#2 by arnaudweb at May 15th, 2009
| Quote
Merci pour ton commentaire, le premier du blog
J’avais effectivement envisagé de faire une déduction automatique d’un problème sur la ligne en remarquant qu’un temps pour atteindre la station suivante était inhabituellement long mais j’ai laissé tomber car les informations recueillies dans les transports ne sont pas stables. On peut détecter un jour un passage à une station et la rater le lendemain. Ainsi, du point de vue du téléphone, ne pas détecter qu’on est passé par la station X ni X+1 ne signifie pas qu’on est bloqué dans un couloir. Cela peut juste être du à une mauvaise réception (éventuellement due à un changement de position dans le train).
Je ne peux donc pas me baser sur une absence de donnée pour détecter un blocage. Suite à cette réflexion j’avais laissé tomber l’idée d’une détection automatique d’incidents.
Mais en fait en lisant ton post et en y répondant, je me rend compte qu’il est possible de détecter non pas des blocages mais juste des ralentissements. Un blocage engendrera une absence de données supplémentaires alors qu’un ralentissement se base sur des données detectées et peut donc être notifié de façon fiable.