Archives par mot-clé : web

La fin du combat pour Flash, mais quel avenir pour HTML5 ?

La news est tombée pendant les vacances : Adobe arrête de supporter Flash sur Android.

Plus de Flash sur Android, et bien sûr toujours pas de Flash sur les terminaux mobiles Apple : une bonne partie du Web doit maintenant se débrouiller sans Flash.

Plus intéressant encore est la raison de cet abandon : Adobe reconnait que l’avenir est du côté du HTML5.

La messe est donc dite : le Flash va disparaître, et être remplacé par les technologies incluses dans le HTML5.

Tout serait simple si…

Si le HTML5 avançait bien. Ce qui n’est pas du tout le cas : aux dernières nouvelles, les équipes se disputent, ce qui va rendre le processus de normalisation plus lent et plus complexe…

Aujourd’hui, rien ne garanti qu’on arrive dans les temps, c’est à dire en 2014, avec une norme bien aboutie.

Ce qui est a peu près clair, c’est que ce sont les éditeurs de navigateurs qui font principalement évoluer les choses : Google, mozilla, Microsoft, Apple.

Bon, concrètement, il ne me semble plus très raisonnable de démarrer un site avec des composants Flash. Le HTML5 est de rigueur !

Les agences vont devoir accélérer leurs mutations, et, surtout, on attend des outils d’éditions HTML5 à la hauteur des enjeux.

A suivre de prêt !

Infographie – L’histoire du HTML5

Le HTML5, c’est le passé, puisque ça existe depuis 2004, le présent, puisque les navigateurs actuels supportent le HTLM5, et le futur, parce que le HTML5 n’est pas encore une norme (la cible, c’est 2014).

C’est donc sacrément important !

Cette infographie vous donnera quelques repères :

(Via Frenchweb)

Responsive Web Design, mon grain de sel ;)

Les tailles des écrans varient énormément, et ce phénomène ne fait que s’amplifier.

Les nagigateurs se diversifient, sans qu’on voie de réelle convergence arriver. En fait, comme l’historique du web augmente (mécaniquement 😉 ) et qu’on ne contrôle pas les mises à jours des logiciels, le nombre de navigateurs augmente mécaniquement, au fil du temps.

Le contexte de l’internaute est de plus en plus varié : chez lui, avec un ordinateur, chez lui, avec une tablette, une console de jeux mobile ; en mobilité, avec un smartphone, …
Ce contexte est important, parce qu’en fonction de celui-ci, les problématiques ne sont pas les mêmes : la bande passante n’est pas du tout la même, entre un internaute qui accède à un réseau wifi et un internaute en mobilité, en 3G ou Edge.

Enfin, même quand l’internaute est chez lui, devant un bien classique ordinateur, la taille de la fenêtre du navigateur peut tout à fait ne couvrir qu’une partie de son écran.

Bref, le contexte de navigation devient de plus en plus varié, avec pas mal de paramètres à prendre en compte.

D’ou la tendance actuelle, intéressante, du Responsive Web Design.

Cette notion vient de l’architecture physique, ou l’on essaye de faire des éléments qui évoluent, en fonction des besoins ou usages.
Exemple : une vitre est transparente et peut devenir opaque, en fonction de l’usage de la pièce.

Je veux pas la ramener, mais c’est bien ce à quoi Wokup s’était attelé dès 1999 !

Donc, ce n’est pas un sujet nouveau, mais on peut dire que c’est un sujet qui devient de plus en plus important.

L’idée, du Responsive Web Design, c’est de changer la façon de concevoir un site web, de manière à ce qu’il soit « intrincèquement » adaptable aux différentes configurations.

On a bien l’idée d’un contenu unique, qui s’adapte à l’ensemble des situations.

 

Ce que j’en pense :

C’est un vrai sujet, c’est donc très bien qu’il soit traité 😉

Comme le dit ce très bon article (en Français en plus), cela ne concerne pas que la partie technique. Il faut que les designers pensent au site différemment, le conçoivent différemment.
Il faut dans le même temps que les décideurs, les manageurs, comprennent ces enjeux, et fassent des choix cohérent par rapport à ce besoin, qu’ils demandent à leurs agences : « comment le site s’adapte aux différentes tailles d’écrans » ?

