Ces dernières années ont vu l’arrivée de nouveaux terminaux mobiles dont les interfaces se sont de plus en plus adaptées aux contraintes de leur environnements. Nous allons tenter dans cet article d’identifier ces contraintes et voir quelles réponses apporter dans les applications web via l’utilisation du framework Sencha Touch.

# Mais tout d’abord : Que-ce que Sencha Touch ?

Sencha Touch est un framework Javascript basé sur JQTouch et ExtJS, utilisant massivement HTML5 et CSS3. Il permet de créer des interfaces pour tout navigateur utilisant comme moteur de rendu WebKit et pour une utilisation au doigt. Ce framework offre une gestion des données très puissante contrairement à certains de ses concurrents comme jQueryMobile. En contrepartie, le framework est lourd : la librairie pèse plus de 300ko, et le code complexe à exécuter. Les principes de fonctionnement ainsi que les noms des éléments sont très similaires à la libraire ExtJS4.

 

Site Web de Sencha Touch : http://www.sencha.com/products/touch/

Intéressons-nous aux contraintes de développement des applications sur un plan ergonomique. Suivant le type de terminal (smartphone, tablette…), deux éléments de saisie restent très disparates au sein du marché : la présence ou non d’un clavier physique, et l’écran. Mais désormais tous les smartphones récents s’utilisent au doigt. Exit le stylet, mais on pourra le regretter sur quelques points tout de même. Contrairement à celui-ci, un doigt, c’est gros et peu précis. Mais cela apporte un avantage indéniable : cela rend l’interface plus naturelle à utiliser, si tant est qu’elle soit bien conçue.

Afin de manipuler les interfaces tactiles, on peut identifier des “gestures”, c’est à dire les interactions possibles avec l’écran qui ressortent de manière événementielle. Voici les principales :

(Merci Nicolas Chevobbe pour avoir trouvé cette image)

On remarque que certains événements que l’on trouve habituellement sur les interfaces manipulables à la souris n’existent plus. C’est le cas de l’événement du mouseOver (survol des éléments) qui n’est pas détecté (pour le moment en tout cas !)… Concrètement, il ne sera pas possible d’afficher un tooltip d’information lors du survol d’un bouton par exemple.
Sencha Touch permet d’identifier ces gestures et de les intercepter sur les éléments d’interface. A noter que certains peuvent être rattrapés au niveau du navigateur et non dans l’interface elle-même. C’est le cas du Pinch rattrapé sur certains smartphone Android gérant le multi-page, le Spread servant à zoomer ou encore le Hold permettant de faire des actions spécifiques sur certains éléments, tel le copier/coller. Voici un exemple de panel sous Sencha Touch rattrapant des événements :http://dev.sencha.com/deploy/touch/examples/kitchensink/ -> Touch Events.Afin de parfaire l’expérience utilisateur il convient d’adapter l’interface à l’utilisation aux doigts, et il y a certains principes plus ou moins évidents à respecter :S’il est généralement aisé de comprendre l’action que va faire un bouton avec du texte ou une image, ça l’est beaucoup moins lorsqu’il s’agit d’un objet quelconque où il n’y a aucune indication dessus et où il faut faire une action particulière. Par exemple un flick (ou swipe) vers un côté pour switcher l’écran en cours de visualisation, ou lorsqu’il faut faire un double tap pour actionner quelque chose, ou encore faire un drag d’une barre pour développer un panel. Leur découverte arrive plus souvent par le fruit du hasard que naturellement. Il faut donc faire comprendre à l’utilisateur ces choses, via l’utilisation d’indicateurs, ou via la mise en scène de l’information. Par exemple, pour comprendre qu’il est possible de scroller une courte liste d’éléments, l’ajout de dégradés foncés en haut et en bas de cette liste afin de simuler une roue de choix (comme un cadenas à code) fait comprendre à l’utilisateur qu’il s’agit de quelque chose qui tourne.
Sencha Touch propose une multitude d’éléments qui prennent en compte ces nécessités d’affichage. Ces éléments s’inspirent beaucoup du design iOS.

