Date: Thu, 28 Mar 2024 20:54:08 +0100 (CET)
Message-ID: <1478778034.163.1711655648732@confluence-esup.uphf.fr>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_162_551319960.1711655648731"
------=_Part_162_551319960.1711655648731
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
1=C2=B0) Adapter les services :
- tous les services et toutes les fonctionnalit=C3=A9s ne sont pas utiles=
sur une version mobile : il faut d=C3=A9finir quelles parties de l'applica=
tion existante doivent =C3=AAtre port=C3=A9es en version mobile et lesquell=
es sont superflues.
- la mobilit=C3=A9 est une contrainte pour ce qui est de l'ergonomie pure=
de l'application mais offre certaines opportunit=C3=A9s. C'est pourquoi, a=
u-del=C3=A0 de faire un =C2=AB simple portage =C2=BB des services=
existants en version mobile, il serait int=C3=A9ressant d'ajouter des serv=
ices (ou de modifier ceux existants) en y int=C3=A9grant des infos li=C3=A9=
es =C3=A0 la g=C3=A9olocalisation par exemple.
2=C2=B0) Cibler le(s) public(s) souhait=C3=A9(s)
Apr=C3=A8s avoir choisi les services =C3=A0 adapter/cr=C3=A9er, il faut =
alors se poser la question : application =C2=AB native =C2=BB ou =
application Web ?
- S'il s'agit d'une application native, sur quels terminaux nous concentr=
ons-nous : IPhone et/ou Android et/ou =E2=80=A6 ? Si l'application native p=
ermet une meilleure int=C3=A9gration =C3=A0 l'environnement mat=C3=A9riel, =
l'application Web -elle- permet de toucher TOUS les utilisateurs peu import=
e les terminaux mobiles utilis=C3=A9s
- S'il s'agit d'une application Web, doit-on cr=C3=A9er une application s=
p=C3=A9cifique =C2=AB mobile =C2=BB ou bien modifier l'applicatio=
n existante de fa=C3=A7on =C3=A0 ce qu'elle s'adapte aux terminaux mobiles =
?
3=C2=B0) Faire =C2=AB simple=
=C2=BB : penser =C3=A0 une ergonomie adapt=C3=A9e
- malgr=C3=A9 les progr=C3=A8s faits =C3=A0 ce sujet, les claviers sur mo=
bile s'av=C3=A8rent g=C3=A9n=C3=A9ralement peu pratiques... il est donc imp=
ortant de minimiser la saisie.
- faciliter/limiter la navigation : l'utilisateur ne doit pas avoir =C3=
=A0 passer 10 =C3=A9crans pour arriver =C3=A0 l'information qu'il souhaite =
et les contr=C3=B4les doivent =C3=AAtre rapidement rep=C3=A9rables sur l'in=
terface.
- pour ne pas trop d=C3=A9payser l'utilisateur, il serait pr=C3=A9f=C3=A9=
rable de customiser au maximum l'interface mobile de fa=C3=A7on =C3=A0 ce q=
ue certains =C3=A9l=C3=A9ments graphiques caract=C3=A9ristiques (couleurs, =
images, polices, etc.) soient proches entre la version =C2=AB g=C3=A9n=
=C3=A9rique =C2=BB et la version mobile d'un m=C3=AAme service. <=
/li>
- utiliser des polices (styles et taille) et couleurs adapt=C3=A9es. Les =
environnements et situations dans lesquelles les utilisateurs utilisent les=
services mobiles sont plus =C2=AB extr=C3=AAmes =C2=BB que derri=
=C3=A8re un PC de bureau : luminosit=C3=A9 (contre-jour, soleil plongeant s=
ur l'=C3=A9cran, etc.), monde =C2=AB en mouvement =C2=BB (m=C3=A9=
tro, voiture, marche, etc.).
- optimiser l'espace visible sur un =C3=A9cran mobile : =C3=A9viter =C3=
=A0 l'utilisateur d'avoir un ascenseur horizontal et/ou vertical. Etant don=
n=C3=A9 le nombre de terminaux mobiles sur le march=C3=A9, les tailles et r=
=C3=A9solutions d'=C3=A9cran diff=C3=A8rent beaucoup : il faudrait donc ada=
pter l'interface graphique en fonction des sp=C3=A9cificit=C3=A9s des termi=
naux (exemple : tailles des banni=C3=A8res pour UnivMobile en fonction de l=
a =C2=AB famille =C2=BB du mat=C3=A9riel). [{_}Note: de =
plus en plus de t=C3=A9l=C3=A9phones proposent des modes =C2=AB paysag=
e =C2=BB et =C2=AB portrait =C2=BB : penser =C3=A0 tester le=
s 2 variantes{}]_
4=C2=B0) Tenir compte des contra=
intes R=C3=A9seau (d=C3=A9bit) et Technologique
Afin de minimiser le temps de chargement d'une page et donc permettre la=
meilleure exp=C3=A9rience utilisateur qu'il soit, il est primordial d'all=
=C3=A9ger au maximum les pages :
- en redimensionnant les images (dimensions, compression, etc.).
- en r=C3=A9duisant les scripts charg=C3=A9s dans une page : il est inuti=
le de garder des centaines de lignes de Javascript si seulement 5 m=C3=A9th=
odes nous int=C3=A9ressent.
- si l'application affiche des pages =C2=AB lourdes =C2=BB (pag=
e d'actualit=C3=A9s par exemple : images, vid=C3=A9os, etc.), il serait pr=
=C3=A9f=C3=A9rable de charger au fur et =C3=A0 mesure la page (1 actualit=
=C3=A9 charg=C3=A9e =C3=A0 la fois par Ajax) et non tout d'un coup, au char=
gement initiale de la page.
De plus, tous les terminaux mobiles n'embarquent pas le m=C3=AAme naviga=
teur : il faut donc veiller =C3=A0 utiliser des technologies (librairies JS=
F, etc.) compatibles avec un maximum de navigateurs mobiles. Par exemple, a=
vec la librairie Trinidad est fournie une liste d=C3=A9taill=C3=A9e des nav=
igateurs mobiles compatibles : http://myfaces.ap=
ache.org/trinidad/browsers.html
Liens pratiqu=
es :
- Bonne pratiques du =C2=AB Web mobile =C2=BB (Mobile Web=
Best Practices aka MWBP) d=C3=A9finies par le W3C :=20
- Bonnes pratiques : Accessibilit=C3=A9 et =C2=AB Web mobile =
=C2=BB=20
- R=C3=A8gles d'ergonomie ou de qualit=C3=A9 plus g=C3=A9n=C3=A9rales com=
me celles d'OpQuast :http://www.opquast.org/
------=_Part_162_551319960.1711655648731--