Si le buzz actuel sur cette approche fait bouger les choses dans ce sens, et aide l’ensemble des acteurs : développeurs, designers, décideurs, c’est déjà très très bien !

Maintenant, l’approche est intéressante, mais n’est pas suffisante.

Je ne pense pas, pour ma part, que le seul sujet soit la mise en forme, aussi intelligente soit-elle.
Exemple : on ne va pas afficher le même nombre de produits, entre une interface pour smartphone et un ordinateur.

Je ne vois pas non plus pourquoi on envoie le même contenu à l’internaute, quelque soit sa configuration.

Je sais que ce n’est pas l’approche « standard », mais je pense qu’il est plus adapté, pour certains éléments, d’envoyer un contenu adapté à la configuration de l’internaute.

Exemples :

  • il est en mobilité, sur un petit écran : j’envoie des images petites, légères.
  • Il est chez lui, avec un bon réseau : j’envoie des images en haute définition, permettant d’avoir une qualité au top.
  • Il navigue depuis IE6 😉

Bref, je pense que la solution passe par un mixe entre ce que propose le Responsive Web Design, et des technologies côté serveur.

La partie Responsive Web Design permet d’avoir un contenu avec une certaine élasticité.

La partie serveur permet d’optimiser ce qu’on envoie à l’internaute, tant au niveau du poid qu’au niveau du format.

Maintenant, l’approche dont je parle n’exsite pas…. Pas encore !

Merci à

La folie Javascript

Si, au début, Javascript est arrivé discrètement, pour « égailler » un peu les pages, aujourd’hui, c’est un vrai feu d’artifice !

Bien souvent, les sites chargent plus de 15 scripts, qui représentent souvent plusieurs centaines de Ko.

Sans oublier le code javascript ajouté directement dans les pages…

Le résultat est que les pages sont lourdes : lourdes à charger, et lourdes à exécuter.

En fait, bien souvent, on importe des librairies, et on en utilise une petite sous partie.

Quel dommage, surtout quand on connait l’importance d’avoir des sites qui répondent vite

Comment en est on arrivé là ?

En fait, c’est une dérive, largement encouragée par pas mal de boites du secteur.

Je m’explique.

Pour la plupart des entreprises, la partie technique du site e-commerce est un centre de cout, pas un centre d’investissement (dommage 😉 ).

Dans un tel contexte, l’ajout de fonctions au site est toujours une négociation difficile.

La parade ? Le Javascript !

Les boites viennent vous voir, et vous explique que leur solution est « non intrusive », et qu’il suffit d’ajouter « un petit script de rien du tout ».

Et ça marche ! En quelques heures, le site a intégré une nouvelle fonction, et cela n’a presque rien couté en intégration…

Mais voilà, tout cela à un prix : le « petit code javascript » inclus un autre fichier, bien plus gros, qui lui même fait appel à des fonctions externes… et la page a pris 20, 30% de temps de chargement en plus, sans compter les bugs « qui viennent avec » parce que certaines fonctions sont incompatibles, les unes avec les autres.

Tout cela se corrigera avec le temps, quand la qualité deviendra un critère de performance (ce qu’il est vraiment !).

La qualité, cela doit aller jusqu’au bout, jusqu’au contenu qu’on envoie sur le poste du client.

Le pire, c’est qu’il n’est pas très compliqué de faire le ménage là dedans : compiler regrouper les fichier javascript, supprimer les fonctions inutiles, compresser tout ça… Et gagner de précieuses secondes en temps de chargement !

Une idée du e-commerce en HTML 5

Le HTML 5, qui devrait aboutir à une norme en 2014, est déjà bien présent dans les navigateurs modernes, Google Chrome en tête.

Le web a d’ailleurs pratiquement toujours évolué comme ça, tiré par les navigateurs plus que par la normalisation (qui est donc plutôt une normalisation « a posteriori »).

Voici quelques sites, qui, je pense, donne une idée de ce qu’on peut faire, en HTML 5 dans notre secteur du e-commerce.

