Interfaces riches : 2 approches

Le site Thinking and Making résume de façon assez intelligente l’intérêt des interfaces riches : Two strategies for rich interface design. L’auteur a ainsi identifier deux types d’approche :

  • Raccourcir / fluidifier les processus. Ceci est particulièrement intéressant sur des sites de commerce en ligne ou des sites qui mettent en scène des assistants avec plusieurs étapes.
  • Ouvrir de nouvelle possibilité dans la conception d’interface. Il est vrai que des technologies comme Flash nous permettent de nous affranchir des éléments d’interfaces ‘basiques’ du HTML (boutons radios, cases à cocher, liens, champs…).

A méditer… Et pour vous, ça sera quelle approche ?

Un commentaire sur “Interfaces riches : 2 approches

  1. Le plus intéressant dans cette approche, indépendamment de sa pertinence, est le fait qu’elle suit entièrement le point de vue de Macromedia (l’éditeur de Flash, pour les ignorants en la matière). Doit-on en déduire que les éditeurs de logiciels dictent maintenant leur loi aux communicateurs ? J’espère sincèrement que non. Mais avouons que la résistance à leur puissance de frappe et à leur volonté d’hégémonisme doit s’organiser de manière active. Ou alors, il ne me reste plus qu’à postuler chez Macromedia, Adobe ou Microsoft…

  2. Point 1:
    Il me semble qu’on s’engouffre un peu trop vite dans ce genre d’interface à base d’assistants. Cela nuit grandement à l’accessibilité car il faut passer plusieurs pages avant d’arriver à ce que l’on souhaite. Par exemple connaître les frais de ports sans avoir à entrer ses coordonnées. C’est très déroutant ! … et inutile

    Point2 :
    Là aussi ce genre d’interface finit par ne pas être très accessible. Flash est par définition pas accessible du tout aux mal voyants. Je doute qu’il existe un lecteur d’accessibilité capable de lire le flash. Par ailleurs ce n’est qu’une question d’affichage. Le DHTML permet beaucoup d’options en ce sens, même de créer des contrôles qui n’existent pas.

  3. Point 1: il me semble que ceci relève de la compétence du créateur de l’interface davantage que de les possibilités offertes par le rich media. Point 2: là encore, Flash permet aujourd’hui d’utiliser avec succès les logiciels destinés aux mal-voyants. Les éditeurs proposent, les agences interactives disposent (bien ou mal)… Mais là encore, nous restons dans une logique dictée par les éditeurs de logiciels. Il serait bon de connaître les possiblités offertes aujourd’hui dans ces 2 points par les solutions open source. A mon avis, il y en a: l’utilisation des flux et aggrégateurs RSS est à mon avis une alternative majeure. Je doute qu’il ne se passe longtemps avant que ce sujet ne devienne un des sujets de discussion les plus importants dans le cadre de la relation acteur/consommateur (une fois épuisée la hype autour des blogs). A ce sujet, je vous conseille un nouveau blog consacré aux RSS (en anglais): RSSapplied.com

  4. Les interfaces riches, ça existe depuis belle lurette. Seulement ici, j’ai compris qu’après coup qu’on parlait du Web ;-) Historiquement, le HTML a été conçu pour de la mise en page. Après est venu DHTML, avec du Javascript (ou autre) afin de rentre le fonctionnement du site plus interactif. Sans trop d’échanges serveur pour compenser la faiblesse du débit en général. Les besoins évoluant avec le débit, et pour contourner la difficulté, on a jugé bon de mettre en place toute une tringlerie côté serveur pour donner l’illusion d’un processus d’interaction continu (ASP.NET, Servlets Java .. etc ..), ou alors d’enrichir la partie client (Ajax, Flash, …) Pour moi, faire de l' »interaction continue » en Web, ça reste du bricolage. Développer en Javascript, d’accord c’est sympa, ça donne des résultats impressionnants, mais bon … Reprendre le code Javascript de quelqu’un d’autre, c’est une vraie galère, et tout le monde ne connait pas Flash non plus. Javascript est trop permissif. Il ne m’est pas rare de devoir repasser derrière du code dégueulasse impossible à maintenir, qu’on a gardé parce que « c’est beau ». Le développeur-artiste se fait mousser, puis se sauve. Son code jetable, est remplacé pages par pages au fur et à mesure des changements. Coûteux… Côté serveur, c’est sympa à développer, et très propre. A relire, c’est bien aussi. C’est orienté objet, et tout et tout .. Mais les résultats ne sont pas à la hauteur de ce qu’on peut attendre en Javascript « pur ». Les échanges navigateur-serveurs parviennent à donner l’illusion, mais pas de réaliser de l’interaction vraiment pointue côté client. Sauf avec des contrôles qui génèrent cette fois ci, le javascript, qu’il faut une fois de plus maîtriser correctement. Le design, le marketing … tout ça d’accord, c’est bien joli. Mais n’oublions pas la technique, et les gens « de l’ombre » qui bossent derrière pour donner du concret à tout ça. Je pense que la programmation Web côté client restera du bricolage infâme, malgré la beauté du résultat, tant qu’une grosse révolution ne se pointera pas. Est-ce que celle-ci s’amorce ? Va-t-on voir le « stateless » disparaitre pour de bon ? Celà ressemblera-t-il à un échange à la X11 ? Le développement du haut débit permettra t-il de s’affranchir de cet échange Get/Post/Redirect et de toutes les ruses que celà implique ? Verra-t-on un langage client digne de ce nom ? Que sera cette révolution ? Ajax ? Flash ? Avalon ? Pour répondre à la demande croissante en interactivité et en maintenabilité de ce qui devient de plus en plus des « vraies applications en ligne », je pense qu’une révolution est nécessaire.

  5. Et pour ceux qui ne connaissent pas flash et qui aiment le développement OUVERT côté serveur, il y a un truc génial et injustement inconnu : OpenLaszlo. A voir et à tester…

  6. un truc génial et injustement inconnu, tu es un peu dur avec moi Sébastien, j’ai ai déjà parlé à plusieurs reprises sur ce site… /Fred

  7. Je suis étonné que personne ne prenne en compte dans ce débat les problématiques de référencement lié a ces interfaces Rich… Fred C l’aborde au niveau de l’accéssibilité de l’info pour l’utilisateur (Point1) mais pas au niveau des robots… et ca me parait un des points fondamentaux aujourd’hui.
    Je trouve que l’Ours est un peu dur avec le marketing et le design…je dirai qu’heureusement que tous ces profils existent et travaillent en complémentarité…ou essaient du moins.

  8. Ben oui Damien, mais que veux-tu, je n’ai jamais pu me faire à cette cochonnerie de javascript, et je n’ai non plus jamais sorti une seule page Web au design potable… Alors voilà, je confie ces tâches à d’autres plus doués, tout en ravalant ma frustration derrière du middle-tiers écrit en C#. Il en faut aussi pour faire la vaisselle, pas vrai ? :)

Laisser un commentaire