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…
Les exemples d’usage du pattern “device agnostic” sont nombreux chez les grands du Web. On peut citer :
Facebook propose :
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.
On trouve des exemples du pattern Device Agnostic chez les grands médias.
Par exemple le Monde propose :
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 :
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.
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"
[1] Ce téléchargement peut être optimisé (cf. Fluidité de l’expérience l’utilisateur) mais on ne fait jamais de miracle…