Premier exemple : manufacturedessai.it

Le site propose une navigation verticale plutôt étonnante, faite de plusieurs couches (calques) transparents, ce qui donne une impression dynamique nouvelle. A tester pour comprendre ;).

Autre site  : www.gforce.be

La navigation est là encore différente, avec un slider plein écran, et les différents éléments qui apparaissent en superposition.

Autres sites intéressants :

Tout ça pour avoir un petit aperçu de ce que permet le HTML 5, et des évolutions à venir pour les sites e-commerce… A suivre de très près ;).
Au, fait, je donne une formation HTML 5 le 16 Septembre…

Evolution du modèle de programmation du web – Retour vers le futur

Au début, avant Internet, il y avait des ordinateurs qui fonctionnaient en mode client serveur.

Le serveur gérait principalement les données, et l’applicatif tournait sur le client.

Après, il y a eu Internet.

Comme les premieres versions du HTML étaient très pauvres, l’application c’est naturellement déportée vers le serveur. C’est ce qu’on appelle le serveur d’appication.
Dans ce modèle, le serveur fournit à peu près tout : il livre au client une page complète, que le client n’a qu’à afficher. L’intelligence côté client est très légère.
Cela ressemble à ce qu’on fait sur les gros système (CICS par exemple : vous savez, ces écrans textes avec les caractères en vert qu’on voit si on regarde les écrans des vendeurs dans pas mal de boites…).

Mais le web s’est enrichi, avec le Javascript, et la possibilité de développer des applications bien plus intelligentes, bien plus sophistiquées, et surtout bien plus agréables à utiliser.
Cela veut dire que, dans ce modèle, l’intelligence est répartie entre le serveur et le client. Plus la couche Javascript est évoluée, et plus l’intelligence est déportée vers le client.

Avec les évolutions actuelles du web, on peut légitimement penser que c’est bien le sens de l’évolution pour les prochaines années : revenir en fait à un modèle ou l’intelligence applicative est principalement sur le poste client.
Côté serveur, on gère principalement la couche des données.
Sur un modèle en trois couches MVC (modèles / vue / contrôleur), les deux autres couches, vue et contrôleur sont donc déployée sur les postes clients.

Prenons un exemple : un site e-commerce au hasard 😉

Ce que doit gérer le serveur, c’est bien l’ensemble des données du système :

  • Le catalogue, avec l’ensemble des produits, et toutes les informations associées à ce catalogue : description, prix, stock, …
  • La base des clients
  • La base des commandes

Certaines de ces données peuvent, pour des raisons de performance, être gardées sur le poste client. Exemple : la hiérarchie des produits. Mais les données qui « bougent » doivent absolument être stockées côté serveur. Exemple : le stock produit.
Tout le reste pourrait très bien être géré côté client.

Avantages de ce modèle :

L’application peut être bien plus évoluée que ce qu’on fait en web classique. On peut avoir une bonne idée de ce modèle, avec, par exemple, la navigation dans un catalogue en Ajax : quand on applique un filtre, la page n’est pas raffraichie, seuls les produits changent. C’est un peu la préhistoire du modèle que je présente.

Autre avantage : la consommation, en bande passante, est bien plus optimisée. Une fois l’applicatif chargé sur le poste client, on n’échange que les données nécessaires. Pas besoin de renvoyer l’ensemble de la template du site à chaque page.

Les technologies sont assez développées pour permettre de mettre en oeuvre ce modèle dès aujourd’hui.

En fait, ça ne serait pas une bonne idée ;).

Pourquoi ?

Parce que ce modèle n’est pas très « SEO friendly ». Comment google peut il indexer un truc pareil ?

La réponse est connue, c’est la même que pour le Flash : il faut faire deux versions du site. Une « dynamique » et une sans javascript. C’est accepté par Google, car la version sans Javasript est bien accessible à ceux qui le souhaitent, et c’est en particulier le cas pour les mal et non voyants.

L’autre problème, c’est que, même si les technologies permettent « théoriquement » de mettre en oeuvre ce modèle, les outils, les frameworks ne proposent pas encore les bons outils pour faire ça sans avoir à tout réinventer.