L’espace d’affichage étant généralement restreint, il convient d’afficher uniquement les informations essentielles à l’écran. Mais si elles ne peuvent l’être, il faut faire en sorte qu’elles soient accessibles rapidement et facilement. Pour se faire, dans la plupart des cas un simple scroll suffira, mais suivant la situation il n’est pas forcément judicieux d’opter pour cette solution. Si le contenu à scroller est long et désorganisé, la recherche d’une information de cette manière peut devenir calamiteuse. Il peut donc être préférable de privilégier une succession de petits écrans permettant de découper par étape l’accès à une information donnée. De plus, cela peut éviter de devoir compresser, réduire ou même tronquer les informations vues à l’écran.

Dans le même genre de problématique, l’utilisation simultanée d’un scroll vertical et horizontal, en plus de n’être pas forcément intuitive, rendra la lecture d’une page beaucoup plus fastidieuse.
La meilleure solution est donc de faire en sorte que l’interface soit calée dans la largeur ou la hauteur de l’écran afin de n’avoir qu’un seul scroll. Mais pour que cela soit possible, il faut savoir répondre à la problématique de la résolution d’écran ainsi que celle du changement d’orientation.

Voyons les contraintes liées à la résolution d’écran et les autres contraintes techniques que l’ont peut rencontrer sur les terminaux mobiles. Suivant le modèle de smartphone ou de tablette, plusieurs éléments peuvent varier :

  • la taille de l’écran
  • la résolution de l’écran
  • les performances du mobile
  • les accélérations matérielles de certaines fonctions js/css dans le navigateur
Concernant la résolution d’écran, il s’agit ici d’une forte contrainte. Comme évoqué, les smartphones ont des tailles d’écrans qui varient énormément. Mais même pour une taille d’écran quasiment similaire, le panel de smartphone actuellement sur le marché fait qu’on passe d’une résolution à son octuple. A titre d’exemple, sur un HTC Wildfire, la résolution d’écran est de 320*240 pour une diagonale de 3.2″. Sur un iPhone 4, où l’écran est légèrement plus grand avec une diagonale de 3.5″, la résolution est de 960*640. On a donc un rapport de 1 à 8 entre ces deux smartphones. Concrètement, si un élément est fixé à 200 pixels de large et contenant du texte de 10 pixels de haut, celui-ci sera lisible sur le Wildfire, mais il le sera beaucoup moins sur l’iPhone 4, à moins de zoomer ce qui n’est pas très pratique.
Cela pose donc une réelle problématique. Il ne suffit plus désormais de se limiter à une largeur maximale afin d’être compatible avec la majorité des terminaux…
C’est pour cela que Sencha Touch et jQueryMobile permettent de faire abstraction de ces résolutions. En effet, toutes leurs css sont écrites en taille relatives (contrairement à ExtJS). Du fait, pour un bouton par exemple, celui-ci aura (presque) exactement la même taille sur un écran de Wildfire, ou sur un écran d’iPhone 4. C’est donc un énorme avantage offert par ces frameworks, car en écrivant seulement quelques lignes de code, on obtient quelque chose de visible (et donc utilisable) sur la majorité des terminaux. Sencha va même pousser la chose encore plus loin, en proposant un Cloud permettant l’envoi d’image correctement adaptée à la résolution d’écran. Pour plus d’infos concernant ce Cloud : http://www.sencha.com/blog/previewing-sencha-io/

Mais il ne faudra pas oublier de prendre en compte la taille de l’écran tout de même. Un bouton prenant 90% de la largeur de l’écran sera peut être sur-dimensionné sur une tablette comme l’iPad, alors qu’il aura une taille normale sur un Wildfire… Suivant les cas, il sera peut être judicieux de réorganiser la page suivant la largeur de l’écran détectée.On peut voir aussi une autre problématique liée :  celle de l’orientation de l’affichage, généralement modifiable à la volée suivant la position du smartphone au moment de la lecture. Sencha Touch propose des fonctions et événements de détection de l’orientation de l’écran, et les composants sont conçus pour pouvoir se redimensionner à la volée.

