Développement d'un service mobile

Développement d'un service mobile

Ludovic Tant

1 - Ludovic Tant – Développement mobile - v1

Présentation

Ludovic Tant, 32 ans
 ludovic.tant@atosorigin.com

Fonctions actuelles Expérience
Chef d'équipe « TUM Labs » 2002 Framework SMS
Responsable d’une équipe de 2006 Dév. visio mobiles
5 ingénieurs type R&D
2007 Dév. d'applis WiMo (Ten)
Porteur d’offre de la solution
2007 Dév. J2ME pour SFR
interne Worldline Padda
07-09 Développement J2ME
Référent application mobile
chez TUM 08-09 Gestion de projets
avant ventes android,
blackberry, iPhone

Règles

Globalement interactif
Si risque de dérapage, certains questions repoussées en fin
d'intervention
Téléphones en mode discret

(Questionnaire d'amélioration en ligne à la fin)


Au menu
En
Apéro 1 h3
0
Mobilife 2010
Entrée
Panorama des technos
Indisponible en raison de la
Plat saison
Ergonomie, Design et Exemple de code
développement mobile
Debug
Dessert
NDA
Distribution de l'application
Boissons comprises


Au menu
En
Apéro 1 h3
0
Mobilife 2010
Entrée
Plat saison
Debug
Dessert
NDA
Boissons comprises


Mobilife 2010

Concours national Organisé par Big5media
Ecoles d'ingénieurs
Par équipe (1-5 personnes) Parrainé par
Thème imposé: La vie
quotidienne
Projet innovant (technique,
Inscription : sept-oct 2009
idée, packaging)
Remise des projets: 31/12/09
Prix: voyage Silicon valley,
smartphones, netbooks Remise des prix: 2010

Au menu
En
Apéro 1 h3
0
Mobilife 2010
Entrée
Plat saison
Debug
Dessert
NDA
Boissons comprises


Un service mobile peut avoir plusieurs formes

SMS
USSD
Audiotel
Visio
Wap/Web
Application mobile embarquée


Un service mobile SMS

+ modèle éprouvé techniquement
+ modèle économique viable pour les éditeurs
+ interopérable dans le monde entier
et plus souvent que le roaming data
+ en forte croissance surtout dans les pays émergents
reporting sanitaire au Malawi et en Éthiopie, Nokia Money
- asynchrone
pas de session, pas de cookie
- limité en taille
160 octets
- pas hype du tout ;-)


Un service mobile USSD

Exemple: #123# d'orange
peu utilisé, et surtout par les opérateurs pour leur propre service
+ connecté
- peu connu du grand public
- pas de modèle économique pour les éditeurs


Un service mobile audio

serveur SVI classique, « audiotel »
+ modèle éprouvé techniquement
mode connecté
développement généralement en vxml
+ modèle économique viable
36xx, 089[01279]xxxxxx
+ interopérable dans le monde entier
et plus souvent que le roaming data
- pas hype du tout ;-)


Un service mobile visio

pas vraiment décollé
compliqué pour l'utilisateur
appel « en visio » ou touche « visio »
mode connecté
surtaxe possible
essentiellement « rencontre interactive »


Un service mobile web
« wap » est un gros mot
Les navigateurs modernes peuvent faire mieux
iPhone, mais aussi Nokia Serie60, SonyEriccson, BlackBerry,
LG, Samsung etc
Nécessite d'avoir un site optimisé mobile
bande passante, mémoire, usage


Un service mobile embarqué
Plusieurs formes


Un service mobile: au final ???
Le quidam s'y perd
web/webapp/appli mobile embarquée native/tierce …
rôle pédagogique de l'iPhone

Web ou embarqué ?
Pro web:
+ simple, - cher, c'est « l'avenir »
mise à jour
pas d'application difficile à retrouver

Pro embarqué:
meilleur design, ergonomie et interactivité
plus de fonctionnalités (caméra, contacts, offline, NFC, SIM)
présence sur les application store
pas d'URL difficile à taper

Éternel débat “client lourd vs client léger”
à décider au cas par cas
au final, l'important, c'est l'usage pas la technique


Au menu
En
Apéro 1 h3
0
Mobilife 2010
Entrée
Plat saison
Debug
Dessert
NDA
Boissons comprises


Ergonomie d'un service mobile

Spécificités: Mots d'ordre
Environnement bruité Simplicité
Utilisation « en temps mort » Zenitude
Réponse à un besoin Dépouillement

Une démarche
L'usage prime sur les désirs du client
Analyse des profils, besoins et objectifs du futur service
Conception collaborative et itérative basée sur des
cinématiques, story boards, maquettes
Evaluation de l'interface par des utilisateurs à différents stades
du projet



Minimiser le volume d’informations affichées
Malgré les progrès, un écran reste petit.
Informations limitées à l’essentiel et à peu de contenu par page.



