Les Patterns des Grands du Web – Device Agnostic

Description du pattern

Pour les grands du Web, l’ergonomie n’est plus un débat : elle n’est pas négociable.

Déjà en 2003, le manifeste du Web 2.0 plaidait pour une “Rich User Experience”, et aujourd’hui la nécessité d’offrir la meilleure interface utilisateur possible fait consensus dans le monde du Web. Elle est considérée un facteur important de gain de part de marché.

A cette nécessité d’une expérience utilisateur de grande qualité s’ajoute le besoin d’accéder aux applications “anywhere/anytime”, c’est à dire dans tous les contextes de la vie courante. On distingue en général les situations sédentaire (ex : usage au bureau), de nomadisme (ex : usage en position assise dans un aéroport) ou de mobilité (ex : usage en marchant dans la rue).

Ces situations reposent aujourd’hui sur différents types d’appareils ou “devices”. En simplifiant, on peut distinguer :

  • les ordinateurs fixes pour l’usage sédentaire
  • les ordinateurs portables et tablettes pour l’usage nomade
  • les Smartphones pour l’usage mobile

Le pattern “Device Agnostic” dit la chose suivante : il est indispensable d’offrir la meilleure ergonomie possible quelle que soit la situation d’usage et le device.

Une des premières sociétés à avoir développé ce pattern est Apple avec l’écosystème iTunes. En effet, Apple a rendu la musique accessible d’abord sur PC/Mac et iPod, puis par la suite sur iPhone et iPad. Apple couvre donc les 3 situations d’usage. Par contre, Apple n’applique pas complètement le pattern car la musique n’est pas accessible sur Android ou Windows Phone.

Pour mettre en œuvre ce pattern, il est parfois nécessaire d’offrir autant d’interfaces qu’il existe de situations d’usages. En effet, une interface générique de type “one size fits all” ne permet pas cette ergonomie optimale sur ordinateur, tablette, Smartphone, etc.

Les grands du Web investissent donc dans le développement de nombreuses interfaces, ce qui est rendu possible par l’application du pattern “API first” (cf. ce billet). Selon ce pattern, l’architecture de l’application doit reposer sur une API générique, les différentes interfaces seront ensuite développées par l’entreprise ou par l’écosystème sur la base de cette API.

Pour tirer le meilleur parti de chacun des devices, il est aujourd’hui encore difficile de se cantonner à des interfaces Web. En effet, ces dernières ne gèrent pas les fonctionnalités propres des devices (push, capteur photo/vidéo, accéléromètres, etc.). Elles donnent aussi à l’utilisateur une impression de manque de réactivité, car elles nécessitent le téléchargement initial de tout le contenu[1], là où les applications natives peuvent fonctionner en téléchargeant quelques ressources XML ou JSON.

“I’d love to build one version of our App that could work everywhere. Instead, we develop separate native versions for Windows, Mac, Desktop Web, iOS, Android, BlackBerry, HP WebOS and (coming soon) Windows Phone 7. We do it because the results are better and, frankly, that’s all-important. 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. “

Phil Libin, CEO Evernote (janvier 2011)

 

Cependant, les choses évoluent avec HTML5 qui gère le mode déconnecté et répond aux besoins des nombreuses applications qui n’utilisent pas de GPS ou d’accéléromètre. Et de fait, si certains acteurs du Web, comme Evernote, recourent à des applications complètement natives, d’autres s’orientent vers une approche « hybride » : des contenus HTML5 embarqués dans une application native qui devient un simple navigateur, capable de recevoir des notifications en push. C’est en particulier le cas de Gmail, Google+ ou Facebook sur iPhone. Un avantage de ce pattern est d’être présent sur les AppStores, auxquels les utilisateurs ont l’habitude de recourir pour installer leurs applications.

Le Pattern « Hybride » est un bon compromis : il permet une réutilisation du code HTML5 sur divers devices, tout en bénéficiant de l’installation de l’application via les AppStores Apple, Android, Windows Phone, et bientôt Mac et Windows…

Chez qui ça fonctionne ?

Les exemples d’usage du pattern “device agnostic” sont nombreux chez les grands du Web. On peut citer :

  • Dans la catégorie des applications totalement natives : Evernote, Twitter, Dropbox, Skype, Amazon
  • Dans la catégorie des applications « hybrides », on peut citer : Gmail, Google+, Facebook

Les références chez les grands du Web

Facebook propose :

  • une interface Web pour PC/Mac : www.facebook.com
  • une interface Web mobile pour Smartphones : m.facebook.com
  • des interfaces mobiles embarquées pour iPad, iPhone, Android, Windows Phone, Blackberry, PalmOS
  • une interface par SMS pour mettre à jour son status et être notifié des mises à jour de status de ses amis
  • une interface par email pour mettre à jour son status