Au delà de la problématique liée aux écrans, il y a celles liées aux performances du mobile.

Les bonnes pratiques voudraient que la page soit la plus épurée possible, aussi bien au niveau des styles qu’au niveau du contenu. Il incombe donc au développeur d’éviter de créer beaucoup d’objets en même temps, et en supprimant du DOM les objets plus utilisés. Cependant, Sencha Touch ne permet pas vraiment de respecter cela, et malgré toutes les optimisations possibles, les performances peuvent être désastreuses. Cela est du en partie à la simulation du scroll. Sencha Touch génère une div prenant la taille de l’écran et génère lui même les scrolls des éléments à l’intérieur de cette div. Ce scroll est en fait une fonction CSS3 (translate3d) qui marche bien sous les terminaux Apple (car accélérée matériellement), mais très moyennement sous les terminaux Android.

De plus, l’initialisation de Sencha Touch est relativement lente. Ainsi, à chaque chargement de page, une page blanche restera affichée durant une ou quelques secondes, et ce même sur un téléphone haut de gamme. Afin d’éviter ce temps de chargement à chaque fois, il est nécessaire de concevoir l’application de telle manière que chaque enchaînement de page s’effectue uniquement en local (en JS) et non via un rechargement complet de la page, pour ne pas détériorer l’expérience utilisateur. L’utilisation en masse de l’Ajax est donc une nécessité. Mais cela a des conséquences directes  : l’éloignement du fonctionnement une ressource = une url (REST) pour le coté client, ainsi que l’impossibilité d’utiliser la touche retour navigateur. ExtJS4 intègre un Ext.util.History permettant de gérer cela, mais il n’existe pas dans Sencha Touch.

Voyons maintenant les contraintes liées à l’OS et/ou navigateur.

Comme évoqué, les navigateurs proposent des solutions natives afin de rendre l’expérience utilisateur la meilleure possible. Parmi elles, le zoom dans les pages, le copier/coller, ou encore les claviers virtuels adaptés au type de l’input html : affichage d’unclavier numérique dans le cas d’un champs de type « number », clavier alphabétique avec une touche ‘@’ supplémentaire pour un champs de type mail, etc… Sencha Touch propose des éléments de saisie utilisant ces types.

Mais certains élément du navigateur peuvent devenir des contraintes, telle la barre d’adresse. Celle-ci a tendance à disparaître lorsque la page est chargée, mais le hasard (ou pas) fait que par moment celle-ci reste affichée en permanence… Avec Sencha Touch, lorsque cette barre se retire quelques temps après le chargement de la page, la page ne se redimensionne pas forcément bien, et lors d’un scroll vers le bas il se peut que ça soit le navigateur qui récupère l’événement et descende la page complète avec la barre d’adresse, au lieu que ça soit l’élément Sencha Touch de la page qui le récupère et scroll sont contenu….
Il y a aussi l’élément de sélection de texte qui parfois s’affiche sur des éléments venant d’être caché…

