Votre avis m'intéresse : un backoffice en xhtml ou en Flash ?

Bonjour,

J’ai besoin de vos avis, à tous, pour arriver à me décider sur la réalisation d’un backoffice.

J’hésites en effet entre une solution 100% Flash et une autre plus classique, en html (avec dans les 2 cas, du php/MySQL en coulisse)

Le message que vous lisez actuellement a également été posté sur le Forum Flash de Médiabox :

http://flash.media-box.net/index.php?showforum=18

L’idée, pour moi, est de croiser les expériences.

Voici déjà une piste de réflexion, qui ne suffit malheureusement pas à me faire pencher sur une solution plutôt qu’une autre.

1) En flash, une interface sobre est plus agréable à utiliser, car plus réactive qu’une interface html classique. On clique sur un bouton, et tout apparaît instantanément, les ressources de l’interface Flash étant déjà chargée en mémoire (à l’exception, bien sûr, des données nécessitant une requête vers le serveur). Un exemple : vous affichez un calendrier, il apparaîtra instantanément, alors que cela nécessiterait l’ouverture d’une nouvelle fenêtre de navigateur et le chargement de la page en html… Idem pour créer un explorateur de fichiers : en Flash, les icônes apparaîtront instantanément, contrairement à une page html.

2) En flash, il est plus facile d’indiquer à l’utilisateur une opération réseau (avec une pseudo barre de progression) qu’en html. Qui plus est, il est possible de traiter des actions de manières asynchrones, en exécutant une autre tâche pendant que l’interface attend la réponse du serveur.

3) L’accessibilité d’une animation flash laisse à désirer : mais est-ce vraiment un problème pour un backoffice ? D’autant que la plupart des backoffice html utilisent javascript, des tableaux, …

4) Les interfaces javascripts qui manipulent le DOM sont capricieuses, et souvent incompatibles avec tous les navigateurs. En flash, pas de problème à ce niveau là : si le plug-in existe pour un navigateur, on est sûr que la présentation apparaîtra de manière conforme à l’utilisateur.

A l’écriture des points ci-dessus, vous devez penser : pourquoi pose t-il la question, il semble mettre en avant Flash ? C’est vrai. Et pourtant, je n’arrive pas à me décider, surtout pour la raison suivante :

5) Quelle pérennité pour un backoffice Flash ? Le html, lui, me semble plus ouvert. Mais une animation Flash ? Aujourd’hui, mes backoffices sont en xhtml, et je n’ai jamais eu de retour négatifs. En Flash, un client me dira peut-être que l’animation lui plante l’ordinateur ? Quelle solution pour moi alors ? En xhtml, si problème il y a, le client peut changer son navigateur, et souvent, le problème n’est pas spécifique au backoffice (ce n’est que du code html). Mais alors pourquoi je ne reste pas en xhtml sans me poser de question ? Parce que en Flash, je peux proposer un éditeur plus robuste et convivial pour le client. La plus value est intéressante, je trouve. Le point 1) est important pour un client devant travailler chaque jour sur son backoffice.

S’il vous plait, et même si vous pensez que votre avis n’est pas important, faites en part ! Vos avis et expérience, m’intéressent.

Je vous remercie par avance.
Modifié par Yhann (26 Nov 2005 - 11:14)

Bonjour,

Problématique excellement posée. A laquelle je vais cependant apporter un réponse brutale. En tant que client (et non en tant que développeur), je n'investirai pas dans une solution "full Flash", malgré ses remarquables qualités développées ci-dessus, et en dépit du côté indéniablement très primitif des solutions actuelles basées sur HTML-CSS-DOM, mais pour de toutes autres raisons :
- Flash est potentiellement non pérenne
- Flash est non évolutif vers d'autres solutions
- Flash peut me placer, à court terme, face à un déni d'accessibilité qu'un changement de législation ou de jurisprudence me rendrait problématique.
- On m'a abondamment répété et on me répètera quotidiennement dans le mouvement d'industrialisation du Web associé aux standards que Flash, c'est une erreur. On me le répète sans discernement, certes... Mais le mal est fait, je l'ai entendu
Modifié par Laurent Denis (26 Nov 2005 - 11:39)