Donc, c’est un peu tôt pour se lancer à fond là dedans, mais cela donne, je pense, une bonne idée de « là ou l’on va ».

(article issu d’une discussion passionnante avec Pieroxy)

Le stockage local, enjeu majeur du HTML 5 et de l’avenir du Web

Quelle sont les différences entre une application « lourde » et un service Web ?

Heu, ces différences sont de plus en plus difficiles à identifier.

C’est d’ailleurs bien la vision de Google, qui va proposer, dans les prochaines semaines, des ordinateurs portables Chrome.

L’OS a fusionné avec le navigateur.

C’est une tendance lourde, qu’on vie tous, tous les jours.

Par exemple pour le mail, en ce qui me concerne, j’ai mis quelque temps à résister, puis j’ai basculé sur une utilisation complètement web du mail (gmail en ce qui me concerne).

Pourquoi ?

Parce que j’ai estimé, à un moment donné, que les avantages du web mail étaient supérieurs aux inconvénients.

Principal avantage : j’ai accès aux mails depuis plusieurs appareils, ordinateur, mobile, avec des données toujours à jour.

Mais, c’est la limite, j’ai un service très dégradé en mobilité, quand le réseau est mauvais ou inexistant (train, avion, …).

Je suis convaincu que l’enjeu majeur, pour que cette nouvelle recette prenne, est le stockage local.

Le stockage local permet de développer des services qui fonctionnent même quand le réseau n’est plus là.

C’était bien le rôle de Google Gears.

Pour revenir à mon exemple Mail, quand Google Gears fonctionnait, l’usage était réellement bluffant : on accède à ses mails, avec ou sans réseau : rechercher dans la base des mails, écrire de nouveaux mails, …

Mais alors, pourquoi Google a arrêté le développement de ce module ?

Parce que cette fonction est nativement intégrée dans le HTML 5 ! Cela veut dire que les nouveaux navigateurs devraient intégrer nativement cette fonction de stockage local.

Si les choses se passent bien à ce niveau là, on devrait donc voir, dans les prochains mois, l’aboutissement de cette mutation, cette véritable révolution !

Révolution parce que cela change l’écosystème, avec la disparition de l’OS tel qu’on l’a connu depuis plus de 20 ans.

Les principales forces en présence sont les suivantes :

  • Microsoft : est pris entre deux contraintes opposées : défendre son business actuel, et donc chercher à protéger le marché actuel, avec une licence pour Windows, et des licences pour chaque application acheté.
  • Google : à fond pour que l’avenir de l’ordinateur soit 100% web, et 100% via le navigateur. C’est le principal moteur de cette révolution.
  • Apple : est dans une situation différente des autres. D’un côté, Apple est constructeur d’ordinateurs, avec un OS spécifique. De l’autre, Apple travaille, comme Google, pour « transformer l’expérience utilisateur » et proposer une interface mieux intégrée, moins technique, avec toute la gamme des terminaux mobiles iOS : iPod, iPhone, iPad.

La vision d’Apple et de Google ne sont pas si différentes que ça, sauf que Google propose de passer par des technologies ouvertes, alors qu’Apple propose cela au travers des technologies propriétaires.

Tout cela promet d’être passionnant !

Les dangers de l’hyper concentration du web

Le web se concentre, géré par quelques « mammouth » du Web : Google, Amazon, Facebook, …

Cela ne correspond pas au modèle initial…

Cette hyper concentration pose problème, parce que, un peu comme dans le monde animal, la diversité est un facteur de solidité.

Exemple ?

WordPress se fait hacker… et se sont des dizaines de millions de blogs qui sont en danger !

Vous vous rendez compte : un bug, et des centaines de millions de lecteurs se trouvent pénalisés !

Alors, vous imaginez la situation si Google se faisait hacker ?

Et pourquoi pas ? Cela représente de tels enjeux… et la sécurité 100%, c’est dans la même boite que le père Noël, si vous voyez ce que je veux dire ;).

