Case study : 2 applications mobiles réalisées avec Drupal

Drupagora 2016
Case study :
2 applications mobiles
réalisées avec Drupal
Julien Touzé - CEO

SOMMAIRE
1. (Grosse) Introduction
2. (Nombreuses) Problématiques !
3. Drupal 8
4. Questions
Drupagora 2016 - Case Study : 2 apps avec Drupal, par Julien Touzé - Twitter : @Skilld_fr #drupagora 2/43

1. INTRODUCTION
Qui suis-je ? Et vous ?
Pourquoi faire une « app » ?
D'ailleurs c'est quoi une « app » ?
Pourquoi Drupal est recommandé ?
Case Study #1
Case Study #2
3/43Drupagora 2016 – Case Study : 2 apps avec Drupal, Julien Touzé - Twitter : @Skilld_fr #drupagora

1. INTRODUCTION – QUI SUIS JE ?
Drupagora 2016 – Case Study : 2 apps avec Drupal, par Julien Touzé - Twitter : @Skilld_fr #drupagora 4/43
Top #1 – France – Drupal 8 Core Contributor
Top #8 – Worldwide – Drupal 8 Core Contributor
+100 % de croissance en 2015
Source : http://www.drupalcores.com/companies.html

1. INTRODUCTION – QUI SUIS JE ?
POURQUOI JE SUIS LA ?
[A] Pour me changer de l'enseignement de la gestion aux Mines ;-)
[B] Skilld a une expertise reconnue sur le thème {App + Drupal}
[C] Etat d'esprit « 100 % Logiciel Libre » → Partager & Contribuer
[D] Trouver de nouveaux projets ambitieux d'Apps avec Drupal !
ET VOUS, POURQUOI VOUS ETES LA ?
[1] Vous détestez la Croix-Rouge ?
[2] Vous vouliez faire la sieste dans un amphi au chaud ?
[3] Vous n'avez trouvé aucun prestataire pour vos applis avec Drupal ?
[4] Any other reason ?
Bonnes Réponses : A3, B3 ou C3 >>> contact@skilld.fr
ALLEZ, LET'S GO !

1. INTRODUCTION - POURQUOI UNE « APP » ?
Drupagora 2016 – Case Study : 2 apps avec Drupal, par Julien Touzé - Twitter : @Skilld_fr #drupagora
ALORS. POURQUOI UNE « APP » ?
Mobile > Desktop depuis 2014
Source : http://www.smartinsights.com/mobile-marketing/mobile-marketing-analytics/mobile-marketing-statistics/
6/43

1. INTRODUCTION - POURQUOI UNE « APP » ?
ALORS. POURQUOI UNE « APP » ?
Avantages d'une APP vs Site WEB :
#1 Personnalisation
#2 Notifications
#3 Usage des Capteurs
etc.
Sources : http://www.smartinsights.com/mobile-marketing/mobile-marketing-analytics/mobile-marketing-statistics/
http://app.mhb.io/e/dkgd/5o
« Pourquoi une app » ?
1. Usage Mobile > Desktop (mais on ne peut PAS ignorer le desktop)
2. Usages sur mobile : 90 % Applications, 10 % Navigateur (USA, 2015)
3. Usage multi-supports chez 80 % des utilisateurs

