Tous les navigateurs acceptent HTML5 et CSS3 mais tous ne comprennent pas leurs nouvelles fonctionnalités. L’usage de nouveaux attributs HTML5 ou de nouvelles propriétés CSS3 ne bloquera pas votre navigateur, ce dernier les ignora tout simplement. Un avantage indéniable qui nous permet d’utiliser dès aujourd’hui HTML5 et CSS3 même si certains de nos utilisateurs ne disposent pas encore de navigateurs les supportant. Comme je le précisais dans l’article Osez renoncer aux vieux navigateurs, il ne faut pas avoir peur d’utiliser des fonctionnalités HTML5 et CSS3 car des comportements dégradés natifs existent. Quels sont les comportements dégradés natifs acceptables ? Comment profiter d’une fonctionnalité HTML5 ou CSS3 si son comportement dégradé n’est pas acceptable ? Comment pallier l’absence de support des nouvelles API JavaScript si le navigateur ne les possède pas ?

Les comportements dégradés natifs

Des comportements dégradés existent nativement pour la majorité des nouveautés HTML5 et CSS3 lorsque celles-ci ne sont pas supportées par le navigateur. Prenons deux exemples pour illustrer comment les vieux navigateurs se comportent.

HTML5

Certaines fonctionnalités HTML5 sont des évolutions de fonctionnalités existantes, c’est notamment le cas pour les formulaires. Prenons l’exemple des nouveaux types de champs de saisie qui permettent de spécifier un champ de saisie en tant que champ de saisie e-mail, téléphone, date, etc. Cette spécification permet d’avoir un clavier spécifique sur les mobiles et une validation adéquate coté navigateur. Ci-dessous un exemple d’un champ de saisie de type email sur Firefox pour Android 4.

Code original :

1

<input type="email">

Code compris par un navigateur ne supportant pas les formulaires HTML5 :

1

<input type="text">

Si le navigateur ne comprends pas le type (email dans notre cas), le type par défaut utilisé sera text. Votre formulaire sera donc totalement fonctionnel sur un ancien navigateur, votre utilisateur ne bénéficiera pas d’un clavier spécifique ni de la validation coté client mais il pourra soumettre le formulaire. Tout le monde peut utiliser votre formulaire et vos utilisateurs qui utilisent un navigateur récent bénéficieront de fonctionnalités intéressantes sans la moindre charge de développement.

CSS3

On bénéficie également de ces comportements natifs sur les CSS3.

Si vous voyez les coins arrondis, vous êtes un utilisateur génial qui utilise un navigateur récent. Sinon mettez à jour votre navigateur.

Style original :

1
2
3
4
5
6

.boite-arrondie {
  border-radius: 5px;
  padding: 5px;
  background: #ddd;
  border: 2px solid #777;
}

Style utilisé par un navigateur ne supportant pas la propriété CSS3 border-radius :

1
2
3
4
5

.boite-arrondie {
  padding: 5px;
  background: #ddd;
  border: 2px solid #777;
}

Si une propriété n’est pas comprise, elle est tout simplement ignorée par le navigateur et les coins sont rectangulaires. Sans les CSS3, il nous faudrait 1 à 6 images afin de reproduire ce rendu, ce qui en terme de performance n’est pas anodin ni en terme de complexité de code ajouté. Est-ce inacceptable de se priver des coins arrondis sur les anciens navigateurs ? Est-ce pertinent de passer du temps et augmenter la complexité du code ? Il est important de se poser ces questions pour les nouvelles fonctionnalités CSS3 qui vous intéressent.

Ce comportement est notamment très utilisé par les navigateurs qui préfixent les propriétés lorsque l’implémentation n’est pas finale. L’utilisation des préfixes sur certaines propriétés n’est pas utile lorsque les navigateurs supportent la propriété sans préfixe depuis plusieurs versions. Des sites comme Can I Use et CSS3 Generator vous permettront de voir si les préfixes sont indispensables. Ils sont inutiles pour border-radius mais impératifs pour les gradients :

1
2
3
4
5
6
7