Minimiser les textes
style rédactionnel
clair, précis, concis



Minimiser les actions requises



Minimiser le nombre de liens
placer en tête les liens les plus souvent utilisés
en tactile, un liens doit devenir un bouton assez grand et espacé
résister à la tentation d'un visuel abscons à la place d'un texte
les icônes doivent être systématiquement sous-titrées.



Minimiser les saisies
Pas de clavier alphabétique, ou clavier alphabétique en deça du confort d'un clavier
desktop.
Eviter les saisies combinant chiffres et lettres (mots de passe)
Utiliser des services du type mobiletinyurl

http://www.atosworldline.com/En/Market_Sectors/Transport/Airlines/innovation.html
http://ad.ag/tmwgtp (13 appuis vs 184)



Minimiser les temps de chargement et les temps de réponse
usage « pressé »
bande passante faible (surtout en déplacement)
temps de latence



Minimiser le temps d’appropriation
Se conformer aux standards d’usage
Reprendre le wording et les icônes du site web s'il existe
Exemples :
WAP : le caractère > ou < devant les liens...,
iPhone : boutons pour naviguer comme pour agir, flèche vers la droite pour naviguer
entre les listes, secouer pour rafraichir (finalement, plus vrai en 3.x)


Au menu
En
Apéro 1 h3
0
Mobilife 2010
Entrée
Plat saison
Debug
Dessert
NDA
Boissons comprises


Design mobile: les problèmes

Diversité des tailles d'écran, bien plus importante que dans le
monde desktop
Tactile, non tactile, mixte


Design graphique : S'adapter aux différentes tailles d'écran

Quelques format plus répandus que d’autres, mais l’exotique existe toujours (voir de plus en
plus)
Notion de famille/classe d’écran

Extrêmes suivantes dans chaque classe
• tiny : du 128x116 et du 120x147
• small : à partir de 128x128 et jusqu'à du 220x159 ; surtout du 128x160, pas mal de 128x128 et de 130x176
• large: à partir de 176x177 et jusqu'à du 240x208; surtout du 176x206-220
• verylarge: à partir de 240x256 et jusqu'à du 240x400 et 480x248 , surtout du 240x320
• huge: jusqu'à du 480x800; surtout du 352x416
• Les classes d'écran à privilégier pour les tests sont verylarge et large.

Comment gérer ?
 Soit prévoir tous les cas, s’ils sont peu nombreux
 Soit prévoir quelques cas typique, et rajouter des bordures quand l’écran est plus grand: border design
 Soit stretchy design

De plus, prévoir une bande décorative en haut
 Car souvent encombré par des icônes (réception, batterie etc).

Format des images
 png, mode palette 32/64/256 couleurs, 16 degrés de dégradés dans l’alpha, pngoptimizer
 une version par famille d’écran


Design graphique: Solution 1: prévoir tous les cas

+ rendu nickel pour les tailles prévues
- … moins bien pour les tailles non prévues
+ positionnement au pixel près via fichier de config modifiable par le client
cf. projets SFR/Streamezzo

chaque élément est placé au pixel près


Design graphique: Solution 2: border design

+ rendu nickel pour les tailles prévues ou à peu près
- … moins bien pour les tailles vraiment éloignées
+ solution cumulable avec la précédente

offset X et Y égale à la moitié de la différence entre la taille
prévue de la classe et la taille réelle de l’écran
chaque élément est placé au pixel près
ajout d’un rectangle de couleur en fond de décor

Design graphique: Solution 3: stretchy design

- rendu pas nickel au pixel près
+ gère au mieux tous les écrans proches de la référence de chaque classe
+ gère au mieux pire les écrans très exotiques
doit être prévu dès le début de la conception

d=(H-4*h)/5
h

H

logo et boutons
les boutons sont
le logo n’est plus une image sur toute la largeur de ancrés au centre et à
ancrés bottomleft et
l’écran mais une image doublée d’un rectangle blanc. width/2
bottom right

Au menu
En
Apéro 1 h3
0
Mobilife 2010
Entrée
Plat saison
Debug
Dessert
NDA
Boissons comprises


Un problème ? Quel problème ? Ou est passé ma CPU ?

 Serveur typique: quadripro, 2 Go RAM, plusieurs To sur
serveur de fichiers
 PC Desktop : pentium III 2.8 Ghz, 2 Go RAM
 Émulateur WTK 2.2 sur desktop: 10Mo, 161890 Points CPU
Speed indice
 KVM SE K800: 863ko, 58161 Points CPU Speed indice

Conséquence:
les non optimisation en javascript, en java serveur, en perl etc.
sans impact de performance en auront sur le mobile


Un problème ? Quel problème ? Téléphones bugués

Téléphones bugués, ou s'éloignant de la théorie