1. INTRODUCTION – C'EST QUOI UNE « APP » ?
Drupal « Headless » WebApp Native App
Classique Drupal (Single page) Ex : Android
8/43
Source : http://fr.slideshare.net/AcquiaInc/applied-progressive-decoupling-weathercom-angular-and-drupal
C'EST QUOI UNE « APP » ?
1. Un Back-end (comme Drupal) = {Le moteur de l'application + Le back-office}
2. Une API REST (webservices) pour la transmission des données
3. Un Framework Javascript ou équivalent, pour consommer / afficher les données

1. INTRODUCTION – C'EST QUOI UNE « APP » ?
Source : http://www.kantarworldpanel.com/fr/smartphone-os-market-share/
Android to Rules them ALL ?
Evolution en France sur 4 ans. (NB : Situation différente pour chaque pays)
Blackberry est mort. Windows Phone bientôt (pic en 2015 à 10%)
Breaking News

1. INTRODUCTION – DU COUP, BO = DRUPAL ?
Pourquoi Back-End === DRUPAL ?
(ce que l'on appelle « Headless Drupal »)
Pour de nombreuses raisons (idem projet web)
- Evolutivité
- Flexibilité
- REST Ready
- Sécurité
- Communauté
Source : https://github.com/davidhwang/horseman

1. INTRODUCTION – DONC C'EST FACILE ?
DONC C'EST FACILE ? OUI ! :-) … et NON :-(
2012 : Android 2.3 (Think IE8 for Desktop…), et Blackberry 15 %
2016 : Mort de Windows Phone + Blackberry // Avènement de Drupal 8
>>> CELA CHANGE TRES TRES VITE !!! <<<
ET MAINTENANT LA SUITE :
Je vais vous raconter 2 histoires *vraies* sous un angle fonctionnel & Business
Il était une fois une startup…et même deux startups, et même plus ;-)
RESUME INTRO (pour ceux qui avaient répondu [2] (la sieste)) :
- IL FAUT FAIRE DES APPS
- APP ANDROID et APPLE ONLY
- DRUPAL = PARFAIT pour le Back-End + API REST
- APP HYBRIDE (CORDOVA) ou NATIF ou WEBAPP pour consommer
Bonus Tuto Technique : Allez voir la super conf « Headless Drupal & Angular » sur slideshare
11/43

1. INTRODUCTION - CASE STUDY #1
Back-End : Drupal 7 + Drupal Commerce
Webapp + Apps Hybrides Android + iOS (Cordova)
Points clés : Startup + Médias + Social + Transactionnel (Paypal)
12/43

1. INTRODUCTION - CASE STUDY #2
Back-End : Drupal 7
App Hybride Android (Cordova)
Points clés : Santé + Notifications Push GCM (Google) + Capteurs Smartphone
13/43

2.PROBLEMATIQUES
Les contraintes de tout projet web...
Les problématiques « app » (Front-End)
Les problématiques Drupal (Back-End)
Bilan ?
Drupagora 2016 – Case Study : 2 apps avec Drupal, Julien Touzé - Twitter : @Skilld_fr #drupagora 14/43

IL ETAIT UNE FOIS … UN MONDE IDEAL (Phase de séduction)
Le client veut « Une app géniale simple qui fonctionne partout & tout le temps »
Le client a aussi { temps & budget } limité (plutôt ++ que --)
NB : C'est vrai pour tous les projets / clients, a fortiori les startups (vie ou mort)
Rappel : Définition de la Stratégie d'entreprise :
Strategy can be defined as the determination of the long-term goals and objectives of an enterprise, and the
adoption of courses of action and the allocation of resources necessary for carrying out these goals
(Chandler (1962) Strategy and Structure. p. 13.)
QUEL EST LE MOT IMPORTANT SUR CETTE PAGE ? (réponse sur la page suivante)
2. PROBLEMATIQUES – CONTRAINTES PROJET WEB
15/43

Limité
On ne pourra pas TOUT faire
pour HIER
qui fonctionne sur TOUS LES DEVICES
dès le 1er jour sans AUCUN BUG.
(sic : « pourquoi on paie de la recette? »)
« on est tous AGILES ... »
+ On va proposer des LOTS
(et un « MVP » - Minimum Viable Product)
Il faut commencer par se mettre d'accord sur ce dont on parle ici >>>
16/43

IL ETAIT UNE FOIS… DES PERSONNES
De quoi parle t'on ?
Et avec qui ...
J'aime cette citation :
« Un [projet Web]
c'est la rencontre entre
quelqu'un qui ne sait pas ce qu'il veut
et quelqu'un qui ne sait pas ce qu'il fait (…) ! »
17/43

IL ETAIT UNE FOIS… DES LOTS & UN PLANNING
Vu par le client
Vu par le prestataire
Rappel – On aime cette citation :
« on ne fait pas 1 bébé avec 9 femmes en 1 mois » !
Se concentrer d'abord sur le coeur de l'expérience client !
Ne pas sous-estimer la phase de cadrage/conception (et la soumission des apps...)
Travailler en méthodologie SCRUM (a fortiori pour les startups)
18/43

IL ETAIT UNE FOIS… UN BUDGET
(Bonne Réponse : C2 ou C3 >>> contact@skilld.fr )
Question idiote #1 : Qui a raison ? (voir page d'après)
Question idiote #2 : sur quelle durée avez-vous prévu ce budget ?
Le budget d'une App {Build + Run} est toujours largement sous-estimé
On rigole aussi : Montée de version OS, TMA, Evolutions, « Mode produit », etc.
Vu par le client Vu par le prestataire
[A] 5kE – 10+ kE [1] 20kE – 50 kE
[B] 20kE – 30+ kE [2] 50kE – 100kE
[C] 50kE – 100+ kE [3] 100++ kE
19/43

IL ETAIT UNE FOIS… UN BUDGET (SUITE)
Dev / Prod ? Hybride / Natif ? Complexité ? Nombre d'environnements ?
Source : https://crew.co/how-to-build-an-online-business/how-much-does-an-app-cost/
Budget x3 (Desktop + Natif x2) ou bien Webapp (+30% vs Desktop simple)
Pour une startup, l'arbitrage est rapidement fait ! (quitte à passer natif plus tard)
2. PROBLEMATIQUES – APP
20/43

IL ETAIT UNE FOIS…UN CLIENT PRESQUE CONVAINCU
C'est NORMAL, on ne déploie jamais assez de PEDAGOGIE
Pour expliciter les contraintes liées aux APPS
Let's GO !
On est presque tous au clair … {quoi / combien / quand}
Le client est « presque » convaincu de faire le bon choix ...
Mais le client trouve encore que le budget est très (trop?) cher !
21/43

IL ETAIT UNE FOIS… L'UNIVERS DES SMARTPHONES / TABLETTES
Définir les Devices et OS Cibles (Remember the time « Pixel Perfect »)
En 2016, 24000 Devices Android !
(+ Apple …) * OS versions
On ne peut PAS GARANTIR
un affichage parfait
sur tous les écrans
(NB : même avec 30 % de recette !)
Source : http://opensignal.com/reports/2015/08/android-fragmentation
Des sociétés de « (Crowd)testing »
Apparaissent :
Stardust Testing
TestObject.com
Etc.
22/43

IL ETAIT UNE FOIS… L'UNIVERS DES SMARTPHONES / TABLETTES (SUITE)
Attention aux vieilles versions des OS (Remember IE8)
Vous aviez réussi à valider de travailler sur Android et Apple only.
Et ping, suprise :
En 2016, il reste 2.3 % d'Android 2.x !
Doit-on traiter ces cas particuliers ?
(Réponse non ;-)
Source : https://developer.android.com/about/dashboards/index.html
Bien se mettre d'accord sur les
versions des OS supportées par
l'application développée !
23/43

IL ETAIT UNE FOIS… L'UNIVERS DES SMARTPHONES / TABLETTES (FIN)
Oubliez les Breakpoints. (il y en a trop)
Prévoyez 2 modes de consommation
De votre application :
1 mode vertical
1 mode horizontal
(NB : Blackberry Passport Carré ;-)
Et Pensez « Mobile-First » !
Source : http://digitalsynopsis.com/design/web-designer-developer-jokes-humour-funny/
Prévoyez 2 versions du design :
- 1 version verticale
- 1 version horizontale
24/43

IL ETAIT UNE FOIS... LES LISTES
Exemple typique : Une page « catégorie »...
Attention Danger Performances !
Les listes peuvent être TRES longues
Prévoir absolument un « infinite Scroll »
Qui (re)charge un nombre limité d'éléments
Source : http://elekslabs.com/2012/12/android-vs-ios-user-experience.html
Evitez d'avoir plus de quelques dizaines d'éléments simultanément dans vos listes
+ Mettez en place des « Infinite Scroll »
25/43

IL ETAIT UNE FOIS... L'ERGONOMIE ANDROID vs APPLE
(2 mondes irréconciliables)
Pour le choix « app hybride »
Il est IMPOSSIBLE de définir une Ux/Ui
Satisfaisante pour tous.
1. “Back” navigation
2. Top navigation
3. Switching between data views
4. Search
5. Actions
6. Screen sizes and resolutions
7. Scroll direction etc.
Source : http://elekslabs.com/2012/12/android-vs-ios-user-experience.html
Définir sa cible (Ex : Android only)
Et/ou Compromis
Et/ou Budget ++
26/43

IL ETAIT UNE FOIS... LE SEO
Le contenu d'une App n'est PAS référencé par défaut
Il faut :
1. Soit Prévoir un mini-site web (+ Landing Pages)
Pour le SEO
Pour faire rêver
Pour inciter au téléchargement
2. Soit Prévoir un effort spécifique
Utiliser une librairie JS créer du HTML indexable
(Ex. Prerender.io / React JS, etc.)
Source : https://www.gotinder.com/
Pour une App, le succès ne passe
PAS FORCEMENT par le SEO !
Ex : Tinder, Netflix, etc.
27/43

IL ETAIT UNE FOIS... LE DEVELOPPEUR JAVASCRIPT
La demande explose,
mais pas le nombre de développeurs JS expérimentés...
Il faut :
1. Soit utiliser Tinder ;-)
2. Soit payer très cher
3. S'investir dans la durée avec des équipes de dev.
Quoi qu'il en soit, comme c'est un besoin récent,
La situation ne s'améliorera pas avant qques années.
Source : http://www.visionmobile.com/product/developer-economics-state-of-developer-nation-q1-2016/
Attention pour la qualité de la réalisation, à la
pénurie de développeurs JS d'un bon niveau !
28/43