Plus proche de notre sujet préféré, le e-commerce, un copain me disait qu’il a reçu un mail, l’avertissant que les comptes d’une boutique en ligne ou il est inscrit avait été hackés. Il doit donc modifier ses mots de passes d’urgence, sur tous les sites ou il a utilisé le même couple (login / password). Comme cette boutique est géré par un acteur plutôt gros, ça veut dire que la plateforme que gère cet acteur a des fuites…

Les experts en sécurité ont du pain sur la planche 😉

Autre question liée : comment éviter cette hyper concentration ?

Je ne sais pas en fait si on pourra éviter cette tendance forte.

L’une des solutions serait d’avoir des briques techniques, facile à utiliser, permettant de créer relativement facilement des solutions qui « challengent » les leaders.

Vous voyez l’idée ? La technologie ne constituerait plus un obstacle.

Mais bon, on est en pleine science fiction là ;).

Mise à jour du 28 Avril :

Vous avez suivi ce qui se passe sur le réseau de jeux de Sony ?

Le système est tombé, ces millions de comptes ont été pillés, avec les données de paiement (CB) dans la nature !

La panne dure depuis plus d’une semaine !!!

Le drame des cookies…

Les discussions actuelles, qui visent à ajouter des fonctions de « protection de la vie privée », ça peut avoir de très fortes incidences sur nos métiers…

Pour bien comprendre tout ça, ça vaut le coup de reprendre un peu l’histoire du web.

Au début, le web, c’était simple :

Il s’agissait de pages de textes, statiques, contenant des liens permettant de naviguer, d’une page à l’autre. Il y a eu rapidement des images, mais tout cela restait très statique.

Pour faire ça, Tim et ses équipes ont travaillés sur des choses très simples : un langage de description de contenu, le HTML, et un protocole très très simple, le HTTP.

Le protocole est hyper basique :

  • Le serveur est passif, il « dort » tant qu’il peut (le bienheureux 😉 )
  • le client demande une page
  • Le serveur reçoit la demande, et renvoie la page demandée si elle existe, une erreur sinon (404, ça vous dit quelque chose ?)

Point à la ligne ! A la base, le protocol est « stateless » : le serveur ne fait pas le lien entre deux demandes. C’est comme si il était amnésique.

Tout cela marche très très bien pour les premiers contenus du web.

ça ne marche plus du tout quand il s’agit de mettre de véritables applications transactionnelles en ligne.

On a donc du étendre le protocol initial, et ajouter un « machin » permettant de faire le lien entre deux pages.

Pour nous, dans le e-commerce, c’est juste fondamental : c’est, par exemple, le moyen pour maintenir le panier du client rempli entre deux pages !

Pour faire ça, la technique la plus utilisée est d’utiliser les cookies.

Le mécanisme est assez simple :

  • Le client demande une page (ça démarre toujours comme ça 😉 )
  • Le serveur renvoie la page, plus un petit texte, qu’on appelle cookie, et qui sera interprété à part par le navigateur du client, qui va stocker ce fichier sur le disque dur du client.
  • Quand le client demande ensuite une page suivante, le navigateur renvoie le texte du petit fichier, vers le serveur.
  • Le serveur reçoit donc deux choses : la page à afficher plus le texte du cookie envoyée la première fois.

Si, dans ce petit fichier, on stocke un identifiant unique, on a bien, côté serveur, le moyen de faire le lien entre les deux pages. On a créé une session !

Petit détail complémentaire : le cookie est associé au nom de domaine du site. C’est comme ça que vous pouvez trouver, sur votre navigateurs, les cookies associés à chaque site web :

Bon, maintenant, les cookies, c’est utilisé pour pleins de choses. Si c’est effectivement utilisé dans une application e-commerce, ou tout autre application web, c’est aussi utilisé pour faire de la publicité ciblée (je te fais de la publicité en rapport avec les pages sur lesquelles tu navigues).

Je ne sais pas comment les choses vont évoluer, mais ça me semblait important de rappeler ces fondamentaux : pour travailler, on a besoin que ces mécanismes fonctionnent bien, et je crains que certains fassent l’amalgame entre les cookies pour publicité et les cookies pour faire tourner les applications en ligne.