blog e-commerce, François Ziserman
e-commerce, marketing des sites marchands, technologies 2.0, entrepreneuriat,...

Demain soir a lieu le lancement officiel d’AIR d’Adobe (vous y serez ? Moi, oui !).

L’occasion de se reposer la question : quel est l’avenir des applications en ligne ?

On peut utiliser une application qui va se jouer dans le navigateur (un service Internet quoi).

Avantages :

• L’utilisateur n’a rien à installer, donc un accès rapide à l’application, un accès depuis n’importe quel ordinateur, et pas de problème de mise à jour ;
• On bénéficie de facto de toute les fonctions autour des URL (bookmark, copier / coller, et les effets viraux, en avec la transmission très facile de l’adresse du site) ;
• L’utilisateur est (normalement) en sécurité, l’application en ligne ne peut pas accéder aux ressources locales de l’ordinateur : ni les fichiers sur le disque dur, ni les périphériques (micro, caméra, …). Rien excepté la zone graphique contenu dans la fenêtre du navigateur, la souris et le clavier pour entrer des données ;
• L’interface est assez bien balisée (là aussi, normalement ), et l’utilisateur a des repères, il sait ce que c’est qu’un formulaire, qu’un lien, une page, …
• L’application est la même, quelque soit l’ordinateur, le système d’exploitation, le navigateur (ok, je simplifie ).

Inconvénients :

• Avec les applications évoluées, le navigateur est “décalé” : le bouton back est inutilisable, l’application a besoin d’accéder à plus de ressources (caméra, …) et l’interface est un peu limité ;
• L’application n’est accessible que quand il y a une connexion Internet (a modérer, avec les propositions de Google).

C’est donc pour donner “plus d’air” aux applications en ligne qu’Adobe a développé son AIR.

L’idée est d’avoir le beurre et l’argent du beurre.

En fait, c’est évidement pas si simple :

• L’utilisateur doit installer l’application AIR (ok, très peu de clics) ;
• Les mises à jour sont pratiquement transparentes : comme il y a une application locale, il faut bien mettre à jour l’application. Mais cette mise à jour est automatisée (comme la plupart des applications, aujourd’hui) ;
• L’interface n’est plus du tout banalisée. Ce n’est pas une critique, puisque justement c’est le but, de sortir des limites du navigateur. Le résultat sera dépendant de ce que feront les éditeurs… On verra le meilleur et le pire !
• L’application est bien la même, quelque soit la plate-forme, c’est ce qu’apporte le moteur AIR.
• L’application peut fonctionner en mode off-line, cela dépend de l’application (l’application eBay en mode off-line n’est pas opérationnelle) ;
• On peut bien sûr se passer l’url qui pointe vers la page d’installation de l’application, mais il est certain qu’on n’aura pas le même niveau de viralité par rapport aux URL…
• La sécurité : ah, je suis impatient d’en savoir plus demain. Adobe devait y travailler, c’est évidement un sujet clé.

Dans une application AIR, le runtime AIR n’est pas visible, seule l’application apparait sur le bureau de l’ordinateur.

La gestion des applications est donc laissée au gestionnaire de fichier de l’ordinateur.

C’est là que je reviens avec mon idée, d’un navigateur sans bord de fenêtre… C’est peut être un compromis plus intéressant : garder la notion de navigateur, d’URL, mais avec certaines applications en ligne, qui prendraient la main sur la fenêtre du navigateur.

Pourquoi ?

• Pour garder justement la notion d’URL et tous les avantages associés ;
• Pour avoir le double mode : service Internet ou service “application” ;
• Pour simplifier encore plus les processus d’installation ;

Mais voilà, Adobe ne me demande pas mon avis pour spécifier ses produits. Microsoft non plus remarquez !

Comme vous le savez sans doute, je suis en pleine préparation de notre p’tit dej Rich commerce.

On a clairement choisi avec Fred une orientation plutôt “non technologique”.

J’ai pas pu m’empêcher, j’avais préparé tout un tas de slides sur l’architecture MVC adéquate pour décliner les interfaces riches…

En relisant notre présentation, on s’est rendu compte que c’était décallé !

Zut !

Alors je publie une image sur ce blog, et vous ne la verrez pas demain lors de la présentation !

Compréhensible sans explication de texte ?

Quand on parle d’interfaces riches, il faut parler des technologies permettant de les mettre en oeuvre.

L’une des technologies phare, c’est le Flash.

On connait tous plus ou moins Flash, mais on parle de plus en plus de Flex.

Quelle est la différence ?

Qu’apporte Flex par rapport à Flash ?

Flash recouvre plusieurs choses :

• Un format de fichier, le SWF, qui contient le média animé proprement dit (les images, les annimations, les films, …) ;
• Un éditeur : c’est une application Mac ou PC, qui permet de créer des fichier Flash (SWF donc). L’éditeur est orienté design. On pose des images, des objets graphiques, sur une time -line, et on déplace les objets graphiques sur l’échelle de temps ;
•  Un player : c’est l’application qui permet de lire le Flash. On peut lire un fichier SWF avec une application spécifique, mais le plus souvent, on utilise un plug-ins, intégré au navigateur. C’est donc le navigateur qui joue le rôle de player Flash.
• Un langage de programmation : ActionScript. On écrit ses programmes depuis l’éditeur, et le langage est interprété par le player.

Flash est donc un ensemble permettant de réaliser des interfaces riches et animées. Flash est orienté design.
Et Flex alors ?

Flex, c’est la déclinaison Flash pour les programmeurs.

Quand on fait du Flex, on travaille en fait sur le même format qu’avec Flash : le SWF.

Pour le client, le résultat est donc exactement le même : c’est un contenu Flash qui apparait dans le navigateur Internet.

La différence, c’est sur la façon dé générer ce fichier SWF.

Flex introduit un nouveau langage, le MXML.

C’est un langage qui permet de décrire l’application Flash que l’on souhaite, et les comportements associés.

On se retrouve donc à faire du Flash, sans l’éditeur graphique, mais plutôt depuis un environnement de développement (Eclipse, …).

Donc, si le résultat est le même, la façon de le faire est complètement différente, et complémentaire.

Dans la réalité d’un projet, les deux approches doivent cohabiter : la partie graphique pourra être réalisée avec l’éditeur Flash, et la partie dynamique pourra être réalisée avec Flex.

Mon billet précédent (celui là bien sûr) a eu son petit succès.

On est tous bien d’accord, la question, c’est comment vendre plus, comment utiliser les interfaces riches pour mieux mettre en valeur le produit.

Dans ce nouvel exemple, le produit est mis en valeur avec une interface 3D, sous flash :

Vous trouvez pas qu’ils sont bien présentés les produits ?

En tout cas, on est en plein sur le sujet de RichCommerce.fr.

Bon, je suis sur la mauvaise pente moi, qu’est-ce que je vais vous montrer demain ?

On parle souvent d’interfaces riches, des services qui intègrent de la 3D, de la vidéo, des animations.

Mais est-ce que cela fait vendre ?

Je vous propose, pour s’en convaincre, de passer faire tour sur www.knickerpicker.com

Le mélange de flash, de petits films, d’animations, est très… convaincant !

D’accord, le sujet s’y prête, d’accord, c’est plus facile que pour des sacs poubelles, mais il est bien évident qu’on peut utiliser ces technologies pour tout un tas de produits.

Merci Manu (encore ! ).

Cette news tombe à pic pour faire un peu de “teasing” : les interfaces riches, et le e-commerce, voilà un sujet sur lequel je vais bien vite revenir… Stay tuned !