IL ETAIT UNE FOIS... LA PUBLICATION D'UNE APP
1. « Manifest » & Contraintes techniques
App et Compatibilité du téléphone
Déclaration des capteurs Ex : « podomètre »,
Problème avec certains Huawei
2. Publication sur l'App Store d'Apple
Prévoyez un délai suffisant dans votre planning
Si jamais l'app est refusée dans un premier temps…
3. Pour ceux qui publient pour la première fois,
Ne sous-estimez pas le temps qu'il faut y passer...
La publication d'une application dans les stores, qui paraît une formalité pour le
client, peut parfois générer des surprises… ;-)
29/43

IL ETAIT UNE FOIS... LA CONNECTIVITE & LES PERFORMANCES
En mobilité, la connexion est variable (ou parfois absente dans le métro...)
1. Penser au fonctionnement « Offline » / Rupture de connexion.
Local Storage (pour les médias ou formulaire)
Local Search (LunR JS)
2. Penser « Performances »
Utiliser tous les niveaux de Cache
(Attention aux données transactionnelles)
3. Grouper les appels au serveur autant que possible
4. Fichiers Médias :
Taille des fichiers (=> Image Styles côté Drupal)
Opérateurs qui dégradent la qualité des médias
5. Notifications Push
La connectivité (ou son absence) est l'un des enjeux majeurs à adresser dans un
projet d'App, et c'est en partie ce qui justifie que de tels projets sont souvent sous-
évalués par les clients en terme de budget.
Il FAUT prévoir du temps d'optimisation des performances à chaque SPRINT
30/43

