3. Qu’est-ce qu’une application mobile
• Application impliquant une interaction avec l’utilisateur
• Conçus ou optimisée pour l’utilisation sur appareils
mobiles
• Supporte différents types d’appareils. Au moins une
tablette et/ou un téléphone intelligent.
4. Les catégories d’applications
• Les applications se divisent presque exclusivement en 2
catégories
• B2C (Business-To-Consumer)
• B2B (Business-To-Business)
5. B2C
• Business-To-Consumer
• Ce sont les applications comme Facebook, Future Shop, La
Presse+, Angry Birds, etc...
• On doit évaluer le type d’app en B2C. Gratuite, payante ou
« freemium ».
• Les secteurs les plus attirés par B2C sont les transports, ventes au
détails, santé, logiciels (jeu et autres), services financiers, media, et
fournisseurs de contenus en général (YouTube, Songza, etc.)
6. B2B
• Business-To-Business
• Dans le mobile, ça s’applique aux applications d’entreprises
• Plus porté à aller vers une seule plateforme et fournir le matériel et
le logiciel.
• Les applications du Apple Store à Sainte-Foy
• L’application du MRN fait par notre ami Carl Chouinard.
• C’est ce secteur qui a fait la fortune de BlackBerry à l’époque
9. Les types d’applications (logiciel)
Native Web app Hybride
Peut être déconnectée Doit avoir une connexion
la plupart du temps
Peut-être déconnectée
Longue à développer ($) Facile à développer Facile à développer
Une app par plateforme Multiplateformes Multiplateformes (à 90%)
Rapide Plus lente (au moins au
chargement)
Plus lente que natif
Présence dans les stores Référencement web
normal
Présence dans les stores
10. Les sites web mobiles
• Site mobile
• Site web optimisé pour
le mobile
• Peut être applicatif (web
app) ou static
• Nécessite la présence
de 2 sites avec un
système de détection et
d’aiguillage.
• Responsive design
• Site s’affichant
différemment sur PC et
sur mobile.
• Plutôt pour les sites
static ou CMS
• 1 seul site avec
détection et utilisation de
CSS appropriés pour
l’appareil et l’orientation
11. Les patterns de développement mobile
• Présentation
• Back-and-Save
• Guess-Don’t-Ask
• A-la-Carte-Menu
• Sink-or-Async
• Logon-and-Forget
• Babel-Tower
• Do-as-Romans-Do
• List-and-Scroll
• Comportement
(behavior)
• Predictive Fetch
• Memento-Mori
• As-Soon-As-Possible
12. Back-and-Save
• Sauvegarder le plus souvent
possible ce que l’utilisateur a
saisie afin d’éviter de l’obliger
à retaper en cas de
problèmes.
Save the content of
input screens when the
user leaves (or is forced
to leave) the screen
13. Guess-Don’t-
Ask
• Essayer d’anticiper les choix
de l’utilisateur pour minimiser
le nombre d’interactions. On
pense à « l’autocomplete »
par exemple.
Use any available
resources to make
intelligent guesses and
save users the largest
possible bit of
interaction.
14. A-la-Carte-
Menu
• Les choix doivent être clairs
et chacune des actions ne
devraient pas être à plus de 2
ou 3 clicks
At any time, it should be
clear for the user which
action to take and how
many options she has.
15. Sink-or-Async
• Tous les traitements prenants
plus de quelques
millisecondes devraient être
asynchrone
Implement
asynchronously any
operations expected to
perform for longer than a
bunch of
milliseconds.
16. Logon-and-
Forget
• Toujours authentifier
l’utilisateur une fois et
sauvegarder les informations
de façon sécuritaire pour une
durée déterminé.
You should ask for
credentials once, store
them safely, and
transparently
authenticate the user in
every session.
17. Babel-Tower
• Autant que possible, toujours
utiliser un procédé pour
présenter l’application dans
la langue de l’usager.
Avoid hard-coded and
fixed layout text and
design your application
to support the dynamic
injection of properly
translated text.
18. Do-as-
Romans-Do
• Respecter les conventions
d’utilisations des applications
des différentes plateformes.
Juste à penser aux menus
contextuels d’Android.
It is compelling for
users, and possibly also
advantageous for
developers, to abide by
the lookand-
feel and capabilities of
the host operating
system
19. List-and-Scroll
• Présenter l’informations sous
formes de listes. Beaucoup
d’applications implémente ce
pattern.
Don’t be afraid of using
(vertical) lists in your
mobile application, even
long lists that contain
more than 100 items to
scroll.
20. Predictive
Fetch
• Prédire les prochaines
actions et pré charger les
données. On peut s’aider
avec un MVP et de l’analyse
d’utilisation par exemple.
If you depend on
network connectivity,
download data that is
likely to be used later
and make
sure you have enough
data stored at any time
to survive a lack of
connectivity.
21. Memento-Mori
• « Rappellez-vous que vous
mourrez ». On doit
sauvegarder son état
lorsqu’on est relégué à
l’arrière plan car l’application
peut être terminée en tout
temps par l’OS.
Applications always
should save their
relevant state when the
operating system forces
them into
the background.
22. As-Soon-As-
Possible
• Les fonctionnalités critiques
devraient être traitées en
priorité et reprises
automatiquement en cas
d’erreur. Implémenter des
détecteurs de connexion
réseau pour reprendre une
mise à jour échouée par
exemple.
Remote operations that
are critical for the
application should be
implemented in a
protected
manner and reiterated a
few times before failing.
In case of failure,
however, the operation
should
be recorded and played
back as connectivity
returns.
23. Références
• Architecting Mobile Solution For The Enterprise – Dino
Esposito, Microsoft Press
• BriteSnow - The Five Software Architecture Generations
http://britesnow.com/blog/software-architecture-evolution-
mobile-apps-to-html5
• Choosing The Right Architecture For Developing Mobile
Applicationhttp://www.enterprisecioforum.com/en/blogs/su
kumarofs/choosing-right-architecture-developing-m)