Bonjour Laurent,

Ta vision renforce mes craintes exprimées au point 5 de mon premier post.

Par contre, et en tant que client justement, "l'expérience utilisateur" n'est-elle pas importante également ?

J'ai l'impression que ce terme n'est jamais évoqué lorsque l'on parle de standard, mais finalement, n'est-ce pas un point essentiel ? Faut-il sacrifier la prise en main d'une interface par l'utilisateur ?

a écrit :
Flash peut me placer, à court terme, face à un déni d'accessibilité qu'un changement de législation ou de jurisprudence me rendrait problématique.

Je ne comprends pas, peux-tu en dire plus ? Et attention, je ne parle pas du frontend, que je développe en xhtml strict. Ma question porte uniquement sur l'interface d'administration du site.

Pour ma part, j'essaye de proposer à mes clients ce qu'il y a de mieux. Et le problème, pour moi, c'est qu'une interface Flash se rapproche du confort d'une application offline. Le travail quotidien dans un navigateur, sur une interface web, est lent et inconfortable. Et pourtant, j'ai du mal à me lancer dans un backoffice Flash, pour les raisons que tu donnes. Là est toute ma contradiction.

Merci pour ta première réponse.

Bonjour Yhann,

Si je peut me permettre, une interface d'administration de site demande un minimum de compétences techniques de la part de l'utilisateur, pour une tache, ben, d'admin, donc de pouvoir se dépatouiller avec une interface js relativement sobre.

"L'expérience de l'utilisateur" est effectivement importante, mais on est pas obligé de mettre du flash de partout, il y a des solutions plus "iso" qui apportent des réponses tout à fait acceptables d'un point de vue ergonomique.



(c'est un avis perso, mais je suporte pas les interfaces qui bougent tout le temps, et c'est un peu la dérive flash , les graphistes peuvent pas s'empecher de mettre des petites leds partout)

a écrit :
c'est un avis perso, mais je suporte pas les interfaces qui bougent tout le temps, et c'est un peu la dérive flash , les graphistes peuvent pas s'empecher de mettre des petites leds partout

Je suis entièrement d'accord avec toi, et c'est bien pour cela que le frontend de mes sites n'utilisent pas Flash.

Attention, je ne voudrais pas que ce sujet dérive en pour ou contre Flash.

Ici, il s'agit juste de créer une interface de mise à jour, en proposant le meilleur au client. Flash, en dehors de la possiblité de faire bouger des trucs dans tous les sens (possible d'ailleurs sans flash), permet les points abordés dans mon premier message.

Je ne reviendrai pas sur le pour ou contre le flash, accessible ou pas mais pour ma part ma réflexion serait je dois le dire bien égoïste.

Les outils de gestion de contenu ont tous des points communs. D’un site à l'autre ou d'un client à l'autre, certaines fonctions sont identiques...

Dans ce cadre de réflexion, j'ai pris comme principe de faire en sorte de ne jamais perdre de temps à créer du code non réutilisable afin de capitaliser sur mon temps de développement. Et dans ce contexte, la solution xhtml CSS, me permet d'utiliser des 'librairies" de fonctions qui ensuite seront présentées aux client via une feuille CSS qui lui est propre.

Donc si j'étais face à un choix comme celui qui te concerne, je me poserais d'abord cette question :

"La solution flash est t'elle aussi malléable que la version xhtml CSS ?
Ne vais-je pas perdre mon temps à chaque déploiement à adapter mes sources à chaque client ? "

Je ne connais pas beaucoup flash, je ne pourrais donc pas répondre à ces question, mais après avoir vu ce qu’un simple tag cold fusion peut faire notamment pour générer un tableau flash permettant de classer la liste qui y est affichée tu es en droit de te la poser