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 »).
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.
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 !
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.
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 : [email protected]
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
🟣 Pour ne manquer aucune news sur le Journal du Geek, abonnez-vous sur Google Actualités. Et si vous nous adorez, on a une newsletter tous les matins.
Ça a l’air sympa mais je ne vois pas ce que cela vient faire sur ce site qui ne traite pas ce sujet d’habitude.
Pub déguisée ?
c’est un billet sponsorisé?
Certainement.
Oui, visiblement …
Sinon, ça se passe comment si le serveur se plante sur la reconnaissance du client ? Bah on se retrouve avec un truc qui ne ressemble à rien …
moi qui pensait voir une pensée sur les développement à venir pour gérer ce problème si il en est (c’est un faux probleme avec un affichage smartphone toujours plus proche de celui d’un desktop) et je me retrouve avec une pub pour une solution bancale
Article intéressant, même si j’aurais préféré savoir dès le départ que je lisais un communiqué de presse et pas à la fin…
Parce que du coup, j’ai apprécié la lecture de cet article, mais sur la fin j’ai eu comme l’impression de m’être fait berner dans le sens où l’article à clairement un parti-pris (celui de Backelite – que je connais bien, vu que je bosse avec eux…).
Bref, c’est dommage.
Il faudrait aussi développer les applis pour qu’elles s’affichent convenablement sur tablettes…
Bien pratique cette solution ! reste plus qu’à la tester. Je critiquerai après 🙂
Pour ce genre d’article, un journal aurait eu l’obligation d ajouter “ceci est un publi reportage”…
Ben c’est écrit “Rédacteur invité” dans la zone de titre. Et on se doute du truc en lisant l’article dès qu’il y a écrit “notre solution”.
Bon je me fais l’avocat du diable, moi aussi j’ai été surpris…
Vive les news sponsorisées surtout quand la boite qui le fait n’est même pas capable de faire un design mobile sur son site oO
Bonjour à tous. Oui nous parlons de la solution de Backelite au cours de l’article mais les concepts présentés restent néanmoins pertinents. Et d’ailleurs, on fini l’article en vous invitant à un événement complétèrent gratuit durant lequel je serai absolument ravis d’échanger et d’argumenter. Donc, le parti pris dont vous parlez s’appuie sur notre expérience. Vous avez tout à fait le droit de voir les choses différemment mais argumentez 🙂
@Zebu, les cordonniers sont toujours les plus mal chaussés 😀
ok sur la forme c’est sponsorisé, mais sur le fond ils lèvent le lièvre du rwd : à quoi ça sert de balancer 1 mega de ressources avec un temps de latence mobile élevé alors que 100k adaptés pourraient suffire ?
Moi j’ai repéré direct l’entourloupe. Sujet trop technique et trop rédigé pour faire partie des articles habituels.
Donc avec cette solution le serveur est amené à faire le boulot que ferait le navigateur de la plateforme appelante et donc, le serveur pourra être très facilement surchargé.
Bref une solution pas terrible pour qui voudrait un site réactif sur un serveur tranquille.
Outch effectivement, pas de site mobile, ça la fout un peu mal. Dommage je trouvais ça intéressant mais là ça décrédibilise un peu tout le truc.
@guigeek je voulais voir ce que donnait leur outil donc première chose j’ai regardé leur site avec le mobile… mais non :p
Plus sérieusement, c’est certainement un attrape nigaud.
En sachant que pratiquement tous les langages web (sauf très exotiques) ont ce genre de possibilités en natif et qu’il existe des 10ènes de Framework gratuits et très efficaces qui permettent de faire la même chose.
Pourquoi partir sur une solution propriétaire, payante et restrictive?
C’est pas étonnant qu’ils essayent de faire un max de pub, sinon ils ne vendront jamais rien.
Leur site n’est ni responsive. ni adaptative, c’est un peu dommage non?
@JournalduGeek : je n’ai rien contre les billets sponsorisés mais cela serait plus correcte pour vos lecteurs de mieux les identifier comme tel… je n’avais pas remarqué le nom indiqué en petit de l’auteur de cet “‘article”” et au début j’ai été surpris du manque d’objectivité de vos journalistes…
@Zebu : même réflexion, je ne vois pas tellement la valeur ajoutée de la solution (surtout qu’il doit sortir pratiquement un nouveau téléphone par semaine, ils ne me feront pas croire que chaque nouvel appareil est testé pour être adapté sans parler des différentes versions des navigateurs…). Une solution propriétaire donc payante pour le client sans doute par abonnement et le jour où l’on veut changer de crèmerie… plus de site!
Je n’ai pas lu l’article, juste survolé, car déjà il n’as pas de réel raison d’être sur ce site. De plus la solution me semble vraiment étrange.
Je suis développeur web, et le responsive design ça se fait coté client, ce n’est pas compliqué et ça s’adapte à toutes les devices moderne. alors certe c’est plus compliqué si on veut être compatible avec les pda d’il y a 15 ans.
Et puis avec cette solution, en cas de redimensionnement de fenêtre, il n’y a pas d’adaptation du contenu, contrairement à du vrai responsive web design.
Pour finir : des articles sponso : oui mais qu’il traite du contenu du site s’il vous plait.
Je vous invite à aller voir :
http://www.currys.co.uk/gbuk/index.html
http://www.pcworld.co.uk/gbuk/index.html
Qui sont juste les sites d’un des plus gros retailer d’europe, et qui sont full responsive, et avant de dire que c’est lourd à charger, il faut peut être réfléchir un peu…
En partant du principe “mobile first”, c’est le code destiné au smartphone qui est poussé sur tout les device, et le contenu enrichi pour les autres qui se charge en ajax… mais oui l’ajax n’est plus le mot qui fait rêver de nos jours… c’est trop old school… rien n’interdit de mixer les technos.
Et rien n’interdit non plus de charger des images de plus haute résolution une fois la page chargée pour tout ce qui n’est pas un smartphone par exemple…
@phoeniix07 : avoir parfois des news techniques est vraiment sympa et pour une fois, l’information (pour la solution, chacun son avis) est utile.
Pour ma part, pour le web, de l’AJAX avec hashtag est plus que bien venu et donc des webservices pour retourner le contenu souhaité. Solution existante depuis longtemps donc éprouvée, ne charge que le nécessaire côté contenu au premier chargement. Un coup de localstorage pour la forme et le coeur JS et on a l’équivalent d’une appli avec l’avantage du web multidevice. Seul contrainte, ne fonctionne pas sous IE7 (à cause des hashtags) mais avec un hack, ce n’est plus un problème.
Plus qu’à couplé à une solution responsive design, et on est tranquille.
Il n’empêche, c’est une tanné de devoir maintenant géré autant de cas, l’époque IE6 était limite plus simple ^^’
ça me rappelle le site d’adobe qui n’affiche pas une seule animation flash sur sa page d’accueil
pour ce qui est de l’adaptive design, ça prend surement plus de ressources coté serveur mais apparemment c’est utilisé par pas mal d’appli existantes http://www.wope-framework.com/en/references/
si le billet est sponsorisé, ça aurait plus clair AMHA, pour nous lecteurs, de donner le nom du “rédacteur invité” ou de l’indiquer dans le titre comme le fait si bien presse-citron (http://www.presse-citron.net/?s=billet+sponsoris%C3%A9)
Sponsorisé ou pas, honnêtement, je m’en f**t 😀
C’est une approche différente de celle qu’on a d’habitude, et je pense qu’elle vaut le coup d’être explorée. Surement plus complexe à mettre en place (plus de détails sur la “device database” seraient intéressants : quantité / qualité du contenu / màj / etc.), mais avec des avantages non négligeables.
C’est toujours assez surprenant de voir autant de fermeture d’esprit (“le responsive, ça se fait comme ça, un point c’est tout”) dans un domaine en évolution constante comme le notre.
“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.”
Ou alors c’est peut-être juste de l’incompétence en design rwd ?
Je veux bien qu’il y ait des articles sponsorisés, qui sont de la pub déguisée et qui vont se multiplier à l’avenir (encore que logiquement, faudrait faire apparaître de manière visible que c’est une pub pour ne laisser aucun doute, rapport à la loi, donc pas du tout à la fin mais au début, voire même dans le titre…), mais si c’est pour avoir des contre vérités par des mecs qui ne maîtrisent pas totalement leur sujet… Ça n’en vaut franchement pas la peine.
Et dans ce cas, vu que c’est pour parler d’une solution maison, je me demande même si ça ne tombe pas sous le coup de la publicité mensongère…
Les solutions de rendering de contenu (comme WOPE) sont en voie de disparation : la raison de leur création était la nécessité de générer du WML pour les terminaux WAP, eux même en voie d’extinction.
L’article sponso est pas très habile et dénigre, pour des raisons marketing ou pire d’incompétence, le RWD qui s’impose pourtant comme un standard durable.
@phoeniix07 dans l’article c’est surtout le fait d’éviter les chargements inutiles qui est mis en avant (et c’est un des défaut du responsive d’aujourd’hui, bien qu’on puisse le limiter en programmant intelligemment).
Maintenant comme je disais, avec la plupart des langages on peut déjà nativement faire la distinction entre les périphériques.
Pour moi, il y a 2 choses distinctes :
le responsive qui permet de replacer/masquer ou redesigner la page selon la taille de l’écran/fenêtre qui est géré par les css et le js éventuellement pour donner un rendu plus adapté aux différentes résolutions.
l’adaptative qui permet de faire varier le contenu qui sera envoyé au client géré du côté serveur par le code ou un Framework.
Par exemple ne pas afficher une description qui n’a plus sa place sur un petit écran.
côté responsive, tout est géré coté client par la css et le js donc il n’y a pas besoin de Framework ou ni quoi que se soit.
côté adaptative, n’importe quel langage comme l’ASP.NET, le java, le PHP, etc. possèdent des solutions natives pour faire varier le contenu et qui sont au final relativement simples à utiliser.
Il existe aussi de très nombreux Framework pour simplifier encore plus la tâche sur chacun de ces langages.
Il est aussi tout à fait possible par exemple de mixer le responsive l’adaptative design :
par exemple il est très pertinent de faire un responsive générique qui sera donc actif même sur un desktop dans le cas ou la fenêtre du browser sera petite mais rien n’empêche d’utiliser de l’adaptative pour ne pas charger les composants inutiles dans le cas d’un périphérique mobile, qui lui, n’aura jamais la possibilité d’avoir une taille supérieur à son écran.
@Morgan: très bonne remarque.
Ce n’est pas le boulot du serveur Web de faire le rendu d’une page mais au navigateur
ou alors j’ai rien compris au principe d’internet et je vais de suite modifier tous mes sites…
Hâte de voir le rendu de WOPE en action. Pour ma part je ne suis pas fan du responsive pour les raisons que vous avez énoncé dans l’article mais aussi pour une question de Lisibilité des textes de 300 mots ou plus sur un smartphone !
Autant sur un ordinateur je n’ais pas de problème à lire un article si long, sur mon appareils mobile, j’ai pas envie et généralement je n’ais pas le temps.
Je conseil vivement la création d’un site internet mobile en l’offrant même à mes clients actuellement même si il y a une contrainte d’avoir “deux sites” différents.
Que ce soit le Responsive Design ou l’Adaptive Design, ce n’est pas LA solution pour le mobile.
Ces 2 approches ne s’occupent que de l’aspect du rendu d’une page HTML et pour le mobile c’est totalement insuffisant.
Un des fondamentaux des mobiles est le multi-touch. Faire un site mobile sans tenir compte de cela ne sert à rien, les utilisateurs ne l’utiliseront pas et voudront au final une application native.
De plus ces approches ne laissent pas l’utilisateur libre de choisir entre la version standard du site et sa version mobile.
Laissez-donc tomber ces approches et regarder par exemple la version mobile de Rue89 :
http://m.rue89.com
Il y a là des idées à prendre.
Ceux qui disent que le JdG a pas de site mobile:
http://puu.sh/509of.png
xgl: BON DIEU QUE C’EST GÉNIAL.