L’objectif d’un tel article est de permettre; d’une part aux participants non technophiles de comprendre et demystifier les principales approches utilisées pour le développement d’applications mobiles, et, d’autre part, aux designers et développeurs de mieux communiquer en fonction de leurs besoins et attentes respectives sur les possibilités propres aux sites webs et applications mobiles.
Sites web mobiles vs applications mobiles
On confond souvent ces deux notions, ou dumoins, on en fait rapidement un amalgame, web et mobilité. Donnons leur un sens et une définition plus précise ce qui nous permettra de mieux prendre en compte la suite de cet article. Dans un premier temps, distinguons les tout simplement en plaçant d’un coté des sites web consultables depuis un navigateur sur appareils mobiles et d’un autre coté des applications autonomes directement installées sur appareils mobiles.
Sites Web mobiles
Le web est, par définition, consultable depuis n’importe quel terminal, mobile ou non, qui possède une connection internet et un navigateur. Rien de nouveau sur cela. Afin de rendre consultable ce site sur appareil mobile, il suffit juste d’anticiper et de proposer aux internautes une ergonomie, et une utilisabilité alternative, qui soit adaptée à des écrans de tailles réduites. Cette proposition d'affichage vient en complément de celles proposées pour des écrans d’ordinateurs de bureau ou celles parfois proposées comme alternative pour l'impression ou les personnes malvoyantes. Ce type de fonctionnalités existait déjà avec la gestion de l'attribut media des liens CSS "all, braille, embossed, handheld, bandwidth, print, preview mode, projection, screen, speech, tty, tv ". Comme nous le verrons plus tard cette ouverture s'est aujourd'hui grandement améliorée avec l'apparition des mediaqueries. Il est à noter qu'en fonction des appareils mobiles, le navigateur utilisé peut être différent et de ce fait utiliser un moteur de rendu différent.
mediaqueries
Dans le cadre du déploiement de contenu de site web sur divers types de plateformes, le w3c recommande l’emploi des requêtes de média (Media Queries). Nous avions vu au début de cet article l'utilisation de l'attibut media lors des liaison de feuilles de styles. Aujourd'hui les requêtes de média permettent d'aller plus loin et s'adaptent de manière interactives avec l'affichage du contenu. Concrètement, ces requêtes permettent d’attribuer, de manière dynamique, diverses feuilles de styles CSS en fonction de certains critères de la plateforme d’utilisation. Les critères de choix sont très bien expliqué dans l’article Media Queries sur le site de Mozilla ou encore plus détaillés sur la recommendation complète du w3c.
Afin de mieux se rendre compte visuellement de la richesse ergonomique que peut apporter l’utilisation des media queries rendez vous sur le site mediaqueri.es qui rassemble une collection de sites les utilisant ou de cet exemple. Chargez le et redimentionnez la fenêtre de votre navigateur, vous constaterez que le contenu se redistribue en fonction de la dimension de la fenêtre.
Applications mobiles
A la différence, une application mobile est ‘embarquée’ et physiquement installée sur l’appareil mobile. Générallement l'application est mise à disposition sur un magasin d'applications tel que Androïd market ou encore appStore. Une fois installée, cette application peut donc être lue à tout moment, et ce, de manière connectée, ou non. De plus, les informations utilisées par l’application peuvent être injectées, ou utilisées, par d’autres applications ou services de cette même plateforme. Attention le langage utilisé pour le codage est différent en fonction de la plateforme et de l’OS utilisés et nécessite donc des compétences tierces en fonction du développement web classique.
Les API de la mobilité
A la différence des sites web lus sur un appareil mobile depuis un navigateur, les applications mobiles permettent d’utiliser pleinement des API directement utilisables par le système des appareils mobiles, comme par exemple :
- La géolocalisation Google
- Utilisation de l’API de Flickr
- Touch-event
- La documentation phone gap
- Multi-Touch
- Code
- Utilisation
- Multitouch Tests
Pull vs Push
Ceci amène à prendre en compte le concept des technologies pull et push que l’on rencontre quotidiennement bien souvent de manière transparente. La première nécessite que l’lutilisateur envoie une requête pour obtenir de l’information, au contraire la seconde pousse cette information dès que celle-ci est disponible, ou accessible, vers le demandeur.
Un exemple très simple est un moteur de recherche qui répond en temps réels, et à l’instant ‘T’, à une requête. Une recherche de type Google en est la pleine illustration, on demande une information celle ci nous est renvoyée... point barre. Maintenant, prennons une autre situation, par exemple lors d’une recherche de logement auprès d’un moteur d’agence immobilière. En fait dans un premier temps nous formattons la requête et ensuite nous recevons des informations de manière continue, dès lors, que des réponses répondent aux critères de notre recherche. Dans le premier exemple nous allons chercher l’information (pull) dans le second, l’information nous est envoyée de manière continue (push).
Les applications du web s’appuient fortement sur ces deux notions… un client web-mail en ligne est pull, nous allons consulter nos mails, un client mail applicatif est push, nous recevons nos mails au fur et à mesure qu’ils sont disponibles.
Avantages vs Inconvénients
Il n’y a ni réel avantage et encore moins d’inconvénient entre un site web ou une application mobile… En fait, tout va dépendre des fonctionnalités proposées à l’utilisateur final et également de la stratégie marketing mise en place pour la distribution de ce contenu.
| D’un coté, s’il s’agit d’un site web, voici quelques notions qui peuvent être retenues : | D’un autre coté, s’il s’agit d’une application embarquée, voici les notions qui peuvent être retenues : |
|---|---|
|
|
Les technologies pour développement de contenus mobiles
Diverses technos - Divers langages
Le développement d’une application mobile nécessite l’utilisation d’un langage tiers qui peut être différent en fonction des plateformes de destination. Ainsi, pour les plate-formes les plus fréquentes, il faut avoir recours aux langages suivant :
| Type de plateforme | Langage |
|---|---|
| Androïd | Java |
| iOs | Objective-C |
| Blackberry | Java |
| Windows Mobile, Windows Phone | C, C++, C# |
| Pour avoir de plus amples informations sur divers autres types de plate-forme, il est préférable de se rendre sur le site de Wikipedia, auprès de l’article Mobile application development - Wikipedia. | |
Solutions alternatives
Cependant, il existe une solution alternative à l'utilisation d'un tierce langage. Parfois, et bien souvent, lorsque l'application à diffuser sur appareil mobile n'est pas à un applicatif très particulier comme un jeu ou une application à traitements complexe, il n’est pas nécessairement utile d'avoir recours, ou à apprendre, un nouveau langage. Et ce à plus forte raison, s'il s'agit d'une refonte d'un site web existant en application mobile.
A cet effet, il est possible, d'utiliser un framework qui a pour fonction d’empaqueter les fichiers de codes HTML, CSS et Javascript, dans une coquille écrite elle en byte code et propre à la plateforme visée.
Ces frameworks de type Phone gap, Titanium (appcelerator) ou encore Rhodes (Rhomobile), permettent de partir d’une base déjà écrite en HTML, CSS et Javascript et de transformer ce contenu en application directement installable sur un appareil mobile. Tous propose une version de base gratuite de l’environnement, mais tous ne propose pas les mêmes services ni les mêmes finalités. Pour en savoir plus, il est préférable de se rendre sur le site de developpez.com avec l’article Frameworks open source pour applications smartphones multiplateformes - developpez.com.
L’avantage principal est l’utilisation des langages déjà très familiers à des équipes développant des sites web. Il est également intéressant à prendre en compte, la réelle simplicité de mise en place surtout lorsque le service visée est proche de celui d'un site web… mais cependant, il faut prendre en considérations certaines limitations en terme de performances et d’applicativité qui peuvent être rapidement atteintes. On ne remplace pas dans ces cas là une véritable application native écrite en C, C++ , Java ou Objective C...
Les langages de la solution alternative
Faisons un rapide rappel sur les langages du web, car cette grande innovation dans le champ du web et de la mobilité reste donc la prise en compte des standards déjà utilisés par la majeure partie des agences web. Les bases restent donc établies sur des langages robustes, et améliorés, du web. Il est vrai également, qu’en ce qui concerne les dernières versions de ces langages, celles-ci ne sont pas proposés par l’industrie mais deviennent utilisés et façonnées par les besoins de la proffession.
HTML 5
Il ne s’agit pas là de la cinquième version du langage, mais d’une approche encore plus sémentique, encore plus structurée, répondant encore plus aux attentes des développeurs de sites et applications web. Cette version est encore en brouillon et devrait être en version finale vers 2022. Mais qu'à cela ne tienne, html 5 a un sens et il est l'heure de s'ennivrer. Que se passe-t-il donc sous le capot ?
- L’ajout de nouvelles balises telles que <nav>, <header>, <footer>, etc… permet de prendre lieu et place des anciennes techniques de structuration de contenu de la page, <div class="nav">, < div class="header">, < div class="footer">, etc… .
- La présence de balises telles que <canvas>, <svg>, <audio>, <video> permet de compléter les contenus par des éléments plus interactifs et multimédias tout en respectant l’aspect non propriétaire et standard des langages du web.
- L’adaption interactive des balises telles que <details>, <command>, <summary>.... ou le renforcement d’attributs tels que role="", data="" ou encore aria="" permet de préciser et affiner le caractère des métas données propre à un enrichissement sémantique et accessible des contenus.
- La gestion des données locales qui sont en quelques sortes une alternatives aux fameux cookies et qui permettent surtout d'une part de ne donner l'accès qu'au client mais également d'autoriser un volume de stockage bien supérieur. L'utilisation reste tributaire de l'activation de javascript mais ouvre correctement la porte au développement d'application hors ligne.
Il reste à savoir comment les outils de navigations les intègrent et les supportent avec leur moteurs de rendu respectifs. Voir HTML5 Demos and Examples de Remy Sharp, ainsi que la liste des diverses API disponibles depuis HTML5.
CSS 3
Aujourd’hui l’ensemble des nouveaux navigateurs proposés par les éditeurs prennent en compte les spécificités des CSS3 en proposant une déclinaison une déclaration propriétéaire des principales propriétés CSS, par exemple la description :
proprieteCSS: 8px;
… peut être complétée par les descriptions complémentaires et propriétaires suivantes propres à chaque éditeur :
-webkit-proprieteCSS: 8px; -moz-proprieteCSS: 8px; -o-proprieteCSS: 8px; -ms-proprieteCSS: 8px; proprieteCSS: 8px;
Juqu'à présent l'utilisation de code propriétaire pouvait être déconseillé, mais là cela permet au contraire une mise en application directe et progressive des CSS3. Donc, il est possible d'utiliser des transformations ainsi que des transitions... d'ajouter des filtres type ombres portées, des boites à coins arrondies, ou encore des boites avec différentes images d'arrières plan, bref la liste est longue ... et bien sur, cerise sur le gâteau, le principe de continuellement rester web-standard compatible, plein text avec une pure séparation contenu /contenant et d'éviter ou dumoins de limiter l'utilisation de Javascript afin d'apporter une mise en forme et un affichage très souple et quasi sans contrainte.
Par contre, l’ajout de code Javascript permet d’obtenir une couverture plus élargie en intégrant nottament les vieilles versions d’Internet explorer. Par exemple CSS3 Progressive Internet Explorer permet moyennant la ligne de code ci-dessous, et le fichier .htc téléchargeable sur le site, d’inclure les versions de 6 à 9 d’IE :
behavior: url(/PIE.htc);
CSS3 intègre également la confirmation de la règle @font-face, apparu timidement en CSS2, qui permet dorénavant d’utiliser toutes sortes de polices 'non web'. De ce fait, cela permet d’enrichir la panoplie des interfaces de contenu sans devoir avoir recours à des subtilités de remplacement image ou d'alternative telles que Cufon,Typeface.js, or SIFR.
JavaScript
Bien que lors de la dernière décade Javascript eut été un frein à l’utilisation d’application DHTML, il est aujourd’hui omni présent sur la majeure partie des sites web et s’est largement démocratisé sur l’ensemble du web. Son intégration discrète (Unobtrusive JavaScript) se doit quand même d’être prise en compte afin de ne pas pénaliser les utilisateurs qui n’auraient pas choisit d’activer ce langage sur leur navigateur.
L’utilisation de plus en plus fréquente de technologie comme AJAX rend les contenus dynamiques plus simple à utiliser au sein des interfaces et améliore considérablement l’expérience utilisateur et l’ergonomie du web en général. Le DOM scripting permet de réécrire à la volée le contenu des pages et l’utilisation de librairies telle que prototype, scriptaculous, spry, jquery, mootools, dojo, etc… en simplifie la mise en place. Pour en savoir plus à ce sujet rapprochez vous sur ce même site de l’article Les diverses librairies Javascript.
Comme nous venons de le voir, il existe une pleïade de librairies Javascript disponibles, toutes répondent plus ou moins au même attentes et il y va de la sensibilité de chacun pour opter pour l’une ou l’autre. Cependant, aujourd’hui, la librairie jQuery reste majoritairement utilisée par la communauté de développeurs du web. Elle se décline sous trois formes. La librairie jQuery elle-même qui représente le cœur des fonctionnalités et reste utile et nécessaire avec la majorité des extensions et plug-ins disponibles. Elle est secondée par jQuery UserInterface une librairie spécialement dédiée aux composants d’interface d'application web en général, cette librairie évolue assez souvent et intègre au fur et à mesure des plug-ins comme dernièrement Auto-complète. Une troisième solution vient compléter le tableau par jQuery mobile, une partie prenant en compte tous les éléments d’interface orientés appareils mobiles et enfin jQtouch pour le développement spécifique d’application mobile.
Il reste toujours possible de venir complèter ces librairies par des extensions, ou des plug-ins externes, comme par exemple qTips pour réaliser des infos bulles personnalisés, maphilight pour gérer plus finement la gestion des cartes et les survols détournés, chosen pour affiner la représentation des objets de formulaire ou encore checkbox qui facilite la personnalisation des cases à cocher.
Il existe d’autres librairies spécifiques aux sélecteurs javascript autre que jQuery et qui de par leur petite taille deviennent un complément ou une substitution potentielle dans certaines situations :
AJAX
Bien que cette technologie soit intégralement prise en compte par l’utilisation des prinicpales librairies et notament la librairie jQuery, il n’en reste pas moins qu’AJAX peut fonctionner de manière autonome. En résumé, on peut dire qu’AJAX permet le chargement d’informations au travers du protocole http sans devoir recharger l’intégralité de la page et de manière asynchrone. Ses utilisations les plus connues, ou répendues, reste Google Maps ou encore le classique autocomplète des champs de formulaires.
Récapitulatifs
Nous avons donc affaire à un véritable tryptique de construction, HTML pour la structure, CSS pour l’affichage et Javascript pour la gestion des diverses interactions, qu'elles soient système ou utilisateur. Chacun fonctionnant de manière indépendante et pleinement modulaire ce qui rend le système très pérène et évolutif. Le plus simple reste de se rapprocher de cet exemple qui parle de lui-même.