|
Les
défauts actuels des " web-applications "
:
les
applications " webisées " (difficile de
trouver un vocable reconnu et agréable
à l'oreille - applications " client
léger " ? il semblerait que le terme "web
services" s'impose, même s'il ne me
paraît pas vraiment adapté) ont
hélas des défauts qui peuvent
gravement affecter l'expérience vécue
par leurs utilisateurs :
- Un
défaut mineur qui sera vite résolu
: les volumes de stockage de documents offerts
en ASP sont trop faibles.
- Les
applications ASP transitent via les tuyaux trop
étroits de l'internet, et les hauts
débits ainsi que la qualité de
transmission nécessaire au fonctionnement
satisfaisant de ces applications se feront
attendre encore quelques années (voir
veblog, les
fausses promesses du haut
débit).
Cet inconvénient est en partie amoindri
si l'application est placée dans un
serveur sur un réseau local, encore que
le nombre de données circulant sur le
plus performant des réseaux
(Réseau 1Gb/s) soit 3 à 6 fois
inférieure à la quantité de
données pouvant s'échanger dans le
même temps à l'intérieur
d'un seul ordinateur. Les applications les plus
gourmandes en puissance (3D, imagerie de
synthèse, etc...) auront beaucoup de mal
à fonctionner selon ce mode pendant
encore quelques temps.
- Le
plus gros défaut de ces applications,
hélas rarement perçu par les
services informatiques, est le recul qu'elles
font subir à l'utilisateur en terme
d'interface, recul pouvant affecter leur
productivité. En effet, les navigateurs
ont été conçus dans un but
bien précis : naviguer dans des
séries de documents reliés entre
eux par des liens hypertexte. Les barres de
menus, d'outils, d'adresse contenus dans les
navigateurs leurs sont propres et ne sont pas
adaptées à d'autres
usages.
Regardons
l'image ci dessous, représentant une
interface d'éditeur de texte
évolué vue à travers un
navigateur (en fait, cette interface provient d'un
serveur d'édition web à distance,
editthispage.com,
mais le principe est le même):
Les commandes du navigateur ne sont pas
adaptées à l'application
celle ci occupe une part insuffisante de l'espace
écran.
Apparemment,
la partie centrale du navigateur affiche une
interface rappelant celle d'un traitement de texte
classique. Mais en analysant plus finement cette
page, on voit que l'espace écran est
très mal utilisé : moins du tiers
pour la surface de saisie consacrée à
l'application. En outre, il est encombré de
commandes du navigateur qui n'ont rien à
voir avec l'édition de texte : signets,
recherche, l'icône internet explorer, plus de
70 commandes qui n'ont rien à voir avec la
tâche en cours...
Par
exemple, la touche "retour" du navigateur est ici
particulièrement perturbante, puisqu'elle ne
signifie ni l'effacement de la dernière
saisie ou l'annulation de la dernière
opération, mais bel et bien le retour sur la
page précédent l'application
"édition de texte". Si celle ci a
été moyennement programmée,
l'utilisateur peut en outre perdre ses saisies par
un appui accidentel sur cette touche. De
même, la fonction "enregistrer" du menu
fichier sauvegardera la page html et non le travail
en cours, obligeant le concepteur de l'application
à créer un bouton "enregistrer les
changements" en bas de la fenêtre de saisie,
et l'utilisateur à changer ses vieilles
habitudes et à ne pas utiliser la fonction
"enregistrer" du menu fichiers, etc...
On
me rétorquera qu'il est loisible de faire
ouvrir l'application dans une nouvelle
fenêtre, pour lesquelles on empêchera
les barres standard du navigateur de s'afficher et
pour lesquelles on recréera (à l'aide
d'images et de programmation DHTML) une pseudo
interface proche des applications bureautique
classiques. Cela ne supprimera pas les autres
inconvénients nés du passage à
travers un navigateur :
1.
Le support des fonctions d'annulation
à travers un navigateur est mauvais.
La plupart des applications bureautiques
classiques offrent plusieurs niveaux
d'annulation (fonction "annuler" du menu
"édition" dans la plupart des
applications standard), que le navigateur ne
sait pas reproduire. Il faut programmer ces
fonctions d'annulation au niveau du serveur, ce
qui est consommateur de temps et de
ressources.
2.
Les temps de réaction des
applications à travers un navigateur sont
incroyablement lents, car les navigateurs
actuels sont trop lourds. Bruce
"Tog"
Tognazzini,
grand professionnel de l'interface utilisateur
(un des pères de l'interface graphique
des premiers MacIntosh), considère que
les applications "client léger"
ramènent
l'utilisateur à des niveaux de lenteur
identiques à ceux qu'il avait connu en
1978,
à la naissance de la micro informatique.
Les utilisateurs ont souvent une perception
désagréable de décalage
entre le lancement d'une action et son
exécution.
3.
Le navigateur supporte très
médiocrement le "glisser-déposer
", pourtant bien utile dans de nombreuses
applications usuelles.
4.
la visualisation d'un travail à
travers un navigateur est rarement conforme
à son impression, car le support de
l'affichage "wysiwyg" (conforme à
l'écran à ce qu'il sera sur
papier) y est mauvais.
5.
Enfin, à travers un navigateur, le
programmeur n'est pas obligé de respecter
les règles de programmation propres
à un système d'exploitation
donné (ce sont ces règles de
programmation qui unifient les comportements des
menus, des clics de souris, etc... d'une
application à l'autre). Et les
concepteurs d'application, lorsqu'ils ont la
liberté de faire n'importe quoi, font
parfois... n'importe quoi. Tous les concepteurs
web récemment convertis à la
"web-lication" ne sont pas, loin s'en faut, des
spécialistes de l'interface
utilisateur...
Il
y a sans doute d'autres défauts aux
interfaces de ces applications " webisées ".
Ces défauts limitent le champ de ces
produits à des secteurs très
précis : applications privilégiant
les saisies textuelles ou à base de cochage
(QCM, groupware léger, et
éventuellement édition de texte), ou
focalisées sur l'exécution de
tâches simples. En revanche, les programmes
demandant une forte puissance et des saisies de
précision (dessin, vidéo, musique,
CAO, etc...) sont très mal adaptées
à un tel mode de fonctionnement.
Comment
remédier à cela ? sur la piste du
navigateur ultra léger.
Deux
pistes semblent envisageables pour améliorer
le support d'applications via un navigateur :
1.
Utiliser des plug-ins, comme flash 5,
pour programmer des interfaces d'application.
Flash 5, par ses possibilités de
programmation, son support du "glisser
déposer", amène un début de
solution aux problèmes
énoncés ci avant. Pour peu que
l'équivalent du "guide
méthodologique de développement
d'interfaces utilisateurs" (existant tant pour
windows que pour Mac) existe pour ce type de
logiciel, on pourrait voir apparaître des
initiatives intéressantes. Toutefois,
ajouter une couche logicielle
supplémentaire (flash) par dessus un
navigateur naturellement lent (explorer) et des
réseaux engorgés, ne rendra pas
l'application plus rapide...
2.
Créer un nouveau type de navigateur
"ultra léger", complètement
intégré à l'OS de la
machine, le "navigateur vide", et stocker
à part diverses interfaces utilisateurs
(dont celles du navigateur classique). Lors du
premier lancement d'une application, les
éléments d'interface seraient
récupérés de façon
transparente sur le serveur et installées
sur la machine de l'utilisateur. Au lancement
suivant, le navigateur ultra léger irait
récupérer la bonne interface dans
son disque dur, et l'application tournerait plus
rapidement. De plus, les programmeurs pourraient
à loisir répartir la puissance de
calcul entre le serveur et le poste de
l'utilisateur final, en transférant les
opérations très
répétitives au niveau poste
utilisateur.
Ce
navigateur ultra léger supporterait
"nativement" les niveaux d'annulation, l'affichage
"wysiwyg", le glisser-déposer, et son
intégration à un système
d'exploitation orienté réseau (voir
veblog, réseaux
du futur et gestion de l'overdose
d'information)
conférerait aux applications des
possibilités d'indexation et de gestion
électronique documentaire
accrues...
Malheureusement,
le manque de concurrence tant sur le marché
des systèmes d'exploitation que sur celui
des navigateurs (microsoft ayant dans ces deux cas
réduit la concurrence à des parts de
marché marginales) me laisse craindre que
ces évolutions, pourtant souhaitables,
restent à l'état de vœu pieux,
d'autant plus que la justice américaine
semble vouloir interdire à Microsoft toute
velléité d'intégration entre
navigateur et système... Dans ces
conditions, l'acceptation des applications
"webisées" par les utilisateurs sera moins
facile que ne le prévoient leurs
défenseurs les plus enthousiastes.
|
