Ingénierie du document

Trop souvent on ne dispose pas de moyen efficace pour régler un problème de performance au niveau de l’affichage . Aussi, il est difficile de savoir comment faire pour choisir d’attendre un peu plus pour augmenter la qualité, d’autant plus qu’on ne sait pas quel sera cette quantité «un peu plus», 1 sec, 30 secs ou 2 minutes, qui sait ?

Par exemple, si on veut afficher une scène 3D dont la réflexion spéculaire influence grandement la vitesse du rendu à un tel point que l’attente est pénible. Alors, on sera prêt à sacrifier des détails pour obtenir un résultat plus rapidement. Le problème, c’est comment savoir que la réflexion spéculaire est la cause principale de cette dégradation. Pire encore, même en sachant que cette option est la cause du ralentissement, on n’a pas nécessairement la possibilité de désactiver cette seule option. En effet, on a souvent des choix du genre: ‘performance’, faible/moyenne/grande ou de l’autre perspective : ‘qualité du rendu’, faible/moyenne/grande.

Pour résoudre ce problème, il faudrait au moment même du rendu disposer de statistiques sur les performances, et ce, pour chacune des options utilisées. Puis, juste à côté avoir le choix de conserver ou de désactiver l’option. Il faut donc absolument ajouter de la rétroaction sur les ressources utilisées pour que la personne qui consulte le document puisse faire des choix éclairés sur le compromis qualité/vitesse du rendu.

Pour la diffusion, la compression joue un rôle de premier plan. En effet, lorsqu’il s’agit de diffuser l’information, la largeur de bande à un coût en plus d’avoir une incidence directe sur le temps d’attente. On peut donc accepter de perdre un peu de qualité afin de réduire la taille de façon significative.

Le choix de l’algorithme est souvent le fardeau de l’utilisateur alors que ce dernier ne connait pas les particularités internes des alternatives. Afin de pouvoir prendre une décision éclairée, toutes les techniques de compression devraient être appliquées à l’image, ainsi l’utilisateur pourrait choisir en fonction le plus probant.

Le tableau doit donc montrer, l’image (pour juger de la qualité) et la taille avec le temps requis pour la décompression. Avec ces informations, le créateur du document pourra choisir la stratégie de compression qui convient le mieux.

Exemple:

1000×1000 px | Original | GIF | PNG | TIFF | JBIG | JBIG2
Taille | 10,000 Ko | 120 Ko | 89 Ko | 133 Ko | 78 Ko | 45 Ko
Décompression | | 1,3 s | 1,3 s | 1,8 s | 1.8s | 1,1 s

Une interface épurée, avec pour seul outil un crayon ou mieux encore, des corrélations avec les périphériques d’entrée (ex. clavier, souris, WebCam). Les fonctionnalités avancées seraient ajoutées au fur et à mesure que l’on explore l’application. Un système de menu où les choix les plus souvent utilisés sont placé en premier et ceux qui le sont rarement s’estompent.

Pour faire apparaître les nouvelles entrées, on peut imaginer un système basé sur les jeux vidéo d’aventure, où l’utilisateur doit découvrir à l’aide d’indice comment se servir d’un nouvel objet. Des tutoriels pourraient prendre la forme des ‘mission mode’ des jeux de combats.

De plus, partager ses menus les plus utilisés avec la communauté pourrait servir de ciment entre les différentes catégories d’utilisateurs de l’application.

C’est ma vision de l’interface utilisateur «incrémentale». Les options avancées apparaissent graduellement par enrichissement progressif des compétences de l’utilisateur.

Un aspect important du traitement des objets numériques est l’utilisation de métadonnées. Bien que ces dernières peuvent s’avérer d’une grande utilité, elles peuvent aussi devenir très décevantes. Le texte suivant présente avec humour quelques objections pertinentes http://www.well.com/~doctorow/metacrap.htm.

Une première remarque, c’est que les métadonnées calculées (déduites ou inférées) sont plus fiables que celles qui sont données par le créateur d’un document, à moins de disposer d’un mécanisme pour mesurer la confiance que l’on peut avoir envers l’auteur. Un exemple, c’est le page Rank calculé par Google à l’aide du nombre de liens entre les pages Web.

Une deuxième remarque, c’est que le document que l’on produit et destiné à être consulté par l’humain et que les métadonnées elles sont destinées à être utilisé par la machine. On a donc le fardeau de maintenir deux structure informationnelle, celle du texte du document et celle décrivant les objets numériques du document. Pour réduire ce fardeau, il faut une interface utilisateur qui produit automatiquement (par déduction ou consultation d’une ressource fiable) les métadonnées. Un exemple, c’est l’extraction de MP3 d’un CD de musique. Pour identifier l’auteur, l’album et le titre de la chanson la base CDDB peut-être utilisé sans trop de risque de se tromper. Est-ce que tous les outils d’extraction utilisent systématiquement cette base ? Je ne crois pas, alors que ça devrait être le cas. Il n’y a aucune raison de se priver de ces précieuses métadonnées jugées valides.

C’est indéniable, un aspect important de la révolution des documents Web est la possibilité de créer et de suivre des liens. Cependant, ces liens sont simple, c’est-à-dire de 1 à 1 et on ne connait pas la sémantique. Une structure plus riche de lien serait peut-être souhaitable. Par exemple, pour la cadinalité des liens, on voudrait aussi avoir des liens de 1 à N, de N à 1 et même de N à N. Pour ce qui est du sens, on voudrait pouvoir étiquette ces liens, par exemple est-ce un lien d’appartenance à un groupe ou bien une étape dans une suite.