.fond-degrade {
  background: -moz-linear-gradient(top, #1e5799 0%, #7db9e8 100%);
  background: -webkit-linear-gradient(top, #1e5799 0%,#7db9e8 100%);
  background: -o-linear-gradient(top, #1e5799 0%,#7db9e8 100%);
  background: -ms-linear-gradient(top, #1e5799 0%,#7db9e8 100%);
  background: linear-gradient(top, #1e5799 0%,#7db9e8 100%);
}

Et si ce comportement dégradé n’est pas acceptable ?

Il peut arriver que le comportement dégradé ne soit pas acceptable et qu’il faille envisager une autre solution. Une approche pourrait être de s’interdire d’utiliser une nouvelle fonctionnalité car 30% des navigateurs de vos utilisateurs ne la supportent pas. Une mauvaise approche car on nivelle par le bas et on se prive de fonctionnalités intéressantes pour l’utilisateur et le développeur. L’utilisateur profite d’une meilleure expérience utilisateur. Le développeur simplifie et réduit son code car une partie est implémentée par le navigateur.

L’approche Graceful degradation

L’approche Graceful degradation consiste à profiter des nouvelles fonctionnalités et proposer une solution de contournement lorsqu’elles ne sont pas disponibles. Pour cela, la librairie JavaScript Modernizr expose de nombreuses méthodes permettant de détecter le support d’une fonctionnalité  HTML5 ou CSS3. On peut ainsi utiliser un Polyfill ou encore, si on décide de ne pas implémenter du tout cette fonctionnalité dans ce cas, alerter l’utilisateur que la fonctionnalité n’est pas disponible. Un Polyfill est un plugin qui fournit une fonctionnalité que le navigateur devrait posséder nativement. Une longue liste de Polyfill est référencée sur GitHub par Modernizr. Ci-dessous un exemple de champ de saisie textuel avec le nouvel attribut placeholder (texte d’aide dans le champ de saisie lorsque celui-ci est vide).

Code HTML :

1

<input type="text" placeholder="exemple de placeholder" />

Code JavaScript permettant de gérer le non support de l’attribut placeholder :

1
2
3
4
5

// si le navigateur ne supporte pas placeholder
if (!Modernizr.input.placeholder) {
  // ajout du comportement avec un plugin jQuery
  $('input[placeholder]').placeholder();
}

L’avantage de cette technique est d’isoler le code lié à la solution de contournement. Ceci nous permettra de le supprimer sans crainte lorsque vos utilisateurs n’utiliseront plus de navigateurs ne supportant pas cet attribut.

L’utilisation de la cascade pour les CSS

En CSS3, certaines propriétés ont de nouvelles valeurs possibles. Il est alors possible de définir deux fois une propriété avec deux valeurs différentes. Prenons par exemple une boite avec un fond semi-transparent :

Si votre navigateur est récent, le fond de ce paragraphe est vert et transparent. Sinon il est rouge vif.

1
2
3
4

.fond-avec-transparence {
  background-color: #ff0000;
  background-color: rgba(0,255,0,0.5);
}

Les navigateurs ne supportant pas CSS3 ne comprendront que la première valeur donc le fond sera rouge. Quant aux navigateurs supportant CSS3, ils comprendront les deux valeurs. Ils appliqueront donc la dernière valeur rencontrée pour la propriété ce qui nous donnera un fond vert avec une transparence de 50%.

Des comportements dégradés pour les nouvelles APIs ?

HTML5 apporte de nouvelles APIs JavaScript (Web Storage, Geolocation, etc.). Ces APIs sont directement utilisables sans import puisque exposées par le navigateur. Des erreurs JavaScript seront donc levées si vous les utilisez alors que votre navigateur ne les possède pas. Aucun comportement dégradé n’existe par défaut, c’est à vous de tester la disponibilité de ces APIs avant de les utiliser. Comme pour les balises HTML5 ou le CSS3, Modernizr permet de tester facilement la disponibilité de ces nouvelles API pour proposer une solution alternative ou non. Un exemple ci-dessous avec l’API localStorage :

1
2
3
4
5

// si le navigateur supporte le localStorage
if (Modernizr.localstorage) {
  // stockage d'une valeur dans le Web Storage local
  localStorage.setItem("clé", "valeur");
}

Aucune raison de ne plus utiliser HTML5 et CSS3

Des solutions existent pour pallier l’absence de support HTML5, parfois simple et fiable, parfois trop complexe ou trop impactant sur les performances du client. C’est un choix à prendre sur la solution de contournement lorsque vous décidez d’utiliser HTML5 et CSS3. Le site HTML5 Please pourra vous aider à prendre ces décisions en vous donnant le support des fonctionnalités et en vous conseillant sur leur utilisation. D’après les statistiques de StatCounter du mois de janvier, près de 70% des français utilisent un navigateur récent qui supporte relativement bien HTML5 et CSS3. Profitez des nouvelles fonctionnalités HTML5 et CSS3, des comportements dégradés natifs et ne prévoyez de solution alternative que si c’est indispensable.

Suggestion d'articles :

1. Osez renoncer aux vieux navigateurs
2. OCTO à Paris Web 2010 pour un atelier HTML5
3. HTML5, offline et sécurité

La crise économique, une opportunité à ne pas rater !
L’actualité financière et les perspectives économiques mettent sous pression les budgets des DSI. Les coups de rabot budgétaires ont le mérite de mettre en évidence les sujets perçus comme les plus importants et urgents.
Arbitrer entre maintenir à flot l’activité métier ou la transformer est un choix difficile pour chaque Direction : « run the business or change the business » ? Les investissements SI sont soumis également à ce dilemme.
Néanmoins, les entreprises qui sauront mettre à profit cette période troublée pour se transformer sauront en bénéficier plus tôt. Alors que celles, qui ne le feront pas, n’auront pas eu le temps de le faire avant la prochaine crise, qui les paralysera à nouveau.
Dans une logique de recentrage des investissements SI, la question est donc de bien identifier les sujets qui permettent d’obtenir une réduction significative des coûts opérationnels et de rentabiliser à court terme la transformation des activités. Il faut bien l’admettre, cet exercice nécessite une bonne dose de créativité et d’innovation.

En période de crise, faut-il ignorer les innovations technologiques ?
La question n’est pas tant la technologie, mais plutôt si les signaux de changement concernent la technologie. L’année 2012 sera-t-elle technologique ? Nous en sommes convaincus en considérant les évolutions suivantes :
• L’émergence du « big data ». Le buzzword BigData, qui existe depuis 10 ans, prend une forme réelle aujourd’hui dans les télécommunications, la banque et le commerce en ligne pour exploiter les immenses quantités de données clients (tickets de communication, opérations bancaires, parcours internet, etc.) pour mieux les adresser.
• L’émergence des nouveaux canaux – Smartphone et Tablette – de distribution et de relation client, qui passent du statut d’outils de communication d’entreprise à celui de canal de distribution et de relation client, à l’instar des sites Internet il y a 10 ans. Les investissements sur ces canaux vont devoir se pérenniser et les applications mobiles devront s’inscrire durablement dans les stratégies multicanales des entreprises.
• L’analyse et la simulation deviennent une réponse nécessaire pour faire face aux bouleversements des contextes économiques et financiers. Mes marges sont-elles toujours positives en cas d’une augmentation des taux de financement du Besoin en Fonds de Roulement ?
Ces 3 évolutions majeures entrainent avec elles des défis technologiques importants, qui nécessiteront toute l’attention des meilleurs talents de la DSI.
Le management des SI ne pourra plus se résumer à un alignement sur les processus métiers. Il devra reconnecter l’innovation technologique et ses opportunités aux enjeux et aux perspectives business. Et ça, c’est une bonne nouvelle !
La maitrise des usages et des opportunités technologiques appliquées au business deviendra la clef qui permettra de faire la différence en sortie de crise ou avant le commencement d’une nouvelle.

Sur quels sujets technologiques investir ?
Les sujets technologiques sont nombreux. Il convient d’aborder la réflexion sur l’usage métier avant de se lancer dans une veille « à tout-va ». A notre avis, les sujets suivants seront incontournables :
• L’écosystème NoSQL qui sert de fondation au Big Data : batch distribué Hadoop, bases de données spécialisées (contenu, graph, clef/valeur, multidimensionnelle, grille), traitement de flux d’évènements (CEP)
• La convergence entre grille de données et grille de calculs, qui fournit une nouvelle génération de serveurs d’applications capables de supporter les systèmes mutualisés de très grande taille
• La programmation parallèle pour tirer profit des évolutions matérielles des multi-core, GPU et grid computing et rendre abordable les systèmes de calculs et de simulation
• L’industrialisation des développements Smartphones et Tablettes pour iOS, Android, Windows Phone et Blackberry tout en alliant l’excellence de l’expérience utilisateur à la pérennisation des investissements sur des plateformes techniques encore en pleine mutation
• La multiplication des connexions des objets physiques à l’Internet (smartphone, tablette, table, TV, véhicule, …) va permettre de suivre et de faire interagir le monde de l’information avec celui des actifs physiques, sans intermédiaire humain.
• L’évolution des infrastructures Cloud, qui devront renforcer leurs solutions permettant l’intégration entre « SI Cloudifié » et SI existant et le durcissement des systèmes de sécurité applicative au fur et à mesure du déploiement de nouveaux services complexes.
• L’hégémonie de HTML5 sur les technologies IHM et l’impérative nécessité de maitriser industriellement les technologies Javascript

La contrainte : aller vite
Indépendamment des sujets choisis, la pression budgétaire augmente celle sur les délais d’obtention de résultats rapides. Il devient donc impératif d’être efficace dans l’identification des usages sectoriels et la maitrise des nouvelles technologies.
La R&D OCTO est orientée dans ce sens, en structurant transversalement l’analyse des opportunités technologiques et l’identification des usages dans les secteurs : Banque, Assurance, Télécoms, Media, Internet, Energie, Distribution et Services.

Suggestion d'articles :

1. La meilleure façon de rater son projet grâce à Maven2

Introduction

Le développement d’applications pour terminaux mobiles (iPhone, iPad, Android, Blackberry, Windows Phone, Nokia Symbian, Samsung Bada…) se heurte à la fragmentation des technologies de développements: environnement iOS/Objective-C pour l’iPhone et l’iPad, SDK Java spécifique pour Android, J2ME pour Symbian, etc.

Deux approches possibles lorsque l’on débute un projet d’application ciblant plusieurs de ces plateformes sont de développer une application pour chacune d’elle, ou de développer un site Web compatible.

Dans le premier cas, l’inconvénient concerne bien évidemment le coût des développements. Dans le deuxième, on sera limité en richesse de l’application par les possibilités du Web.

Ce fut l’objet d’un précédent article sur notre blog: http://blog.octo.com/debat-web-apps-vs-natif/.

Entre ces deux approches se situe une offre assez fournie de solutions de développement multi-plateforme, proposées par des éditeurs proposant leurs propres plateformes d’exécution et leurs outils de développement.

Parmi celles-ci, nous nous sommes concentrés dans cet article sur PhoneGap et Titanium Mobile, qui sont aujourd’hui parmi les plus abouties et sont représentatives des deux principales approches de développement multi-plateforme: l’utilisation des moteurs de rendus Web pour PhoneGap, et la translation de code source vers la plateforme cible pour Titanium.

Présentation des solutions

PhoneGap

Nitobi, l’éditeur de PhoneGap, a annoncé son rachat par Adobe le 3 octobre 2011. Cela confirme l’intérêt que l’on peut avoir envers cette solution, même si ce rachat surprise apporte une certaine incertitude sur l’avenir de PhoneGap.
PhoneGap est un outil open-source, et devrait d’ailleurs rejoindre la fondation Apache.
Le principe de PhoneGap est de fournir des API JavaScript aux navigateurs Web standards, permettant d’appeler des fonctionnalités natives non disponibles autrement: accéder à l’appareil photo, à l’accéléromètre, au système de fichiers…
Cela nécessite d’embarquer le code source HTML/CSS/JS dans une application native, grâce au composant permettant d’inclure une vue Web dans une application, disponible dans chaque SDK.

Titanium

Développé par Appcelerator qui vend du support et des formations sur Titanium, c’est également une solution libre.

Le principe de Titanium est de fournir une machine virtuelle JavaScript permettant d’accéder au système natif, et ainsi de développer des applications natives mais en JavaScript. C’est la promesse d’applications plus réactives et à l’expérience utilisateur plus proche du natif que celles basées sur des pages Web, comme PhoneGap.

Points communs

L’intérêt principal de l’utilisation d’une plateforme de développement multi-plateforme comme PhoneGap et Titanium Mobile réside en 2 points:

• pouvoir déployer l’application sur les magasins (AppStore, Android Market…) afin de bénéficier de ce canal de distribution et de communication. Cela est réellement assuré par ces deux outils;
• réduire les coûts de développements en mutualisant du code. Cela est assuré par ces deux outils à condition de bien les utiliser et de limiter la part des développements spécifiques à chaque plateforme et donc de se limiter aux fonctionnalités supportées « out of the box ». On rogne donc sur l’expérience utilisateur et la richesse fonctionnelle.

Comparaison

Plateformes supportées

Notre avis:

En pratique, les développements PhoneGap nécessitent des adaptations pour chaque plateforme, dont les capacités et l’expérience utilisateurs diffèrent fortement. Etant donné l’état du marché (avec l’écrasante domination de l’iPhone, d’Android et de Blackberry), on ciblera généralement ces 3 plateformes uniquement. C’est ce que l’on a pu constater dans la plupart des cas où une entreprise ciblait initialement toutes les plateformes: l’augmentation du coût pour les supporter au fur et à mesure rendait cela impossible et finalement, au maximum, seules les 3 ou 4 principales étaient vraiment adressées.
Concernant Titanium, le support de Blackberry est encore récent et disponible uniquement sous Windows, alors que la plupart des développeurs mobiles sont sous Mac (pour l’iPhone). Cela est dommage mais on espère que ce sera bientôt résolu.
Pour cibler tous les terminaux mobiles à moindre coût, le meilleur moyen reste de réaliser un site Web simple, qui permet de diffuser de l’information mais ne permet ni de fournir des fonctionnalités avancées (appareil photo, etc.), ni de proposer une expérience utilisateur riche, ni d’être visible sur l’AppStore.

Richesse de la plateforme

Notre avis:

Titanium est indéniablement plus riche fonctionnellement et fournira une apparence plus proche du natif, ce qui est en général l’objectif des concepteurs d’applications.
PhoneGap est dans l’absolu plus limité en terme de fonctionnalités, et on doit concevoir les écrans comme des pages Web et non des écrans natifs. C’est d’ailleurs une erreur que l’on retrouve souvent sur les projets mobiles utilisant des technologies Web: il ne faut surtout pas tenter de reproduire des comportements natifs, mais plutôt viser des comportements Web performants.
Les deux plateformes sont extensibles, Titanium plus facilement que PhoneGap, mais nous déconseillons globalement d’aller dans cette direction car cela devient très coûteux à maintenir (on estime en général à 20% la part maximale de code spécifique tolérable), et nécessite en outre encore plus de compétences que de faire des applications natives spécifiques à chaque plateforme.

Plateforme de développement

Notre avis:

On remarque l’utilisation de plus en plus large de JavaScript, un langage décrié par ses côtés peu structuré et trop tolérant. Il est nécessaire, pour développer ce type d’applications, de se former profondément à JavaScript et de connaître les design patterns de structuration/modularisation du code dans ce langage, qui existent mais sont souvent mal connus des développeurs.
C’est d’ailleurs le principal objet de la formation à Titanium donnée par leur expert Kevin Whinnery, que nous avons eu la chance de suivre à l’UpdateConf 2011.
De manière globale, l’environnement de développement de Titanium est mieux intégré et plus documenté.

Productivité des développement

Notre avis:

Titanium fournit un environnement de développement « clé en main » et performant, là où PhoneGap nécessite d’installer et configurer soi-même plusieurs environnements.
La productivité est clairement côté Titanium aujourd’hui.

Gestion des déploiements

Notre avis:

L’automatisation du packaging et de la livraison des applications sur les différentes plateformes (magasins publics type AppStore ou comptes privés « in house ») est un véritable enjeu concernant la productivité des développements et le coût global d’un projet. C’est d’ailleurs pour cela qu’OCTO propose Appaloosa, qui facilite la distribution en entreprise d’applications mobiles dans des stores privés.
L’outil PhoneGap Build (compatible uniquement avec les applications PhoneGap), qui vient d’être ouvert en version finale, était une véritable nécessité.

Synthèse

Les points forts de PhoneGap sont donc aujourd’hui son support de plus de 6 plateformes, et le fait qu’il utilise au maximum les technologies standards du Web.
Ses points faibles concernent ses limitations fonctionnelles et sa moindre richesse d’IHM du fait qu’il n’utilise pas les composants natifs, ainsi que son manque d’outillage de développement.

Les points forts de Titanium sont sa richesse fonctionnelle et graphique, ainsi que la productivité de son environnement de développement.
Son point faible concerne le peu de plateformes supportées.

Conclusion

En conclusion, on a pu voir que Titanium est globalement plus productif et fournit plus de fonctionnalités que PhoneGap dans le but de développer des applications mobiles multi-plateformes. On le préfèrera en général, si l’on ne doit pas supporter plus que iOS + Android + BlackBerry.
Au-delà du choix de l’outil, notre conseil majeur restera d’utiliser les outils pour ce qu’ils savent faire, et éviter de « tordre » leur usage pour leur faire faire autre chose ou de manière différente. Cela s’approche des problématiques bien connues d’utilisation trop personnalisée de progiciels, qui rend rapidement très coûteuse la moindre évolution.

Et d’ors et déjà, le choix de la technologie de développement multi-plateformes doit aussi se faire par-rapport aux applications Web HTML5 qui apportent de plus en plus de fonctionnalités et viennent sérieusement concurrencer les approches natives et hybrides, et les solutions Web existantes comme les moteurs de rendus (BkRender, Wokup) et les nombreux frameworks Web pour mobiles (par exemple Sencha Touch.

La problématique du développement mobile multi-plateforme est loin d’être encore résolue, et nul doute que nous reviendrons encore dessus rapidement car c’est un enjeu fort pour les entreprises aujourd’hui.

Suggestion d'articles :

1. Applications natives ou web HTML5 pour mon mobile ?
2. Ce que jQuery Mobile nous apprend sur le Web Mobile
3. Le terminal mobile et usabilité ou comment réveiller le canal web et les applications desktop

HTML5 et CSS3 sont désormais au cœur des discussions sur le développement Web. La question du support des navigateurs est souvent évoquée notamment pour le cas Internet Explorer. Les clients demandent encore souvent de supporter Internet Explorer 6 (IE6) alors que ce navigateur a plus de 10 ans. Si ce navigateur a été apprécié à sa sortie, il est devenu un cauchemar pour les développeurs Web tant il contient de nombreux bugs et ne respecte pas des standards comme CSS2. Est-il important de supporter les vieux navigateurs ? Y a-t-il des cas où on pourrait s’en passer ? Doit-on se focaliser exclusivement sur les navigateurs récents ?

Les vieux navigateurs font de la résistance

Parts de marché des navigateurs en France en août 2011 (source: gs.statcounter.com)

Sorti en mars 2009, IE8 reste le leader des navigateurs en France avec 21 % de parts de marché. Cependant les quatre navigateurs suivants sont tous sortis il y a quelques mois et supportent de nombreuses fonctionnalités HTML5 et CSS3. On observe que près de 60 % des internautes français utilisent un navigateur récent qui supporte les dernières normes du W3C. Malheureusement il reste des utilisateurs sur les navigateurs IE6 (1,35 %) et IE7 (4,55 %) dont on connait la médiocrité du support de CSS2 et le nombre relativement important de bug d’implémentation. Pour information, ces navigateurs sont sortis respectivement le 27 août 2001 et le 18 octobre 2006.

En entreprise, les statistiques sont très différentes puisqu’en règle générale, un navigateur est imposé et souvent il s’agit d’Internet Explorer. IE6 est encore très présent même si des clients ont décidé de migrer leur parc vers IE8 en occultant totalement IE7. Mais rares sont les grandes entreprises qui autorisent l’utilisation d’un autre navigateur.

Internet Explorer, un navigateur trop lié à Windows

La plupart des navigateurs récents peuvent être installés sur une multitude de versions d’OS. Ce qui n’est pas le cas d’Internet Explorer où il existe une véritable dépendance entre Windows et le navigateur de Microsoft. Ainsi il est impossible d’installer IE9 sur Windows XP et IE10 ne sera disponible qu’à partir de Windows 7. Comme la part de marché de Windows XP est proche des 30%, ce n’est pas étonnant de voir le navigateur IE8 encore autant  utilisé.

Cette dépendance est relativement problématique pour les entreprises car si elles souhaitent migrer vers une version récente d’Internet Explorer, elles doivent envisager également une migration de la version de Windows. C’est la raison pour laquelle toutes les entreprises ne migrent que vers IE8 puisqu’elles n’ont pas encore migré vers Windows 7 pour d’autres raisons. La migration d’un système d’exploitation implique d’autres tests de non-régression à faire pourtant totalement décorréler de ceux d’un navigateur.

Ce lien fort est également pénalisant pour Microsoft car les supports de Windows et du navigateur sont liés. Le navigateur initial de Windows XP étant IE6, la firme de Redmond doit supporter IE6 jusqu’à la fin du support d’XP, c’est à dire jusqu’au 8 avril 2014. Près de 13 ans de support !

Doit-on encore supporter les vieux navigateurs ?

Sur Internet, la diversité des navigateurs utilisés par les internautes est importante. Des standards ont été établis par le W3C afin de rendre le Web accessible à tous quelque soit le navigateur utilisé. Les entreprises souhaitent encore qu’IE6 et IE7 soient supportés par leurs projets Web car ces vieux navigateurs sont encore présents dans leurs visites. Malheureusement supporter ces navigateurs implique de nombreuses contraintes :

• Beaucoup d’efforts d’adaptation car ils n’implémentent pas correctement les standards. De nombreux développeurs estiment que cela représente un coût supplémentaire de 30%. Sur mon projet actuel dont l’IHM est très riche, on a estimé que ce surcoût approchait les 50%. Ce navigateur nous obligeait à créer beaucoup de CSS et JavaScript spécifiques à IE6.
• Des performances catastrophiques dès que votre application Web possède un peu de JavaScript ou de modifications importante du DOM. Des scintillements et des ralentissements nuisibles à l’utilisateur sont observables sur ces vieux navigateurs. Pour information, il faut 20 secondes à IE6 pour réaliser SunSpider (test de performance JavaScript) alors que Chrome 14 et Firefox prenaient environ 250 ms. Sur Peacekeeper (test de performance rendu, manipulation DOM, etc.), IE6 n’obtient que 627 points alors que Firefox 7 et Chrome 14 obtiennent respectivement 5573 et  10109 points.
• Impossibilité à utiliser HTML5 et CSS3 qui ajoutent de nouvelles possibilités et permettent des gains de productivité. Je vous invite à regarder la session USI HTML5 : quelles perspectives pour les entreprises ? pour en savoir plus.

De nombreuses contraintes avec ces vieux navigateurs pour très peu d’utilisateurs. Face à ce constat, les grands du Web ont fait leurs choix :

• Google ne supporte Internet Explorer qu’à partir de sa version 8 sur ses produits Google+, Gmail, Google Docs et qu’à partir de sa version 7 sur Google Calendar et YouTube
• Facebook ne supporte plus IE6 depuis plus d’un an
• l’administration du CMS WordPress ne supporte plus IE6 depuis mai
• Amazon n’assure plus la compatibilité avec IE6 des espaces d’administration de ses vendeurs

À moins que vous ne souhaitiez dépenser 30% en plus sur votre projet, arrêtez de supporter ces vieux navigateurs. Vous pouvez soit bloquer totalement l’accès comme le fait Google+ ou simplement prévenir l’internaute qu’il utilise un navigateur non supporté. Mais dans tous les cas, invitez vos utilisateurs à mettre à jour leur navigateur.

N’ayez pas peur d’utiliser des fonctions HTML5 et CSS3, des comportements dégradés sont prévus nativement. Si un navigateur ne comprends pas une propriété, il ne s’en préoccupe pas. Par exemple sur un vieux navigateur, un cadre aux coins arrondis aura les coins carrés ou encore un champ de saisie de type email deviendra un simple champ de saisie de texte. Ces comportements dégradés natifs feront l’objet d’un futur article.

Et si le navigateur de mon entreprise est IE6 ?

Le navigateur de nombreuses grandes entreprises est encore IE6 pour diverses raisons :

• Certaines applications de leur SI ne fonctionnent que sur ce navigateur car les standards n’ont pas été respectés lors de sa réalisation.
• Mettre à jour le navigateur imposerait de faire de nombreux tests de non-régression sur les applications du SI.
• Et bien d’autres encore.

Cependant si certaines anciennes applications d’un SI retardent la migration d’Internet Explorer, ce n’est pas une raison pour pénaliser les nouvelles applications en endettant les développements et en privant les utilisateurs de fonctionnalités intéressantes. Internet Explorer n’est pas le seul navigateur, il est possible d’installer un navigateur récent tel que Firefox ou Chrome sur les postes des employés afin qu’ils bénéficient des avancés d’HTML5 et CSS3. Cela ne les empêchera pas d’utiliser IE6 pour les applications ne fonctionnant que sur cet ancien navigateur.

Une autre solution si vous ne souhaitez vraiment pas installer de navigateurs supplémentaires est le plugin Google Chrome Frame. Il permet d’utiliser le moteur de rendu du navigateur de Google dans IE6 à IE9. Les employés lancent ainsi le même navigateur mais suivant les applications accédées, le rendu sera géré par Internet Explorer ou le plugin Chrome Frame. Contrairement à l’installation d’un nouveau navigateur, l’installation de ce plugin ne nécessite plus les droits administrateurs.

Une autre alternative aux problèmes de droits administrateurs réside dans l’utilisation des Portable Apps de Firefox ou Chrome pour Windows. Ce système permet d’être autonome et de disposer d’un navigateur récent même sur une clé USB. Mais attention, les Portable Apps ne se mettent pas à jour automatiquement, il faut alors les télécharger à chaque nouvelle version pour être à jour. Cette solution n’est à utiliser qu’en dernier recours.

Faites le choix

Vous devez oublier de supporter IE6 et IE7 afin de profiter des avancées des standards du Web. Les grands du Web l’ont fait, les grandes entreprises françaises doivent aussi faire ce choix. Ne forcez pas vos employés à utiliser des vieux navigateurs qu’ils n’utilisent plus chez eux depuis longtemps, permettez leur d’utiliser un navigateur rapide avec des fonctionnalités avancées. N’endettez plus vos applications Web avec du code spécifique pour maintenir les vieux navigateurs. Ne vous bridez plus sur les fonctionnalités de vos applications Web sous prétexte d’être compatible avec les vieux navigateurs.

Suggestion d'articles :

1. Tous les navigateurs acceptent HTML5 et CSS3

Débat : Web Apps VS Natif

Lundi 5 septembre 2011 se tenait la Update Conf 2011 à Brighton, nous y étions ! Nous avons notamment assisté à une table ronde (« geek ninja battle » pour les jeunes) sur le thème « Web Apps VS natif » qui réunissait :

Matt Gemmel (Développeur iOS, auteur du fameux client Twitter)
Jeremy Keith (Web developer)
Seb Lee-Delisle (consultant)
Martin Beeby (évangéliste Microsoft)
Kevin Whinnery (évangéliste Titanium)

Débat mené par Aral Balkan organisateur de la Updateconf

Le sujet a déjà fait couler beaucoup d’encre, cette table ronde a été l’occasion de résumer les différences entre ces deux approches du développement mobile et de vulgariser des considérations complexes. Cet article propose une synthèse de ces discussions.
On notera que ces discussions ne traitaient pas de l’aspect stratégie mobile mais d’une comparaison technique entre ces deux approches du développement mobile.

Mais avant tout deux définitions s’imposent :

Application native : Application conçue spécifiquement pour une plateforme en utilisant le SDK propre à celle ci.
Web app : Application réalisée via un site Web optimisé pour mobile

Résumé de l’intervention sur les Web Apps mobile :

Le principal bénéfice d’une Web App est de créer une application « universelle » : l’application ainsi produite a la possibilité de s’exécuter sur n’importe quel device, aussi bien smartphones que feature phone.
Un autre point à considérer est la durée de vie des applications : une application Web sera toujours accessible, par exemple les tous premiers sites Web sont toujours utilisables. En revanche une application native est liée à une plateforme et aux devices qui l’utilisent, sa durée de vie est donc au maximum celle de la plateforme, et souvent des problèmes de rétrocompatibilité limitent sa durée de vie à quelques années.

En se basant sur ce constat d’universalité et de durée de vie des applications, la discussion prenait parfois une tournure quasi idéologique : en effet réaliser une application native s’inscrit dans le « flow », et ne fait que passer. Tandis que produire une application Web permet de participer au « stock » et enrichit le Web pour les générations futures.

Pour revenir à des considérations plus pratiques il faut tenir compte des limitations actuelles de l’approche Web App. Les navigateurs des téléphones sont très hétérogènes et ont chacun une implémentation différente des standards du Web :

- Différences de capacités entre le navigateur d’un feature phone et celui d’un smartphone
- Différence de comportement entre les navigateurs de différents smartphones pour la même fonctionnalité

Cette contrainte se heurte au fait que les applications mobiles sont devenues de plus en plus évoluées en terme d’interface. Une mauvaise pratique consiste à chercher à faire une Web App avec une interface reproduisant le comportement d’une application native : d’une part c’est techniquement complexe et on perd rapidement la compatibilité avec de nombreux navigateurs. Mais il faut également tenir compte du fait que chaque plateforme cherche à se différencier en proposant une ergonomie native différente. Dans ce contexte faire un site Web avec une ergonomie native pose deux problèmes :

- Si on essaye de reproduire l’ergonomie propre à chaque plateforme on recommence à faire des développements spécifiques à chaque plateforme
- Si on reproduit le comportement d’une application iPhone sur chaque plateforme, le résultat est décevant pour les utilisateurs des autres plateformes.

La bonne pratique en terme d’interface pour les Web App consiste à reprendre les standards d’ergonomie du Web et d’adapter l’interface aux différents téléphones selon deux axes :

- Adapter l’interface à la taille de l’écran du téléphone/Smartphone
- Adapter les fonctionnalités de l’application aux possibilités techniques du navigateur.

Ce dernier point peut s’avérer complexe, la recommandation pour qu’un site Web puisse offrir une expérience optimum sur chaque device consiste à faire du « progressive enhancement » :

Il s’agit de partir d’une approche orientée document (HTML sans JavaScript), bien gérée par tous les navigateurs, et qui assure un ensemble minimum de fonctionnalités quelque soit l’utilisateur qui consulte l’application.
Puis aller vers une approche orientée interaction et comportement, en adaptant le site aux possibilités disponibles sur le navigateur qui consulte l’application.

Les intervenants mettaient également en garde contre le fait de faire du spécifique pour chaque navigateur : on retombe dans le même travers que de faire du spécifique pour des devices. A la place il est conseillé d’optimiser l’application pour des fonctionnalités : choisir une implémentation standard, et n’activer cette fonctionnalité que si le navigateur la supporte.

Il faut noter que si aujourd’hui il est possible de reproduire en Web la plupart des fonctions d’une application native (utilisation offline, stockage de donnés, GPS, etc.), certains points restent aujourd’hui impossibles, typiquement l’accès aux données du téléphone (annuaire, calendrier, etc.).

Notre avis : il faut également tenir compte du manque de maturité de l’HTML5. Aujourd’hui démarrer une application Web embarquant une base de donnée locale, GPS et utilisation offline avec synchronisation des données comporte une part importante de R&D. Ces fonctionnalités existent dans les applications natives depuis plusieurs années et sont aujourd’hui totalement maîtrisées.

Résumé des interventions sur le développement natif sur mobile:

Chaque plate-forme possède ses spécificités en terme d’interface et crée son identité notamment sur ces différences d’ergonomie.
Les applications natives permettent de proposer une expérience totalement intégrée à la plate-forme et de tirer parti de ses spécificités :
On a en effet accès non seulement aux données du téléphone (calendrier, contacts, etc.) mais on peut également proposer au sein de son application une ergonomie intégrée à celle du téléphone.

Un point qui est rapidement soulevé est la question de la « proximité » avec l’OS.

De part leur nature les applications natives n’ont aucune couche d’abstraction avec le téléphone, ce qui les rend mieux intégrées :

Cette expérience utilisateur plus proche du device peut s’avérer déterminante dans un environnement fortement concurrentiel : si sur chaque plateforme une Web App est en concurrence avec plusieurs applications natives qui proposent le même service mais avec une expérience spécifique, comment se démarquer ?

Notre avis :
Nous partageons cette analyse concernant l’importance de l’expérience utilisateur et nous pensons fortement à la citation de Phil Libin, CEO d’Evernote : « We could probably save 70% of our development budget by switching to a single, cross-platform client, but we would probably lose 80% of our users. »

Néanmoins on remarque qu’il y avait le même débat avec la JVM 10 ans auparavant. La leçon retenue est que la « distance » avec l’OS n’est pas déterminante en soit, ce qu’il faut prendre en compte c’est ce que les technos Web permettent de faire.

Les intervenants reconnaissaient que développer et maintenir une version spécifique de l’application pour chaque plateforme est complexe lorsque l’on souhaite multiplier les OS ciblés. C’est dans ce dilemme entre le coût et la valeur que de nombreuses solutions hybrides ont vu le jour, tels que PhoneGap et Appcelerator. Nous publierons prochainement un article détaillant ces approches hybrides.

Autres considérations abordées :

Monétisation :

Le mode de distribution des applications natives via des « stores » a fait ses preuves en tant que solution rentable permettant de générer du profit. Les perspectives business attirent un nombre important de développeurs et d’entreprises à réaliser des projets pour ces plate-formes et pousse l’innovation.

N’est ce pas une faiblesse des Web Apps que d’être privées de store ? Comment faciliter la conversion sur une Web App et réaliser l’équivalent du « one click purchase » ?

Deux arguments ont été évoqués pour défendre le modèle de distribution des Web Apps :

- Effectivement sur le Web le taux de conversion est plus faible, mais cela peut être compensé par une base d’utilisateur plus grande et l’absence de frais d’intermédiaires (les stores prennent un pourcentage sur les achats allant jusqu’à 30%)

- On voit arriver des stores pour les Web Apps, via les navigateurs (Chrome se dirige déjà dans cette direction avec son Web Store)

Notre avis : les intervenants n’ont pas évoqué le fait que les stores servent aussi de vitrines pour les applications et facilitent la découverte du service.

Innovation :

Il est possible de faire de plus en plus de choses via les Web Apps, mais les possibilités offertes en natif progressent également, le gap technologique entre le natif et les Web Apps ne va-t’il pas perdurer ?

On a déjà rencontré cette même situation avec Flash et HTML : l’histoire montre qu’il y a un seuil minimum à atteindre pour que les technologies Web répondent à l’essentiel des besoins. Passé ce stade la valeur apportée par les améliorations de la plate-forme ne justifie plus les contraintes qu’elle implique. Aujourd’hui un grand nombre d’applications sur les stores pourraient déjà être faites en Web.

Conclusion :

Au travers des interventions on a eu un bon résumé de la situation actuelle du développement mobile et cela en 45min, on regrette néanmoins que le débat soit resté assez dogmatique et trop général. Le sujet n’y est probablement pas pour rien, « Natif VS Web Apps » : chercher à élire la meilleur approche dans l’absolue n’a pas beaucoup de sens. On aurait préféré partir de certains cas d’usage relativement cadrés pour illustrer les différentes approches et ce qu’elles impliquent.

Par exemple :

- Délivrer du contenu (blog, prise de note)
- Apporter un service (service public de consultation, bourse en ligne)

D’autre part le débat technique entre l’approche native et web ne suffit pas pour faire un choix. Avant tout il faut définir une stratégie mobile plus globale et poser des questions telles que :

Pourquoi je veux faire du mobile ? (se démarquer de la concurrence par l’innovation ? Trouver de nouveaux business models ? )
A quelle population je m’adresse ?
Quel est le positionnement de mon canal mobile par rapport à mon canal web ?
Etc

Ce sont les réponses à ces questions ET une bonne connaissance des différences techniques entre web app et natif qui permettront de faire le bon choix.

Le propos de ce billet est de faire un petit point sur les assauts passés et présents contre les standards du Web. Il est inspiré par l’article de Chris Anderson dans Wired : “The Web Is Dead. Long Live the Internet”. Anderson y développe l’idée suivante : on utilise de plus en plus des applications embarquées, plutôt qu’un navigateur, pour accéder aux contenus sur Internet (son article présente d’ailleurs une courbe très évocatrice. Suivez le lien…). Rappelons que Chris Anderson a fait la keynote d’ouverture de l’USI 2010 en juillet dernier.

L’ère AOL / World Online

Comme chacun sait, les standards du Web (HTTP/HTML) ont été créés par Tim Berners Lee au début des années 90. On doit la montée en puissance des navigateurs et sites Web respectant ces standards d’abord aux scientifiques et universitaires, puis aux geeks.
Au milieu des années 90, le Web a atteint le grand public. Une première fronde a alors été menée par des ISP comme AOL et World Online. Ces ISP proposaient un ensemble de  logiciels propriétaires masquant les standards : kit de connexion, logiciel de chat, forums fermés, etc.  Cette sortie des standard se justifiait alors par le faible niveau de maturité des utilisateurs issus du grand public : une simplification était donc la bienvenue.
Ces fournisseurs d’accès ont eu la tentation d’enfermer leurs utilisateurs dans un écosystème propriétaire et contrôlé. Les opérateurs mobiles ont eu plus tard la même démarche avec les portails Wap. Heureusement, tout cela a rapidement volé en éclat dès lors que les internautes ont compris l’intérêt d’un Web ouvert.

L’ère IE / Flash

En 2003, le Web était dominé par Internet Explorer qui disposait de plus de 98% de parts de marché toutes versions confondues. De fait, beaucoup d’agences Web créaient des applications pour Internet Explorer, plutôt que des sites Web.

Par ailleurs, le format Flash était largement utilisé, parfois au delà de ses aptitudes au multimédia et au vectoriel. Ainsi, des pages qui auraient pu être développées à l’identique en HTML se trouvaient codées dans un format propriétaire dont la source était inaccessible à la communauté des développeurs. HTML était alors doublement en danger comme l’explique très bien Mark Surman dans sa session USI 2010 : “How the Web was Won, and other usefull stories”.
La relance de la concurrence dans les navigateurs, en particulier grâce à Firefox, a remis le standard HTML en selle. De plus, avec les évolutions de HTML5, Flash est maintenant remis en cause (cf. les attaques virulentes de Steve Jobs contre ce format).

L’ère des AppStores

Le Web est aujourd’hui menacé dans sa version mobile : en effet, de nombreux fournisseurs de contenus préfèrent proposer des applications embarquées plutôt que des WebApps sur les téléphones et tablettes.
L’argument pour le développement d’une application embarquée est souvent le besoin de gestion du mode déconnecté et de géolocalisation. Pourtant HTML5 les gère. Ainsi beaucoup d’applications de l’AppStore d’Apple pourraient, à mon sens, être développées à l’identique en HTML5 et bénéficier d’une portabilité entre plateformes mobiles. Les éditeurs de contenus éviteraient ainsi N développements pour iPhone, Android, Windows Phone, Blackberry, etc.

Les raisons du recours aux plateformes de développement embarqué sont généralement les suivantes :

• HTML5 est un standard immature, encore en cours d’écriture. Cependant, les chose avancent à grand pas : voir ce billet sur jQuery Mobile.
• Les éditeurs de contenu voient dans les AppStores un nouveau territoire où il faut être présent : un catalogue organisé par rubriques qui permet une promotion ciblée. Il faut cependant noter que la visibilité des applications diminue rapidement avec la taille des AppStores. Avec 200 000 applications chez Apple, il est de plus en plus difficile d’arriver en première page de l’AppStore. De fait, on parcourt de moins en moins le catalogue, et on revient à la recherche, comme sur le Web…
• Du point de vue de l’utilisateur débutant, Il est simple de rechercher et installer des applications à partir d’un catalogue. Cette pratique me rappelle les débuts du Web en 1996. J’essayais alors de tester tous les sites Web qui sortaient, et des annuaires comme Yahoo ou Lycos avaient l’ambition de tous les classer dans un catalogue. Le principe du catalogue a vite atteint ses limites pour le Web, il est probable qu’il les atteindra pour pour le mobile. Et les utilisateurs mobiles utiliseront un jour un moteur de recherche et des signets comme sur leurs PC.
• Pour les développeurs, il est rapide de développer des applications embarquées, grâce à des outils très productifs, en particulier dans le cadre d’interfaces tactiles. De plus, les AppStores ont permis à quelques privilégiés de se constituer un salaire : cette opportunité fait rêver de nombreux développeurs.

Le contexte devrait évoluer avec la maturité de HTML5 et l’expérience des utilisateurs.
Par ailleurs, l’effet “applications payantes versus sites Web gratuits pour les mêmes contenus” est très séduisant pour les fournisseurs de contenus. Néanmoins, son succès réside plus dans l’efficacité des plateformes de micropaiements que dans le caractère embarqué des applications. On pourrait imaginer que l’on parvienne à proposer les mêmes micropaiements dans le cadre d’applications Web : c’est le projet du Mozilla Appstore. Les utilisateurs pourraient alors sortir du côté fermé des AppStores (cf. la politique d’Apple) de même qu’ils sont sortis des environnements fermés des AOL & portails Wap.

J’ai personnellement la conviction que l’on verra un retour au standard HTML pour le mobile d’ici 5 ans.

Suggestion d'articles :

1. La complémentarité entre les standards de gestion des processus IT
2. L’émergence de standards faciliterait le recours aux PaaS
3. Autres standards de gestion des processus IT

Cet article s’intéresse aux principes de développement qu’implémente la librairie jQuery Mobile pour offrir des sites Web adaptés aux terminaux mobiles, afin d’en tirer des enseignements pour nos propres développements mobiles, utilisant cette librairie ou non.
Nous entendrons ici par Web Mobile les sites et applications Web pour les tablettes et tous les téléphones portables supportant le Web, depuis les premières version de Symbian S60 jusqu’aux derniers iPhone et Android.

Qu’est-ce que jQuery Mobile?

jQuery Mobile constitue la version optimisée pour les mobiles de la librairie jQuery, une des librairies JavaScript les plus populaires, permettant d’enrichir des sites Web classiques. La version 1.0 est disponible depuis peu en version alpha.
Sa documentation, elle-même adaptée aux mobiles, est disponible ici: http://jquerymobile.com/demos/1.0a1/
Les concepteurs de jQuery ont eu besoin de créer une version spéciale pour les terminaux mobiles, car ce marché a des caractéristiques particulières. Ce sont elles que nous allons explorer ici.

Un marché fragmenté

L’image ci-dessus représente un échantillon des résolutions de mobiles disponibles sur le marché aujourd’hui. Il manque de nombreux (iPhone 4, les nouveaux Windows Phone…), sans parler des tablettes tactiles, et le marché évolue si vite qu’il y en aura sans doute déjà de nouveaux encore quand vous lirez cet article.
Cela afin d’illustrer le fait que le support des terminaux, à la fois par-rapport aux résolutions d’écrans, mais aussi par-rapport aux différents navigateurs, aux différents OS, sans parler des versions ce chaque, constitue un défi inédit pour les développeurs Web.
Les développeurs de jQuery Mobile partent du principe qu’il ne faut négliger aucun terminal. Pour commencer, ils se sont focalisés sur une dizaine de navigateurs, en plus des navigateurs standards, et autant d’OS, avec pour chacun plusieurs versions.
Ils les ont alors comparés suivant 2 critères:
- est-ce que le navigateur supporte les media queries, qui permettent d’adapter la feuille de style suivant l’écran de l’utilisateur?
- et si oui, a-t-il une part de marché suffisante pour que les développeurs de la librairie garantissent une qualité optimale?

Cela leur a permis de classer ces navigateurs et OS dans 3 catégories, A, B et C:
http://jquerymobile.com/gbs/

• catégorie A: jQuery Mobile apportera la meilleure utilisabilité possible grâce à des manipulations de style et de JavaScript
• catégorie B: jQuery Mobile tentera d’apporter la meilleure utilisabilité, mais les développeurs devront être plus vigilants au risque de bugs
• catégorie C: jQuery Mobile n’apportera aucune transformation de style ou JavaScript mais le site restera entièrement fonctionnel en étant rendu en pur HTML.

Cela permet à un développeur utilisant jQuery Mobile de s’abstraire de cettre problématique, tout en étant sûr de toucher un maximum d’utilisateurs possibles. Et peut nous donner un point de départ pour aborder ce problème pour nos propres développements sans jQuery Mobile.

Progressive enhancement et graceful degradation: des réponses à l’hétérogénéité?

jQuery Mobile utilise ces deux principes de développement. Que signifient-ils et comment jQuery Mobile les utilise-t-il?

Progressive enhancement

Le principe de « progressive enhancement » consiste pour le Web à tout d’abord s’attacher à respecter la sémantique du HTML pour assurer un contenu accessible et fonctionnel aux navigateurs les moins puissants et aux utilisations limitées (utilisation des balises de headers, navigation possible sans souris ou sans clavier, etc.). Puis à enrichir l’application avec une couche de mise en forme utilisant des CSS, et enfin une couche évènementielle en utilisant JavaScript voire AJAX, mais tout en restant retro-compatible.

Pour une application développée avec jQuery Mobile, cela consiste à développer son site Web uniquement en HTML et CSS, puis à ajouter l’attribut « data- » (apporté par HTML5) dans un composant, pour lequel on veut appliquer des améliorations via jQuery Mobile.

Le respect de ce principe par l’architecture globale de jQuery Mobile permet à un site développé avec de fonctionner sur des navigateurs ne supportant pas JavaScript ou CSS, ou quand leur support a été désactivé. A ce propos, Yahoo compte 2% de ses visiteurs aux Etats-Unis qui n’ont pas JavaScript, soit 6 millions par mois (cf. http://developer.yahoo.com/blogs/ydn/posts/2010/10/how-many-users-have-javascript-disabled/). A vos statisques!

Graceful degradation

Différant sur la mise en oeuvre du principe de « progressive enhancement », celui de « graceful degradation » consiste à tenter par défaut, de fournir le meilleur élément possible, puis si cela ne fonctionne pas, à fournir une version « dégradée ».
Cela est typiquement le cas avec l’affichage de vidéo en HTML5, ou pour les navigateurs récents on cherchera à diffuser une vidéo avec la nouvelle balise « video », et si le navigateur ne la supporte pas alors on la diffusera avec un plug-in Flash.
Par exemple si le navigateur supporte le type d’input HTML5 date permettant d’afficher un calendrier pour sélectionner une date dans un formulaire, alors on l’utilisera, sinon on affichera soi-même un calendrier en JavaScript, sinon on laissera un champ de type texte… C’est la notion de « fallback »: avoir toujours une solution de secours.

En ce qui concerne jQuery Mobile, la documentation fait référence à ce mécanisme, notamment pour le cas des nouveaux éléments de CSS3 qui ne sont pas tous supportés par tous les navigateurs et qui sont ignorés par les autres. Cela est illustré dans un exemple donné à la page http://jquerymobile.com/2010/10/jquery-mobile-alpha-1-released/.

Les performances ne sont pas une option

Dans le monde mobile, de bonnes performances sont encore plus nécessaires que dans le Web de bureau. En effet, si dans le Web classique l’enjeu est principalement de ne pas perdre des utilisateurs (cf. http://www.slideshare.net/stubbornella/pourquoi-la-performance-presentation: Yahoo perd de 5 à 9% de visiteurs pour 400ms de temps de chargement supplémentaire), sur le Web mobile les latences réseaux, la perte de connexions, les faibles performances des terminaux et les limitations des navigateurs peuvent empêcher votre site de fonctionner.

Pour améliorer les performances, les concepteurs de jQuery Mobile ont réduit au maximum la taille de la librairie (seulement 9k) et limité la dépendance aux ressources externes, notamment en utilisant des Gradient CSS3 pour les dégradés de fonds de pages plutôt que des images, et en utilisant des sprites CSS pour les icônes de la page.

Tactile ou souris?

Ou stylet? Ou encore autre chose? La multiplication des moyens d’interaction entre l’utilisateur et la machine nous contraint à les supporter tous. Or ceux-ci ne sont pas supportés de la même manière suivant les navigateurs.
Par exemple lorsque l’utilisateur pose le doigt sur l’écran: Fennec, la version mobile de Mozilla Firefox, envoie l’évènement « moztouchdown » alors que Safari Mobile, sur iPhone, enverra un « touchstart »…

Pour simplifier le travail des développeurs en masquant les différences entre les navigateurs, jQuery Mobile fournit une API normalisée. Celle-ci est encore un peu pauvre certes, mais ils prévoient de l’enrichir rapidement.

Accessibilité, encore et toujours

L’initiative du W3C sur l’accessibilité concerne aussi le développement mobile. JQueryMobile tente de suivre au mieux ces directives, notamment pour les lecteurs d’écrans pour malvoyants.
Par exemple, l’iPhone fournit un outil appelé VoiceOver lisant le contenu des pages Web, de mêmes qu’une loupe ou un système d’amélioration des contrastes.
La prise en compte de l’accessibilité lors des tests et du développement de l’application est donc toujours nécessaire pour le Web Mobile.

HTML5 est déjà là! (du moins en partie)

On l’a vu, jQuery Mobile utilise les « media queries » et l’attribut « data » (et peut-être d’autres) qui font parti des nouveautés de HTML5.
S’ils n’hésitent pas à les utiliser, c’est que les navigateurs de classe A (selon leur classement) les implémentent.
HTML5, un des buzz-words du moment est donc déjà bien en partie présent sur nos mobiles, ce qui est rassurant pour l’avenir du développement Web, dans le but d’offrir de nouvelles fonctionnalités et une standardisation de celles-ci.

Conclusion

Etudier ce que font des acteurs majeurs doit nous sensibiliser aux problématiques du développement Web pour terminaux mobiles aujourd’hui, et nous donner des idées pour les résoudre.
Quant à l’évaluation de la librairie jQuery Mobile elle-même, et de ses concurrents (SensaTouch, Iui…), cela pourra faire l’objet d’un prochain article.

Crédits

Photos sous licence Creative Commons de Jorge Correa et Toms Baugis.

Suggestion d'articles :

1. Optimiser les performances de vos applications web sur mobile
2. Applications mobiles multi-plateformes: les approches PhoneGap et Titanium Mobile
3. Applications natives ou web HTML5 pour mon mobile ?

L’édition 2010 de Paris Web, l’évènement français des acteurs du Web, a eu lieu du jeudi 14 octobre au 16 octobre. Trois jours de sessions passionnantes dont voici les principaux thèmes abordés.

Du Web partout

Notre consommation du Web a énormément évolué : on y accède depuis nos ordinateurs de bureau, nos téléphones mobiles, nos tablettes, nos téléviseurs, etc. Et cette multiplication des canaux ne va pas s’arrêter !

Matt May, responsable de l’accessibilité chez Adobe, a insisté dans sa présentation sur le fait que nous devons intégrer l’accélération des changements et des nouveautés. Il précise qu’il « faut accepter l’entropie et concevoir de manière universelle ». Cela passe par le support des divers terminaux, mais aussi par la offrir la capacité aux utilisateurs d’utiliser nos applications dans toutes les situations : connexions à faible débit ou intermittentes (téléphones mobiles), utilisateurs handicapés, terminaux sans souris, etc.

Christophe Porteneuve nous a présenté l’état de l’art du développement Web sur smartphone aujourd’hui. Une grande richesse de frameworks, de pratiques et de possibilités, que le plus difficile aujourd’hui est de faire un choix entre tous les outils et toutes les possibilités qu’ils offrent. Tandis qu’en parallèle, les membres du groupe de travail sur le Web mobile du W3C standardisent les bonnes pratiques du Web mobile, afin d’uniformiser et donc faciliter les développements sur ces plateformes. La grande force du Web reste son ouverture et nous nous devons de bien le connaître pour en prendre le meilleur à chaque instant.

Le Web accessible pour tous

L’accessibilité est régulièrement mise de côté dans les projets Web. Denis et Aurélien Levy nous ont pourtant démontré qu’il est possible en 15 minutes d’établir un bilan des principales failles d’accessibilité de nos sites Web pour pouvoir l’améliorer, en se basant sur les recommendations du Web Content Accessibility Guidelines produit par le W3C. On vérifiera notamment que tout est utilisable en mode texte (même les images), que les balises de structure de page sont bien utilisées (les headers, les tables et les listes), que la navigation au clavier correspond à la logique du site, etc. Améliorer l’accessibilité ne coûte parfois que peu de temps et permet au moins de faire bénéficier nos sites Web à plus de personnes.

L’accessibilité doit également être une préoccupation de tous au quotidien, comme nous l’a montré Tanguy Loheac, expert accessibilité chez Sanofi-Aventis. Sur un projet de refonte de l’application des Ressources Humaines utilisée par tous les salariés, l’accessibilité n’était pas une option. Pour mener à bien ce projet, il lui a fallu impliquer tous les acteurs du projet, et sensibiliser les concepteurs et les développeurs.

Un travail de longue haleine, qui ne sera sans doute jamais totalement achevé, mais qui doit nous concerner tous. Et comme le disait Matt May, concernant les handicaps, il ne faut pas oublier que l’âge moyen des internautes va sans cesse augmenter, et que nous pouvons tous être victime d’un handicap, même pendant une courte période.
Est-il encore normal en 2010 qu’un employé ne puisse plus travailler parce qu’il s’est cassé le poignet et que l’application Web qu’il utilise au quotidien n’est pas utilisable au clavier?

La révolution HTML5 et CSS3

HTML5 n’est pas que la cinquième version de la norme HTML. C’est une véritable révolution, qui permet de passer d’un monde de sites Web à un monde d’applications Web. Le navigateur devient une véritable machine virtuelle multi-plateforme, fonctionnant hors-ligne, accédant aux périphériques (GPS, appareil photo,accéléromètre, système de fichiers…), manipulant de la 3D… Paul Rouget, de Mozilla, a fait vibrer l’amphithéâtre grâce à une démo impressionnante, comprenant de la modélisation 3D calculée en temps réel avec WebGL, de l’audio, le tout accompagné de Web sockets, et cela d’une fluidité inattendue. Une émotion d’une rare intensité, et uniquement avec des technologies Web.

Des fonctionnalités de HTML5 sont déjà utilisées par de nombreux développeurs. Et rester compatible avec les clients qui ne le supportent pas n’est pas un problème car les outils existent, comme nous l’a montré Jean-Pierre Vincent.

CSS3 est la deuxième grande évolution de langages Web, et Dave Shea, un des designers Web de référence dans le monde, auteur de CSS Zen Garden, nous en a montré les impacts. CSS3 apporte de nouvelles fonctionnalités facilitant le travail d’intégration, et qui permettent par exemple de limiter l’utilisation d’images ou de JavaScript pour les animations. Cela a donné lieu à un débat passionné lancé par Francis Chouquet, demandant si cela ne pousserait pas les web designers à concevoir les sites directement avec CSS3, sans passer par la case Photoshop…

Du JavaScript côte serveur ?

Cela vous surprend ? C’est normal. Bien que Quentin Adam, lors de sa session, nous a rappelé que LiveScript, le moteur à l’origine du premier moteur JavaScript, avait au départ été développé par Netscape pour leur serveur HTTP.

Cette nouvelle tendance s’accompagne du développement de serveurs JavaScript, les plus populaires étant Ajax Push Engine et surtout Node.js. Ils sont particulièrement intéressants pour le web « temps réel », car ils permettent de développer très rapidement des Web sockets, comme nous l’a démontré Jonathan Blanchet.

En revanche, passer d’un environnement serveur Rails, PHP, Java ou autre, à un serveur JavaScript nous paraît encore peu justifié, d’autant plus que l’écosystème est encore assez pauvre et artisanal.

Conclusion

Les orateurs nous l’ont montré : tout va très vite, le Web est plus que jamais actif et ses acteurs bouillonnent d’idées. La grande nouveauté est la promesse de pouvoir bientôt l’utiliser pour tout et sur tous les types de supports.
Il sera alors de notre devoir de faire les bons choix sans perdre de vue certains objectifs qui doivent rester des valeurs du Web : l’accessibilité et la capacité d’être utilisé partout et par tous.

Enfin, nous tenons à remercier les organisateurs de Paris Web pour leur superbe travail et leurs efforts pour que leur conférence soit en temps réel accessible à tous : casque audio avec traduction en français des présentations en anglais, transcription en sous titrage et traduction en langue des signes française.

A l’année prochaine, et restez à l’écoute de @ParisWeb pour les futurs évènements.

Quelques liens

Les vidéos des anciennes éditions, et bientôt de celle de 2010, sont disponibles gratuitement ici: http://videos.paris-web.fr/
La plupart des slides sont également disponibles sur Slideshare: http://www.slideshare.net/tag/parisweb

et quelques photos de l’évènement et du staff, merci à vous!

Suggestion d'articles :

1. Les grandes tendances de Devoxx 2011
2. Trois jours à QCon London 2010 : Tendances et Confirmations
3. OCTO à Paris Web 2010 pour un atelier HTML5

La cinquième édition de la conférence Paris Web aura lieu du 14 au 16 octobre, abordant les thèmes de l’accessibilité Web, du design numérique et des standards ouverts. OCTO y sera activement représenté par Mickaël Morier et François Petitit qui animeront le samedi l’atelier HTML5 pour mon ordinateur et mon mobile, dont voici le détail :

la révolution HTML5 est en marche à la fois pour les navigateurs de bureau et pour les navigateurs mobiles. Pourtant, peut-on développer les mêmes applications web HTML5 sur toutes les plateformes, et de la même manière? Nous verrons à-travers des exemples concrets, les possibilités offertes par les deux types de plateformes, et ce qui peut les différencier. Nous développerons une petite application dans l’esprit des Coding Dojo, ce qui permettra à tous de prendre le clavier et coder une partie de cette application. Vous serez les bienvenu(e)s!

Victime de son succès, Paris Web affiche déjà complet… Nous espérons donc que vous avez déjà réservé vos places pour vous y rencontrer!

Suggestion d'articles :

1. Paris Web 2010: les grandes tendances
2. OCTO au Paris-Web 2009
3. Applications natives ou web HTML5 pour mon mobile ?

Un article récent publié sur InfoQ abordait la sécurité de HTML5 dans sa globalité, et notamment sur des attaques concernant les nouvelles fonctionnalités de navigation hors-ligne de HTML5.

Quelles sont donc ces fonctionnalités et qu’en est-il vraiment des risques associés?

Rappel historique

La seule possibilité pour une application web HTML/JavaScript de stocker des données dans un navigateur était jusqu’à récemment de les stocker dans un cookie. Limités en taille (la spécification exige seulement des navigateurs qu’ils puissent gérer 4096 octets par cookie!), parfois refusés par les navigateurs et nettoyés régulièrement, et assimilés à des logiciels espions par les antivirus, leur fiabilité restait très limitée.
D’autres technologies à base de plugins, comme Adobe Flash, utilisaient des procédés propriétaires ne répondant pas aux normes du W3C (les « super cookies« ) et très critiquées pour leur opacité (manque de contrôle pour l’utilisateur pour savoir quelles informations sont stockées ou les supprimer). En 2007, Google a sorti Google Gears qui a permis de stocker des données dans le navigateur sous la forme d’une base de  données relationnelle et de disposer en local d’un cache de ressources (cf. les articles publiés par Olivier Mallassi sur le blog OCTO).

Cette nouveauté a permis le développement de véritables applications web stockant un nombre conséquent de données en local, permettant un fonctionnement déconnecté de l’application et une meilleure réactivité en évitant d’inutiles aller-retours avec le serveur. L’exemple le plus marquant étant naturellement le client mail de Google, Gmail, qui innovait en plus avec le « flaky mode » où l’utilisateur naviguait en permance en local, utilisant les ressources stockées dans son navigateur, et où l’application mettait à jour ces données quand une connexion à Internet était disponible. Cependant, Google Gears restait un produit de Google, et son implémentation sur les navigateurs n’était pas garantie.

Le groupe de travail sur HTML5, auquel contribue fortement Google, a alors déclaré vouloir inclure dans la spécification HTML5 des normes de stockage local s’inspirant de Google Gears. En parallèle, début 2009, Google a d’ailleurs arrêté le développement de Google Gears, au profit de l’implémentation de la norme HTML5.

Cette normalisation contraint déjà les navigateurs web à implémenter ces mécanismes, entraînant à coup sûr une démocratisation de leur utilisation par les applications web.

Quels sont les risques liés au stockage local?

Parmi les sites précurseurs dans l’utilisation de stockage local se trouvent les webmails. Les données stockées dans  le navigateur sont donc les courriers électroniques de l’utilisateur, qui sont des données très critiques par-rapport au respect de la vie privée, sans parler des cas où certains mails contiendraient des données plus sensibles, comme un numéro de compte bancaire…
Il convient donc impérativement de s’assurer qu’aucun tiers ne puisse accéder à ces données.

Quels sont les mécanismes de stockage local?

HTML5 prévoit deux systèmes de stockage de données en local :

• le Web Storage, comprenant local storage, toujours accessible à l’application et permettant par exemple à des onglets différents de partager des données, et le session storage, accessible uniquement à une fenêtre donnée. Les données sont stockées sous la forme de clés/valeurs,
• la Web SQL Database fournissant cette fois une base de données relationnelle, implémentée par les navigateurs avec SQLite. Signalons au passage que le choix de SQLite a été fait par les éditeurs de navigateurs au détriment de la proposition initiale de « Indexed DB » proposée par le W3C.

Un autre système de stockage local est fourni sous la forme de caches permettant cette fois-ci de stocker des ressources (images, fichiers JavaScript, etc.) et non plus des données.

Dans leurs spécifications respectives, le W3C aborde la sécurité, et décrit les mêmes problématiques pour les deux.

Quels risques et quelles protections?

La seule protection spécifiée par le W3C concerne l’origine des sites : des données stockées par un site A ne doivent pas être visibles pour un site B, en se basant sur l’hôte du site et le port. Cela empêche par exemple une iframe inclus dans un site, typiquement un encart publicitaire, d’avoir accès aux données stockées localement par ce site.

Ce systèmes ne protège pas de certaines attaques, d’ailleurs décrites dans la spécification :

- les attaques par usurpation de DNS, qui consistent à usurper une adresse IP d’un serveur pour envoyer des paquets à sa place. Ce risque sera toutefois mitigé en utilisant SSL, et concerne le web dans sa globalité.

- le partage de nom d’hôte entre plusieurs sites : si le site d’adresse http://www.mon-site.com/site1 stocke des données, un autre site d’adresse http://www.mon-site.com/site2 y aura accès sans resctriction. Le risque étant faible de se faire attaquer par ce biais, car on a déjà fait confiance au premier site.

On remarquera que les attaques par XSS (cross site scripting) ne sont pas mentionnées et constituent pourtant un risque important, bien mis en valeur par l’OWASP. On pourra le mitiger avec notamment un contrôle du code côté serveur et une validation des données passées dans les formulaires.

La spécification ne prévoit pas d’autre mécanisme de sécurité.

Un point très important n’est pas abordé dans la spécification et pourrait pourtant s’avérer crucial : la spécification ne prévoit que les données stockées en base locale soient cryptées, elles sont toujours stockées en clair.
Ce point a été soulevé par Nicholas C. Zakas (un des référents mondiaux sur le langage JavaScript notamment, qui contribue à HTML5). Il a même proposé une proposition très détaillée d’évolution de la spécification vers un cryptage des données, décrite dans ce billet.
Dans ce système, un serveur d’application web aurait la responsabilité de chiffrer les données sur le client, avec une clé de cryptage gérée par l’application. Concrètement, une application web devrait exécuter la méthode Javascript suivante pour ouvrir la connexion en base de données :

window.openSecureStorage("mystorage", window.AES_128, key, function(storage){
//use storage object
});

L’application web choisirait donc l’algorithme de cryptage et la clef. Ainsi, même si un attaquant parvenait à récupérer des données, il ne pourrait les exploiter. On remarquera d’ailleurs que sans cryptage, toute personne ayant acccès physiquement au poste client pourra lire toutes ces données…

Bien que sa proposition soit assez complète et détaillée, il n’y a pas encore eu de suite à ma connaissance de la part d’autres acteurs du web.

On peut tout de même se rassurer concernant les postes publiques (cyber cafés, etc.). En effet, les données sont stockées dans le navigateur dans un profil créé pour l’utilisateur, qui est normalement effacé lorsqu’il quitte le poste et que le compte est ré-initialisé, ce qui doit être l’usage pour ce type de poste. L’utilisateur devant tout de même s’en assurer, ce qui est loin d’être évident pour un utilisateur non initié. Il est ici plus question d’éducation des utilisateurs que de technologie.

Enfin, les caches peuvent quant à eux être attaqués par « Cache poisoning ». L’objectif de l’attaquant est alors d’injecter dans le cache du navigateur un fichier JavaScript en remplacement d’un fichier fourni par le serveur « sain », et dont le script malicieux serait exécuté par le client. Ce risque est à prendre en compte particulièrement dans les réseaux wifi ouverts comme on en trouve par exemple dans des restaurants, mais si ces attaques sont difficiles à détecter et à contrer, le risque s’avère relativement faible d’après les conditions requises pour permettre l’attaque, citées par l’OWASP.

Conclusion

Malgré cette énumération de risques, qui plus est incomplète, il convient d’insister sur le fait qu’ils ne sont pas spécifiques à HTML5 mais au contraire inhérents au web depuis ses débuts.
La nouveauté avec HTML5 est qu’il offre la possibilité de faire des application plus riches, stockant plus de données localement.
Cela doit simplement inciter les concepteurs et développeurs d’applications web à une certaine vigilance concernant la sécurité des données locales, mais ne vous y méprenez pas, HTML5 constitue bien dès aujourd’hui une formidable opportunité pour vos applications web!

Suggestion d'articles :

1. HTML5 : la promesse d’un browser qui devient VM
2. Tous les navigateurs acceptent HTML5 et CSS3
3. Applications natives ou web HTML5 pour mon mobile ?