Présentation du talk de Nicolas Laurent et Frédéric Millard à La Duck Conf 2018.
Qu'est-ce qui pousse majoritairement les utilisateurs à désinstaller - ou ne pas utiliser - leurs applications mobiles ? Un mauvais service, ce qui se traduit souvent par une UX déceptive ainsi que des mauvaises performances.
L'un des facteurs clé de succès, ou d'échec, de votre stratégie mobile est votre API.
Mais quelles sont les clés pour faire un bon design d'API orientée mobile ? Quels sont les points principaux pour bien s'intégrer au SI ? Comment optimiser sans tout casser ? Venez découvrir nos recettes et nos conseils.
3. 72% des désinstalls liées à
des problèmes de perf
25% d’utilisateurs perdus
au delà de 4 secondes
40% au delà de 10
secondes
Sur 30 à 40 apps en
moyenne, seulement 10
sont utilisées
77% des nouvelles apps
installées ne sont pas
utilisées plus de 3 jours
26% sont
désinstallées
au premier
lancement
Près de
3 millions
d’apps
EXIGENCEUTILISATEURS
COMPÉTITION
8. Les 4 APIs disponibles :
● Vérification de la non existence d’un utilisateur en base
● Validation du couple de mot de passe
● Création du compte
● Connexion
Nom
Prénom
Email
NEXT
Mot de passe
Répétez mot de passe
NEXT
Félicitations Bob !
LOGIN
Email
Mot de passe
NEXT
Bonjour Bob !
Action 1
Action 2
Exemple : Tunnel d’enrôlement API driven
Vérification du user Validation mot de passe
Création du compte
Connexion
9. Nom
Prénom
Email
Mot de passe
NEXT
Félicitations Bob !
Action 1
Action 2
Exemple : Tunnel d’enrôlement UX driven
Création du user
1 seule API POST /api/users qui réalise :
1. La vérification des données,
2. La création de compte
3. Le login
Requête
POST /api/users
{
name: 'bob',
firstname: 'mauranne',
email: 'bob@maurane.fr',
password: 'duck@conf'
}
Réponse
201 Created
+ token d’authentification en header http
11. Exemple : Afficher une liste de contacts
Depuis un référentiel d’organisation interne
● Nom, prénom, photo
● Date d’entrée dans la société
● Intitulé du poste, niveau, type de contrat
● Équipe de rattachement, manager, collaborateurs
● Pays, site géographique
● Coordonnées : email, téléphones
● Compétences
● Projets en cours et passés
Prénom Nom, job
Equipe
Nom du manager
Photo
12. Exemple : Afficher une liste de contacts
{
id: '654'
name: 'Lebowsky',
firstname: 'Jeffrey',
picture: 'http://pics.com/jeff.png',
entry_date: '2013-04-22T06:00:00Z',
site: '23',
country: 'California'
email: 'bob.mauranne@duckcorp.com',
mobile_phone_number: '0605030402',
landline_phone_number: '0102030405',
team: '2344',
manager: '231',
managed: ['476', '378', '666'],
job: 'Senior architect',
job_type: 'permanent',
skills: {...}, projects: {...}
}
Jeffrey LEBOWSKY, Senior architect
Central office
Helen RIPLEY
13. Exemple : Afficher une liste de contacts
{
id: '654'
name: 'Lebowsky',
firstname: 'Jeffrey',
picture: 'http://pics.com/jeff.png',
entry_date: '2013-04-22T06:00:00Z',
site: '23',
country: 'California'
email: 'bob.mauranne@duckcorp.com',
mobile_phone_number: '0605030402',
landline_phone_number: '0102030405',
team: '2344',
manager: '231',
managed: ['476', '378', '666'],
job: 'Senior architect',
job_type: 'permanent',
skills: {...}, projects: {...}
}
Jeffrey LEBOWSKY, Senior architect
Central office
Helen RIPLEY
14. Exemple : Afficher une liste de contacts
Jeffrey LEBOWSKY, Senior architect
Central office
Helen RIPLEY
{
id: '654'
name: 'Lebowsky',
firstname: 'Jeffrey',
picture: 'http://pics.com/jeff.png',
entry_date: '2013-04-22T06:00:00Z',
site: '23',
country: 'California'
email: 'bob.mauranne@duckcorp.com',
mobile_phone_number: '0605030402',
landline_phone_number: '0102030405',
team: '2344',
manager: '231',
managed: ['476', '378', '666'],
job: 'Senior architect',
job_type: 'permanent',
skills: {...}, projects: {...}
}
17. Exemple : Afficher une liste de contacts
{
id: '654'
name: 'Lebowsky',
first_name: 'Jeffrey',
picture: 'http://pics.com/jeff.png',
site_coordinates: '33.9192233, -118.4061577',
email: 'jeff.lebowsky@duckcorp.com',
mobile_phone_number: '0605030402',
team: 'Central Office',
manager: '231',
manager_name: 'Helen RIPLEY',
job: 'Senior architect',
}
N’exposez que les données
réellement utilisées
Privilégiez des APIs
pragmatiques qui limitent
le nombre d’appels réseau
18. Mais encore ...
Prenez l’usage et les contraintes mobile en considération :
- En limitant le nombre d’objets, et en conséquence la taille du payload renvoyé par le serveur ...
- … voire même en incitant le client à filtrer encore plus ses recherches en amont
- En utilisant des formats compressés
Requête
GET /api/employees?range=0-25
Réponse
206 Partial Content
Content-Range: 0-25/2347
Accept-Range: employees 50
[
{...},
{...},
{...},
]
Requête
GET /api/search?name=fr*
Accept-Encoding: gzip, deflate
Paginez Autorisez les formats
d’échanges compressés (zip,
protobuf...)
Forcez l’utilisateur à affiner sa
recherche en renvoyant un
code d’erreur applicatif
Requête
GET /api/employees?name=F*
Réponse
400 Bad request
412 Precondition failed
413 Request entity too large
26. “Mon enseigne” 4,4/5
“Le nom du magasin”
Commentaire 1
Commentaire 2
Commentaire 3
Commentaire 4
BE 1
BE 2
Exemple : Fiche magasin
27. BE 1 BE 2
Perte de
réseau ?
Rollback
context
transactionnel
?
2 plateformes
?
Roadmaps
?
28. BE 1 BE 2API
MOB
Designer vos
ressources
Filtrer et
alléger les
payloads
Mutualiser du
code métier
Décorréler les
roadmaps
....
ex : cache
applicatif
server
31. ● Ne pas propager la complexité du SI dans une app
● Avoir des APIs dédiées pour les applications
○ Limiter les appels réseaux
○ Driver le design de l’API mobile par l’UX
○ Exploiter les mécanismes de cache
○ Ne garder que le nécessaire dans vos payloads
○ ...
Take away