Par ailleurs, plusieurs interfaces embarquées pour Mac et PC sont proposées par des tiers comme Seesmic ou twhirl.

Twitter se distingue des autres grands du Web par le fait qu’il a laissé son écosystème implémenter le pattern pour lui (cf. pattern Open API). En effet, de nombreuses interfaces Twitter ont été créées par les tiers comme TweetDeck, tweetie pour Mac et PC, Twitterrific, Twidroid pour mobile…. A tel point que, pendant un temps, l’interface Web de Twitter était réputée comme peu ergonomique et de nombreux utilisateurs lui préféraient celles issues de l’écosystème. Twitter est aujourd’hui en train de reprendre la main sur ses interfaces utilisateurs.

En France

On trouve des exemples du pattern Device Agnostic chez les grands médias.

Par exemple le Monde propose :

  • une interface Web pour PC/Mac : www.lemonde.fr
  • une interface Web mobile pour Smartphones : mobile.lemonde.fr
  • des interfaces mobiles « hybrides » pour iPhone, Android, Windows Phone, Blackberry, PalmOS, Nokia OVI, Bada
  • une interface pour iPad

On le trouve aussi dans des services grand public nécessitant une consultation fréquente, comme la Banque. A titre d’exemple, le Crédit Mutuel propose :

  • une interface Web pour PC/Mac : www.creditmutuel.fr
  • un portail de redirection pour tous les types de devices : m.cmut.fr
  • une interface Web mobile pour Smartphones : mobi.cmut.fr
  • une interface Web mobile pour tablettes : mini.cmut.fr
  • une interface Wap :  wap.cmut.fr
  • une interface Java simplifiée pour les téléphones basiques
  • des interfaces mobiles embarquées pour iPhone, Android, Windows Phone, Blackberry
  • une interface pour iPad

Et chez moi ?

Le pattern peut être envisagé pour tous service B2C dont l’accessibilité anywhere/anytime fait sens.

En cas de budget limité, il est fréquent d’implémenter une application mobile pour le device le plus utilisé par la population cible, et de proposer une API ouverte en espérant que d’autres implémenteront les interfaces pour les autres devices.

Dépendances à d’autres patterns

Exceptions!

La limite du pattern est le budget nécessaire à son implémentation (voir paragraphe ci dessus).

Retrouver toutes les pratiques des Géants du Web sur le site dédié (www.geantsduweb.com) : pdf de l’ouvrage à télécharger, vidéo et compte-rendu de la présentation « Décrypter les secrets des Géants du Web »

Sources

 


[1] Ce téléchargement peut être optimisé (cf. Fluidité de l’expérience l’utilisateur) mais on ne fait jamais de miracle…

5 commentaires sur “Les Patterns des Grands du Web – Device Agnostic”

  • Trés bon article présentant la meilleure approche pour l'utilisateur du service. Par contre, Google+ n'est pas une application hybride, au contraire de Gmail sur iOS. Ensuite, pour Facebook ils ont récemment annoncé que dû aux pauvres performances des WebView sous iOS, ils allaient passaient en mode 100% natif pour leur application iOS. Ils feront probablement de même pour leur application Android pour les mêmes raisons. Réduisant ainsi le nombre d'exemple réussi d'application hybride à un seul Gmail (que beaucoup d'utilisateur ne trouvent justement pas réussi surtout en comparaison des autres applications 100% natif tel Mail et Sparrow). Et un exemple réussi qu'il pourrait être pertinent d'ajouter à votre liste serait LinkedIn, qui ont réalisée toutes leurs applications "mobiles" (iOS smartphone et tablette, Android) en mode hybride avec presque 90% de technologies du Web utilisé en se basant sur Node.js. On obtient ainsi une trés bonne application, mais avec de mauvaise performance sur Android. PS : un petit oubli paragraphe 7 : Android et non Androïd.
  • Il faudrait aussi préciser que la gestion du offline par HTML5 n'est vraiment pas une réalité opérationnelle. Passer en mode hybride ne permet pas que le référencement dans un store. Il permet de gérer efficacement le mode déconnecté, qui ne fonctionne absolument pas dans une webapp classique (sauf via un environnement - OS et navigateur - installés sur...desktop, mais ce n'est vraiment pas l'usage du nomadisme).
  • Bonjour Mathieu, Je développe actuellement une application hybride iOS et html5. Le mode offline fonctionne très bien en utilisant le local storage natif de html5. On gère effectivement plusieurs stores, et on ne stock dans l'appli native que les identifiants des stores. Le navigateur natif de la webview implémente la quasi totalité des specs html5.
  • Mon message s'adressait bien à Jean et non à Mathieu :)
  • Bonjour Mathieu, Cela confirme ce que je dis: HTML5 ne permet rien en l'état actuel pour la gestion du offline, sans une hybridation (quel que soit le niveau de cette hybridation).
    1. Laisser un commentaire

      Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha