L’avènement de nouvelles librairies Javascript ouvre régulièrement des nouvelles perspectives de développement pour les applications Internet. Les “petites” librairies Ajax, effets visuels et manipulation facilité du DOM sont désormais dépassées, il faut désormais utiliser des librairies plus complètes (et souvent plus complexes), très orientées éléments d’interface (boutons, panels etc…) pour être “dans le coup”. Aujourd’hui on parle de YUI, ExtJS, Dojo, SproutCore pour développer de nouvelles interfaces d’applications Internet.
Ces librairies permettent d’obtenir l’interface utilisateur d’une application Internet complètement en Javascript afin de lui donner un comportement très proche d’une application de bureau (glisser-déposer, copier-coller, barre d’outils, fenêtre modales…). Quels sont réellement les atouts de ces librairies ? Quel est le gain pour l’utilisateur final ?
Ne faisons nous pas fausse route en voulant absolument reproduire dans un navigateur le comportement souvent décrié des applications de bureau ? Ne perdons nous pas l’occasion de développer de nouvelles choses, de nouvelles manières de travailler, de naviguer dans des données, de les éditer, d’en créer de nouvelles ?
Aujourd’hui les développeurs préfèrent ces interfaces proches des applications de bureau car ils pensent que l’utilisateur s’y sent plus en confiance. Pourtant l’utilisateur lambda préfère GMail à RoundCube, ce dernier ayant un comportement trop similaire par rapport aux applications de bureaux qu’il utilise tous les jours.
Je prépare le développement d’une application Internet qui sera utilisée par des personnes qui sont à peine initiées à l’informatique. Cette application concurrencera dans une certaine mesure des applications classiques de type client/serveur. Pourtant cette application ne sera pas développée avec une interface calquée sur le modèle des applications de bureau car je pense qu’il sera beaucoup plus facile d’innover et de se démarquer de la concurrence en recherchant de nouvelles solutions de navigation plutôt qu’en appliquant des recettes des applications habituelles.
Je suis entièrement d’accord avec toi. Je suis moi même en train de développer une application web assez importante dont le but est de remplacer une application “de bureau” (avec plein de truc en plus permis par le web).
C’est bien une application WEB et pas une application de bureau, donc pourquoi vouloir copier le comportement d’une application de bureau ? Une appli web ne fonctionne pas de la même manière, n’est pas similaire “philosophiquement parlant” et surtout ne repose aps du tout sur le même modèle de développement ! (CF Getting Real par exemple) Et le développement influent directement sur l’appli elle même, évidemment :-).
Posté par p4bl0 le 29 juin 2008.
Il y a tout de même des avantages incomparables avec une solution client/serveur traditionnel comme les grilles de données avec validation automatique lors d’un changement de ligne.
Une structure web ne permet pas ce genre de traitement initialement, sauf usage intempestif de javascript et xhr.
Ce comportement là se doit d’être conservé.
En revanche, l’absence de menu contextuel avec le clic droit de la souris dans une appli web force les développeurs à intégrer une interface où toutes les actions sont visibles à l’écran, et ça, c’est un plus indéniable.
Bon, baignant là dedans depuis de nombreuses années, il y a des tonnes d’autres avantages/désavantages différenciant les deux applications (connexions persistantes à la base, gestion des transactions, verrous sur les lignes d’une table (dont le traitement est automatisé en client/serveur)…), mais une chose est certaine, il vaut mieux prendre de suite le plis des applications full web.
En revanche, aucune certitude sur la bonne technologie à employer. Vaut-il mieux rester sur des technologies scriptés comme le couple php/mysql et un navigateur, ou s’orienter vers des clients légers comme Flex ou Silverlight… pour l’instant il me semble que rien n’est tranché, l’avenir nous le dira (c’est bien là où PHP me semble faiblir d’ailleurs…)
Posté par Oliv le 25 juillet 2008.