Chargement initial de la KVM Chargement d'une image optimisée * 1er GC 2ème GC

F480 760 062 3 313 108 3 458 540 866 768
N95 256 880 264 704 259 904 259 556

Chargement de la KVM plus ou moins important
Gestion différente des images (décompression, transformation bitmap)
Garbage Collector qui ne ramasse pas tous les objets abandonnés au premier passage

Affichage de texte en mode souligné inexistant ou défaillant

* Image de couleur unie, au format PNG d’une résolution de 1440 x 900


Tip #1: Problème des polices

 Positionner les textes en local si centré, justifié
 Ne pas utiliser le souligné
 Privilégier les textes courts

Affichage de texte sur des
téléphones Motorola (à
gauche)
et Sony Ericsson (à
droite). Le téléphone de
gauche ne
sait pas souligner les
textes, et l’épaisseur des
caractères
est très différente entre
les deux téléphones.


Tip #2: Compacter le code

 Factoriser le code mais pas trop
 Design pattern, getter, setter et co → pragmatisme
 En J2ME: parser xml → pragmatisme
 Raccourcir les noms de variables, de classes
J2ME: Obfuscation de code
javascript, HTML: « compactage »


Tip #3: optimiser les images
Format png
Virer les meta data (PNG optimizer) => de -10% à -20%
Images en palette 256/128/64/32/8 couleurs et pas en true
colors => - 70%


Tip #4: Attention à la transparence


Tip #5: Nettoyage des répertoires ressources

 Les répertoires contenant les images se retrouvent souvent
tels quels dans l'appli finale
 .svn, CVS, thumbs.db, .backup, .orig
 n'ont pas leur place dans le jar !!


Tip #6: pas de redirect 302

 Pas supporté par les KVM Nokia S40
 Peu supporté par les téléphones quand les URLs de notif
d'install/désinstall sont en redirect 302


Tip #7: écrans tactiles

 Les téléphones tactile ont (ou pas) un clavier, des soft keys,
un joypad
=> attention à le prévoir dans les algos et dans les tests
 Sur des écrans de plus en plus grands, un clic au doigt peut
être perçu par le système comme un déplacement de
quelques pixels
=> et c'est très frustrant, et très long à comprendre
 Zones cliquables (textes, images) de suffisamment grande
taille (relativement à l'écran)


Tip #8: Les tests

 Très tôt dans les dév
Pour vérifier dans les vrais conditions (CPU, mémoire, BD,
temps de latence réseau)
Et changer l'application en conséquence en début de cycle

 Avec de vrais utilisateurs
Qui ne connaissent pas l'application
Qui ne sont pas liés au projet chez le client

Tip #9: importance du fonctionnel/ergonomie/design

Si ce n'est pas pratique, ce n'est pas utilisé
Il y a très peu de différences entre une application hyper
pratique et une appli qui frustre
ex: menu NS
Le design est important:
ex: carpo SFR ou slide 21 formation avancée padda


Illustration du tip 9

Avant:

Après:


Tip #A: importance du marché cible
 Peut annuler un projet si pas assez important
à définir/vérifier avant les dév/avant les tests

 Nécessite de définir le marché cible

 Attention aux hypothèses perso non vérifiées
exemple: blackberry pour les pros, iPhone pour le grand public

Au menu
En
Apéro 1 h3
0
Mobilife 2010
Entrée
Plat saison
Debug
Dessert
NDA
Boissons comprises


Comment distribuer une application mobile ?
Site web
facilement accessible (mobiletinyurl, code barre 2D, SMS pushwap)
aidant l'utilisateur (reconnaissance auto du mobile, FAQ)
Sur un store
 Le référencement à un cout ‘humain’ d’administratif
 Tous les magasins ne sont pas égaux, notamment en terme
d’audience
 Les reversements sont en général du même ordre de
grandeur (70 à 80%)

Les stores à forte Les stores à Les stores
audience potentiel d’annonces

AppStore OVI Store Samsung
Android Market Windows
RIM Appworld Orange Store …
SFR Store
Votre Site internet !

Au menu
En
Apéro 1 h3
0
Mobilife 2010
Entrée
Plat saison
Debug
Dessert
NDA
Boissons comprises


Quelques pointeurs

Association SMS+: http://www.smsplus.org/
USSD:
http://fr.wikipedia.org/wiki/Unstructured_Supplementary_Service_D
vxml: http://fr.wikipedia.org/wiki/VoiceXML
white paper développement d'applications mobiles: ???
brochure padda: ????
compte développeur iPhone (inscription gratuite)
concours mobilife 2010:http://www.mobilife2010.org/


Merci
Pour votre attention

Ludovic Tant


Développement d'un service mobile

Contenu connexe

Tendances

En vedette

Similaire à Développement d'un service mobile

Plus de Ludovic Tant

Développement d'un service mobile