IL ETAIT UNE FOIS... LA CONNECTIVITE & LES PERFORMANCES (SUITE)
L'API REST de Drupal renvoie des données « verbeuses »
Ce qui alourdit un peu le temps pour l'intégration FRONT.
Les requêtes peuvent être lourdes
(Cf : Données pour une page Catégorie)
NB : Drupal 7 propose des modules Contrib
Pour permettre la gestion de l'API REST
Le coeur de Drupal 8 est nativement RESTFul
Pour une APP, l'API REST qui fait la liaison entre le Back-end et Front-end
est LE goulot d'étranglement pour les performances.
Rappel : Il faut prévoir un effort d'optimisation des performances à chaque SPRINT
2. PROBLEMATIQUES – DRUPAL
31/43

IL ETAIT UNE FOIS... LES NOTIFICATIONS « PUSH »
Drupal propose un beau module pour gérer les notifications PUSH
Attention néanmoins à la fiabilité des Services Tiers
Quelques Suprises avec Google GCM (Google Cloud Messaging)
Drupal facilite la gestion des Notifications avec le module « Push Notifications ».
Mais ne pas sous-estimer fonctionnellement la mise en œuvre de ces Push
(notamment pour la recette)
32/43

IL ETAIT UNE FOIS... LES PAIEMENTS (PAYPAL)
Drupal propose un beau module pour gérer les paiements Paypal
Mais dans le cadre d'une intégration Hybride,
il faut se replier sur l'API Paypal.
Ceci occasionne un effort supplémentaire
(par exemple pour la gestion des produits gratuits)
NB : Il n'existe pas à ce stade de mode de paiement « universel » qui fonctionnerait
facilement dans tous les environnements. Paypal est un bon compromis.
L'intégration des moyens de paiement pour une app peut représenter un effort
significatif (en fonction des plate-formes supportées)
33/43

