Le monde mobile est en pleine mutation. Dans quelques années, tout se fera sur mobile. Les développeurs l’ont déjà compris, proposer un rendu adapté aux visiteurs est devenu une nécessité. Les contraintes pour adresser les nouveaux écrans de types Smartphone ou tablette sont multiples. Il y a tout d’abord une fragmentation en termes de taille et de densité d’écrans. Il y a aussi une fragmentation en termes d’OS, de navigateurs, d’API disponibles etc. En bref, le Web Mobile, c’est un peu comme le Web d’il y a 10 ans ! Un Web avec des standards technologiques que peu d’éditeurs d’OS respectent…

image (5)


L’une des réponses, dont on parle beaucoup maintenant depuis quelques mois, est le « Responsive Web Design » (RWD). Cette technique de développement vise à proposer N rendus pour N écrans. Autrement dit, il s’agit de proposer un rendu adapté à un premier écran, puis, à l’aide de différents mécanismes, les medias queries, le JavaScript dit non-obtrusif etc., de se reposer sur le navigateur pour construire un rendu adapté. Vous l’aurez compris, l’enjeu principal du RWD est de rationaliser les coûts de développement et de maintenance en permettant aux développeurs de ne maintenir qu’un seul code pour l’ensemble des dispositifs connectés disponibles.

Cependant, le Responsive Web Design se repose sur le terminal pour afficher du contenu, c’est-à-dire que c’est le téléphone, la tablette, ou la cible, qui, en fonction de ses caractéristiques affichera un rendu spécifique. Précisément, à date, seules la résolution et la taille de l’écran sont des points de rupture exploitables (« breakpoint »).

image (1)

Cette méthode induit donc qu’un volume de code important soit envoyé au terminal quand bien même toutes les lignes de code ne seraient pas indispensables au rendu.

Concrètement, une section ou une div de contenu peut être visible sur une tablette, et masquée sur un Smartphone pour une question simple de cohérence de contenu avec la situation de mobilité du visiteur, ou encore pour une question d’espace d’affichage trop limité. Et bien le Responsive Web Design en tant que tel ne permet pas de « filtrer » le contenu en amont sur le serveur, ce contenu sera envoyé au terminal et c’est lui, qui, en fonction des instructions du développeur, choisira de ne pas l’afficher.

Cette approche aura donc pour effet dans l’immense majorité des cas d’allonger le temps de chargement inutilement. Pire, le rendu risque d’être complètement incohérent avec celui attendu par le développeur en raison de différences d’implémentations fonctionnelles des moteurs de rendus embarqués dans les navigateurs (variantes de WebKit, Firefox, Windows etc.).

Concrètement, il existe des différences de comportement d’un navigateur à l’autre quand bien même le code envoyé est identique. Une fois encore, tout comme dans le Web des années 90 et 2000, les navigateurs mobiles manquent encore cruellement de standardisation.

Au moment où les OS mobiles se multiplient (iOS, Android, Windows Phone, arrivée de Firefox Mobile, de Ubuntu Mobile, de Samsung Tizen…) on ne peut que craindre une augmentation de ces comportements intempestifs.

image (4)

Vous l’aurez compris, le RWD semble donc peu adapté aux sites et applications hybrides complexes qui ont vocation à être affichés sur terminaux mobiles.

Une autre des difficultés les plus importantes à adresser en mobilité correspond aux contraintes de bande passante imposées par les opérateurs. Si votre utilisateur est connecté en WIFI (ou 4G), le contenu s’affichera rapidement même si le volume de données est important, en revanche si votre visiteur est en 3G ou pire, en Edge, alors le temps d’attente avant l’affichage, le fameux « Time To Glass », semblera interminable ! Le Time To Glass correspond à tout le temps d’attente avant que la navigation soit possible.

Lorsqu’on est en situation de mobilité, dans la rue, dans les transports, dans un taxi, etc., l’instantanéité d’accès à l’information doit être le premier objectif du développeur… On comprend donc aisément que si le Responsive Web Design peut particulièrement bien répondre aux besoins d’un service de blogging, il ne l’est plus du tout pour un site complexe de eCommerce par exemple.

À la manière du « Responsive Web Design », il existe une autre approche qui peut d’ailleurs être couplée au Responsive Web Design, « l’Adaptive Design ».

C’est l’approche que nous avons choisi d’implémenter dans notre suite logicielle WOPE. Il s’agit d’une forme de RWD, mais basée sur un composant serveur, on parle donc de RESS (REsponsive design Server Side), ou encore « d’Adaptive Design ». C’est également la méthode utilisée par Facebook sur son site mobile. Elle consiste à « reconnaître » le terminal client lors de la requête afin d’envoyer un contenu « pré-rendu » côté serveur au sein duquel chaque ligne de code sera utile. Cette approche permet également de retailler les images en amont du réseau, d’optimiser le contenu, de réduire sa taille, en somme : d’accélérer le temps de chargement et d’améliorer considérablement l’expérience et les performances.

WOPE (Write Once Publish Everywhere) est un Framework de développement HTML5 dédié aux technologies mobiles et nouveaux écrans. Il permet de développer un site web mobile, optimisé sur l’ensemble des navigateurs mobiles, mais aussi de publier des applications associées sur tous les Applications Stores. Pour l’ensemble de ces dispositifs, le service sera développé une seule fois et c’est WOPE qui adaptera le contenu !

image (2)

Cette solution 100% Française est aujourd’hui disponible sur le Cloud ou en licence. Basé sur la technologie d’aujourd’hui, le HTML5, cet outil de développement fonctionne comme un « reverse proxy », c’est-à-dire qu’en fonction des capacités du terminal qui requête la page, WOPE réécrira le contenu pour l’optimiser et l’adapter à la plateforme.

Les avantages à utiliser ce type de solution sont multiples, tout d’abord, il permet au développeur de ne maintenir qu’un seul code, c’est-à-dire une seule application et ce, quel que soit le nombre de dispositifs cibles, mais aussi d’avoir un « time-to-market » performant et cohérent avec la fragmentation du monde mobile actuel.

image (3)

Vous direz donc ? Oui comme le Responsive Design quoi… Eh bien oui, mais pas seulement.

Pour mieux vous aider à appréhender ces problématiques, toute l’équipe WOPE organise un événement le jeudi 23 mai 2013 à Paris au format d’un petit déjeuner agrémenté de présentations.

Vous souhaitez en savoir plus sur le filtrage côté serveur particulièrement adapté aux services mobiles ?

Vous avez des projets, mais ne savez pas encore quelles technologies utiliser ?

Venez en parler ! Inscrivez-vous ! Vous pouvez réserver votre place en écrivant à l’adresse suivante : contact@backelite.com

Ce sera l’occasion pour Backelite de vous présenter la dernière mouture de sa suite de développement WOPE ! Venez nombreux !

Et en attendant, créez donc un compte de test pour essayer WOPE et vous faire une idée ! Rendez-vous à l’adresse suivante : http://trial.wope-framework.com/
L’adresse du site du Framework : http://www.wope-framework.com