Après ces notions dans les navigateurs eux-mêmes, il y a celles de leurs compatibilités avec les frameworks. Sencha Touch n’est compatible qu’avec les navigateurs WebKit, et ceux-ci ne sont disponibles que sous Android,  iOS ou BlackBerry 6 pour le moment.Sencha ont publié une Wish list ( http://www.sencha.com/blog/our-wishlist-for-microsoft-ie9-mobile/ ) adressée à Microsoft pour qu’il puissent rendre compatible le framework avec le navigateur internet utilisé dans Windows Mobile 7. Mais la solution la plus réaliste sera probablement la création d’un navigateur web alternatif basé sur WebKit pour Windows phone… jQueryMobile est quant à lui compatible avec ce navigateur.

Attardons-nous sur un point essentiel des navigateurs : leurs connectivités.

Les terminaux mobiles étant par définition mobile, leurs connexions à internet est très aléatoire. En haut débit, bas débit, ou pas du tout connecté, les interfaces mobiles devraient pouvoir s’adapter à tout type de situation. C’est une chose désormais techniquement possible, notamment grâce à HTML5. Il offre la possibilité de stocker des données en local, grâce à une base SQLite intégrée (ou IndexedDb). Cependant, d’après le W3C, la taille de cette base ne peut excéder 5mo mais elle doit pouvoir être étendue après autorisation d’utilisateur.

Sencha Touch permet d’utiliser cette base de manière transparente pour l’utilisateur, puisqu’il propose une source de données spécifique pour les « stores » de données. Voir Ext.data.LocalStorageProxy dans la documentation :http://dev.sencha.com/deploy/touch/docs/

HTML5 offre aussi la possibilité de gérer de manière avancée le cache navigateur, grâce au Cache Manifest. Le Cache Manifest est un fichier texte permettant de dire quels fichiers doivent être stockés en cache navigateur, et quels fichiers ne doivent pas l’être, et permet accessoirement aussi de faire des switchs de fichiers si la connexion est présente ou non.

Grâce à cela, il est possible d’optimiser le chargement du site (et soulager le serveur), puisqu’on peut faire en sorte que les librairies JS ainsi que le code de l’application soient tirés du cache, tout en gardant la possibilité de lancer des requêtes Ajax afin de mettre à jour les données.

Cependant, ce cache peut poser problème : cela reste à travailler et à confirmer, mais le navigateur met en cache toute l’interface de la page, et garde une copie de ce cache en l’associant à l’url de la page.

Exemple :  On met en place le cache sur la page d’accueil d’un site. Lorsqu’on va sur ce site sans être logué, celui-ci affiche non pas la page d’accueil mais le formulaire de login, tout en gardant l’url de la page d’accueil. Lors de la première connexion, le navigateur mettra en cache cette page, contenant donc ce formulaire de login. Lors de la validation du formulaire, une redirection est faite vers la page d’accueil (donc la même url, mais le contenu aura donc changé). Mais c’est là que le problème se pose : le cache associant le formulaire de login à l’url de la page d’accueil, c’est donc celui-ci qui sera affiché, et le vrai contenu de la page d’accueil ne le sera pas.
Attention, cette partie reste donc à étudier et à vérifier.

Pour plus d’infos : http://blog.xebia.fr/2010/12/02/application-hors-ligne-avec-html5-le-manifest/
et : http://www.html5-css3.fr/html5/tutoriel-application-web-offline-html5-cache-manifest

Outre ces outils, il conviendra de gérer convenablement les retours de requêtes Ajax impossibles, timeout et autres, de manière à ne pas perturber l’interface, le problème typique étant l’erreur JS qui bloque complètement la page… A noter aussi que les navigateurs fournissent une fonction relative à la connectivité, pour savoir si la connexion à internet est présente ou non.

Grâce à ces possibilités offertes par HTML5 et exploitées par Sencha Touch, on peut au final avoir une application web se comportant comme une application native. Pour pousser la chose encore plus loin, il est même possible de créer un site web en application native et les proposer sur les Android et Apple stores, via PhoneGap : http://www.phonegap.com/

# Le mot de la fin

On vient de voir les principales contraintes des développements web mobile. Comme détaillé tout au long de cet article, Sencha Touch répond à la majorité de ces problématiques. Mais les principaux défauts de Sencha Touch sont sa lourdeur d’exécution et le fait qu’il soit incompatible avec certains navigateurs, dont le navigateur web de Windows phone 7. Mais malgré cela, Sencha Touch est une référence pour le moment en terme de framework d’interface web pour navigateur WebKit. Ses capacités techniques, son design, sa communauté et surtout les technologies qu’il utilise, font de lui un excellent framework. Cependant, pour une application ayant des interfaces plus légères ne qui ne nécessitent pas une gestion de données poussée, il conviendra peut-être de se tourner vers jQueryMobile, qui lui, est compatible avec le navigateur web de Windows phone 7.