IL ETAIT UNE FOIS... LE LOGIN SOCIAL (FACEBOOK CONNECT)
Il faut prévoir plusieurs niveaux de connection en cascade.
1. Sur le web, usage d'un module Drupal « FB Connect »
2. Pour une webapp, usage de l'API Facebook
3. Dans un téléphone,
gestion de Facebook via l'OS
Et sinon via l'application Facebook
Et sinon Webview
Pas de difficulté particulière technique ici, mais plus pédagogique pour expliquer à
un client pourquoi cela prend autant de temps.
34/43

IL ETAIT UNE FOIS... LES PROJETS MULTILINGUES
Le fait de consommer les données dans une APP ne permet pas de bénéficier de
toutes les fonctionnalités Multilingues de DRUPAL aussi facilement.
NB : Drupal 8 > > Drupal 7
pour la gestion multi-lingue
Prévoir un effort de synchronisation des données de traduction entre le Back-End
et le Front-End
35/43

ON SE RESUME : LA VRAIE VIE EST PLEINE DE SURPRISES !
2. PROBLEMATIQUES – BILAN
Conclusion :
Les projets APP sont plus complexes que les projets WEB
Il faut gérer les 3 niveaux : Back-End + API REST + Front-End
Pédagogie + Pédagogie + Pédagogie !!!
Univers technologique très mouvant : AGILITE
Une durée de vie des apps très courte : TMA
De nombreux points d'attention : EXPERTISE
Un focus particulier sur les Performances (++ si JS Hybride)
Mais à la clé, un énorme potentiel BUSINESS pour les Apps réussies !
Et le futur ;-)
Drupal 8, RESTFul, Drupal 8 Commerce ;-) Android, Apple, etc.
36/43

3.DRUPAL 8
RESTFul Core
Gestion du cache
Drupal 8 Commerce ?
Drupagora 2016 – Case Study : 2 apps avec Drupal, Julien Touzé - Twitter : @Skilld_fr #drupagora
37/43

3. DRUPAL 8
Drupal 8 est nativement RESTFul !
Activation des Webservices
Configuration des Rôles
& Permissions
Etc.
38/43

3. DRUPAL 8
Drupal 8 est nativement RESTFul ! (suite)
On peut Gérer ses ressources REST
Et créer ses vues au format REST
Gain de temps et d'efficacité à la clé
39/43

3. DRUPAL 8
La gestion du Cache améliorée dans Drupal 8 : Gain x10
On passe de 40 requêtes / seconde à 400 requêtes / seconde
Sans Cache Avec Cache
40/43
Source : http://www.jeffgeerling.com/blogs/jeff-geerling/benchmarking-drupal-8-php-7-vs-hhvm

3. DRUPAL 8
Conclusion (pour ceux qui ont coché [2])
Skilld utilise déjà Drupal 8 pour des applis en cours de production
Avec des très bons points (RESTFul, Cache, Multi-lingue)
Et quelques bémols sur le niveau de maturité de certains modules,
Notamment Drupal 8 Commerce en version « alpha »
(version Béta imminente : allez à la conférence suivante !)
41/43
DRUPAL 8 : AMELIORATIONS NOTOIRES + « PEINTURE FRAICHE »

6. QUESTIONS ?
Drupagora 2016 – Case Study : 2 apps avec Drupal, Julien Touzé - Twitter : @Skilld_fr #drupagora
42/43

MERCIEmail : Contact@skilld.fr
Twitter : @Skilld_fr
@drupagora

Case study : 2 applications mobiles réalisées avec Drupal

Recommandé

Recommandé

Contenu connexe

Similaire à Case study : 2 applications mobiles réalisées avec Drupal

Similaire à Case study : 2 applications mobiles réalisées avec Drupal (20)

Plus de Skilld

Plus de Skilld (12)

Case study : 2 applications mobiles réalisées avec Drupal