Je me base sur un cas très concrêt: celui de l'AFP, où les responsables informatiques ont mesuré un gain de productivité de 40% des journalistes entre la nouvelle console, basée sur RCP, et l'ancienne. Cf. cet article de 01 Net: http://www.01net.com/editorial/373461/l-agence-france-presse(...)
Ce gain de productivité s'explique dans cet exemple par une interface plus riche que l'ancienne en termes de gestion des flux d'information, de recherche, et d'édition en ligne du texte et des images.
Si on devait comparer une interface RCP à une interface web ajaxifiée, on ne retrouverait sûrement pas 40%, mais peut-être 10% ou 20%, en fonction des besoins des utilisateurs. Ici, on se place dans le cadre de gens qui ont besoin de gérer beaucoup d'information en même temps (y compris sur plusieurs écrans, ce qui à ma connaissance n'est pas évident à faire sur un navigateur), qui ont a travailler des informations multimédia, etc.
Cf. par exemple cette photo: http://flickr.com/photos/nuxeo/2082947465/ où on voit le rédacteur en chef du desk multimédias de l'AFP à Paris avec ses deux écrans, la dépêche et la photo sur lesquels il est en train de travailler sur l'écran de gauche, et les différents flux de dépêches textes et d'images à partir desquels il compose ses dépêches multimédias, ainsi que les flux de dépêches qu'il a à valider, sur l'écran secondaire, à droite.
Pourquoi un coût « pas forcément moins élevé » ?
Le développement d'interfaces utilisateurs en client riche Java (qu'on utilise les techno Eclipse RCP, autrement dit SWT/JFaces ou les technos Sun comme Swing) reposent sur des concepts qui sont maintenant connus et maîtrisés depuis des années, alors que les interfaces riches en client Web (autrement dit Ajax) sont encore toutes récentes (2-3 ans), avec un foisonnement de bibliothèques et un outillage (support des IDE) encore moyen. Je n'ai à ce jour pas suffisamment de données pour dire laquelle de ces deux approches est la moins lourde, en tout cas pour des applications relativement complexes, avec beaucoup de dépendances entre les éléments d'interface, etc., ce qui est le cas qui nous intéresse. Mais il me semble qu'il y a de bons arguments pour dire qu'à partir d'un certain niveau de complexité, c'est le client riche (ou lourd) qui gagne.
Par ailleurs, pour ce qui concerne les gains de productivité ou en tout cas la diminution de la charge de développement sur un projet d'ECM basé sur Nuxeo par rapport à des technologies similaires, propriétaires ou open source, nous n'avons évidemment pas témoignage direct puisque tous les projets que nous faisons sont basés sur les technologies Nuxeo. Mais plusieurs de nos camarades intégrateurs nous ont affirmé, sans souhaiter être cités pour l'instant, pouvoir chiffrer des charges de développement moins élevées avec Nuxeo qu'avec les autres plateformes qu'ils pratiquent.
Oui, mais ces boutiques-là devraient pouvoir sortir de leur logique pour voir ce qui se fait à côté.
Il serait illusoire pour nous de chercher à imposer notre technologie à tout le monde d'un seul coup, surtout lorsque cela représente un effort d'apprentissage important de nouvelles technologies. Notre cible principale est les développeurs Java et nous pensons que sur ce point nos efforts pour rendre le framework Nuxeo accessible ont déjà payé, ce qui ne nous empêche pas de travailler (notamment sur les outils) pour le rendre encore plus accessible.
Concernant les développeurs de type "LAMP" (PHP/RoR/Django/...), le nouveau framework web léger que nous allons annoncer prochainement (je ne manquerai pas de poster une annonce sur linuxfr) devrait répondre à leurs attentes.
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Coût d'une telle solution
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo RCP 2.0 : plateforme client riche pour applications documentaires et multimédias. Évalué à 3.
Je me base sur un cas très concrêt: celui de l'AFP, où les responsables informatiques ont mesuré un gain de productivité de 40% des journalistes entre la nouvelle console, basée sur RCP, et l'ancienne. Cf. cet article de 01 Net:
http://www.01net.com/editorial/373461/l-agence-france-presse(...)
Ce gain de productivité s'explique dans cet exemple par une interface plus riche que l'ancienne en termes de gestion des flux d'information, de recherche, et d'édition en ligne du texte et des images.
Si on devait comparer une interface RCP à une interface web ajaxifiée, on ne retrouverait sûrement pas 40%, mais peut-être 10% ou 20%, en fonction des besoins des utilisateurs. Ici, on se place dans le cadre de gens qui ont besoin de gérer beaucoup d'information en même temps (y compris sur plusieurs écrans, ce qui à ma connaissance n'est pas évident à faire sur un navigateur), qui ont a travailler des informations multimédia, etc.
Cf. par exemple cette photo: http://flickr.com/photos/nuxeo/2082947465/ où on voit le rédacteur en chef du desk multimédias de l'AFP à Paris avec ses deux écrans, la dépêche et la photo sur lesquels il est en train de travailler sur l'écran de gauche, et les différents flux de dépêches textes et d'images à partir desquels il compose ses dépêches multimédias, ainsi que les flux de dépêches qu'il a à valider, sur l'écran secondaire, à droite.
Pourquoi un coût « pas forcément moins élevé » ?
Le développement d'interfaces utilisateurs en client riche Java (qu'on utilise les techno Eclipse RCP, autrement dit SWT/JFaces ou les technos Sun comme Swing) reposent sur des concepts qui sont maintenant connus et maîtrisés depuis des années, alors que les interfaces riches en client Web (autrement dit Ajax) sont encore toutes récentes (2-3 ans), avec un foisonnement de bibliothèques et un outillage (support des IDE) encore moyen. Je n'ai à ce jour pas suffisamment de données pour dire laquelle de ces deux approches est la moins lourde, en tout cas pour des applications relativement complexes, avec beaucoup de dépendances entre les éléments d'interface, etc., ce qui est le cas qui nous intéresse. Mais il me semble qu'il y a de bons arguments pour dire qu'à partir d'un certain niveau de complexité, c'est le client riche (ou lourd) qui gagne.
Par ailleurs, pour ce qui concerne les gains de productivité ou en tout cas la diminution de la charge de développement sur un projet d'ECM basé sur Nuxeo par rapport à des technologies similaires, propriétaires ou open source, nous n'avons évidemment pas témoignage direct puisque tous les projets que nous faisons sont basés sur les technologies Nuxeo. Mais plusieurs de nos camarades intégrateurs nous ont affirmé, sans souhaiter être cités pour l'instant, pouvoir chiffrer des charges de développement moins élevées avec Nuxeo qu'avec les autres plateformes qu'ils pratiquent.
Oui, mais ces boutiques-là devraient pouvoir sortir de leur logique pour voir ce qui se fait à côté.
Il serait illusoire pour nous de chercher à imposer notre technologie à tout le monde d'un seul coup, surtout lorsque cela représente un effort d'apprentissage important de nouvelles technologies. Notre cible principale est les développeurs Java et nous pensons que sur ce point nos efforts pour rendre le framework Nuxeo accessible ont déjà payé, ce qui ne nous empêche pas de travailler (notamment sur les outils) pour le rendre encore plus accessible.
Concernant les développeurs de type "LAMP" (PHP/RoR/Django/...), le nouveau framework web léger que nous allons annoncer prochainement (je ne manquerai pas de poster une annonce sur linuxfr) devrait répondre à leurs attentes.
"There's no such thing as can't. You always have a choice." - Ken Gor