Taxinomie des systèmes auteurs

Pour permettre de situer ce que peuvent faire les systèmes auteurs, il ne suffit pas de les classer selon le niveau de puissance qu'ils offrent, il faut aussi les distinguer par le type d'applications qu'ils permettent de réaliser au mieux. Généralement, des systèmes auteurs de puissance comparable se prêtent plus à certains types de réalisations que d'autres. La typologie de classement proposée ici repose sur la métaphore de la table de montage employée par chacun des systèmes auteurs. En effet, tous les systèmes auteurs possèdent au minimum le niveau de la table de montage, et, souvent, des systèmes auteurs utilisant la même métaphore de montage sont appropriés pour construire le même type d'applications multimédia.

Les systèmes auteurs existants peuvent donc être classés en quatre catégories, suivant la métaphore qu'ils utilisent pour intégrer tous les médias dans une application (image, son, vidéo, texte) [Goffinet 02].

3.5.1 La métaphore de la carte

L'intégration et l'interaction des médias se font autour du concept de la carte. L'unité logique sur laquelle on travaille est la carte. Elle porte un nom, elle peut avoir des scripts associés, elle contient des champs, des boutons et des images. Elle est le réceptacle naturel de tous les objets, donc de tous les médias. Le fonctionnement de l'application est centré sur des liens entre objets situés sur une même carte ou sur des cartes différentes.

Les systèmes basés sur cette métaphore sont bien adaptés à des applications de type "livre électronique" où l'on tourne les pages à l'écran, et où l'on parcourt des informations selon une structure arborescente pas trop compliquée. Ils permettent aussi des choses plus complexes, puisqu'ils comportent tous un langage de scripting, et souvent admettent des commandes externes (mais au prix d'efforts proportionnels à leur complexité).

Par contre, lorsque l'interactivité devient fort complexe, ou lorsque les animations à réaliser sortent des simples effets prévus, ils ne peuvent plus satisfaire à la demande. De même, le fait pour la plupart de posséder un langage de scripting interprété peut poser des problèmes si la performance en temps d'exécution est un facteur clé. On réservera donc ces systèmes auteurs à

des applications simples ou à la réalisation d'interfaces avec des logiciels externes qui en sont mal pourvus. On trouvera dans cette catégorie Hypercard, (Mac), MetaCard (Unix) Toolbook (PC).

3.5.2 La métaphore de la ligne du temps

Les différents médias appartenant à l'application que l'on réalise sont affichés ou joués en fonction d'un scénario temporel qui est spécifié par son concepteur. Les objets apparaissent et disparaissent de l'écran selon un schéma temporel bien défini. On ne retrouve plus ici le concept de carte, mais celui de scène, d'acteurs et de scénario.

La table de montage se prête bien ici à construire des logiciels multimédias qui sont essentiellement des animations, telles que, par exemple, des shows de présentation interactive, des bornes de musée, etc. Mais, comme pour les systèmes de cartes, l'interaction ne doit pas être trop complexe (multiples branchements décidés en fonction de nombreux paramètres), sinon l'outil se révèle moins bien adapté à ce que l'on veut faire. Et ceci même s'il y a des possibilités assez riches de scripting et de commandes externes.. Exemples : MacroMind Director (Mac et PC), Passport

Producer (Mac).

Figure 3.2. La table de montage de Director (une piste contient au plus un média)

3.5.3 Les diagrammes d'icônes

Dans la logique du montage par diagramme d'icônes, les écrans et les objets qui y sont liés s'enchaînent en fonction d'un organigramme défini par le concepteur de l'application. On part donc de la dynamique de l'interaction avec l'utilisateur pour construire, de façon visuelle, son application multimédia. La colonne vertébrale de l'application est un diagramme d'icônes qui décrit les événements qui s'enchaînent dynamiquement (par exemple, jouer un son ou entamer un dialogue avec l'utilisateur).

Les systèmes basés sur des diagrammes d'icônes se prêtent bien à la formation. Ils sont parfaitement adaptés à l'interactivité et aux traitements que cela entraîne, parce qu'ils offrent dès le départ l'arborescence qui correspond aux multiples branchements possibles. Ils offrent aussi un niveau de scripting approprié, bien que l'algorithmique qu'ils entraînent ne soit pas toujours à la portée du premier venu. Exemples de ce type de logiciels : Authorware (Mac et PC), IconAuthor (PC).

Figure 3.3. Construction d'une application avec AuthorWare 3.5.4 Les systèmes hypertextes améliorés

La logique employée ici pour construire l'application est basée sur l'utilisation de liens de type hypertexte. Les différents éléments de l'application multimédia sont décrits dans un fichier texte,

qui est ensuite parcouru manuellement pour marquer les différents objets, les relier entre eux et leur associer des actions. Au moment de l'exécution de l'application on parcourt les écrans successifs au travers de clicks souris sur des morceaux de texte, des images, etc.

Avec cette catégorie de systèmes auteurs, on reste fort limité dans la gestion de l'interactivité avec l'utilisateur. Ces systèmes s'adaptent bien à l'élaboration d'aides en ligne pour d'autres logiciels. Ils améliorent ainsi les systèmes d'aide habituels, limités à de l'hypertexte. Ils s'adaptent aussi particulièrement bien aux systèmes manipulant de grosses quantités de texte ou de données textuelles, du type encyclopédies. On trouvera dans cette catégorie de systèmes : Microsoft

MultiMedia Viewer (PC).

3.5.5 Systèmes généralistes et systèmes spécialisés

Bien souvent, les systèmes auteurs les plus répandus sur le marché sont des systèmes généralistes, c'est-à-dire qu'ils contiennent des fonctionnalités standards qui satisfont aux besoins de nombreux utilisateurs venant d'horizons différents. Mais le prix à payer pour cette généralité est souvent que le système auteur n'est pas optimal pour une catégorie d'utilisateurs bien précise. La généralité implique une multitude de fonctionnalités dont l'utilisateur n'a pas vraiment besoin, et un noyau d'autres fonctions qui devrait être développé davantage pour correspondre à ses attentes. C'est dans cette optique de spécialisation des fonctionnalités que l'on retrouve les « systèmes auteurs spécialisés », par exemple un système auteur dédié à l’apprentissage du langage Prolog.

3.5.6 Portabilité

Une propriété des systèmes auteurs à ne pas négliger est leur capacité à pouvoir créer des applications multimédias tournant sur d'autres plateformes que celle sur laquelle ils ont été développés. On observe ainsi que le temps des systèmes auteurs dévolus à une plateforme unique sera bientôt révolu. Par exemple, beaucoup de systèmes auteurs de renom qui ont vu le jour dans le domaine de la micro-informatique sur Macintosh (Director, Authorware) permettent maintenant de générer une application tournant aussi bien sous le MacOS que sous MS-Windows. C'est un aspect qui peut être important, tant les coûts de passage d'une plateforme à l'autre ont étés dans le passé un obstacle majeur à la diffusion de certains produits.

Par contre, ce qui est loin d'être acquis, c'est la compatibilité des systèmes auteurs entre eux. Si, par exemple, une animation créée avec MacroMind Director peut s'intégrer facilement dans

Authorware, c'est plutôt l'exception dans ce domaine. Lorsque l'on travaille avec un système

auteur, on peut difficilement en changer en cours de route sous peine de devoir tout recommencer à zéro. Une application créée avec l'un de ces systèmes n'est bien souvent pas récupérable par un autre. Il y a là une réelle fermeture des systèmes auteurs entre eux.