C. XFORMS

XFORMS est un standard du W3C visant à supplanter HTML pour la conception de

formulaires sur le web. Le constat est que les formulaires HTML mélangent les données

et la forme. XFORMS spécifie que les données et la présentation doivent être séparées

dans des sections différentes. La partie « données » est fortement typée grâce à

l’utilisation des XML-Schema. La norme XForms a été dès le début conçue pour

enrichir la gestion d'un formulaire tout en le rendant indépendant du support. Les

principaux atouts de XFORMS sont sa réutilisabilité (on peut créer plusieurs

formulaires par page Web, ou bien un seul pour plusieurs pages), son faible besoin de

programmation (la validation de certaines données est faite par le formulaire lui-même)

et son indépendance vis-à-vis de la plate-forme. La spécification prévoit le support sur

ordinateur, terminaux mobiles portatifs (Palm, PocketPC, téléphone...), télévision,

imprimante et scanner. Sur imprimante et scanner par exemple, un utilisateur devra

pouvoir imprimer un formulaire, le remplir à la main, et scanner le résultat pour le

renvoyer sur le réseau au même titre qu’un formulaire WEB.

La Figure II-16 illustre la philosophie de XFORMS. Avec XFORMS, le concepteur

décrit un formulaire contenant des types de données à saisir (texte, numéro, choix, etc.) :

c’est la partie fonctionnelle de l’application (le XForms Model). Un autre langage

(XForms User Interface) est utilisé pour décrire comment, selon le contexte

(plate-forme et préférences du navigateur), le formulaire sera rendu à l'utilisateur. Le

formulaire ne sera pas présenté de la même façon selon qu’il sera rendu sur un

ordinateur de bureau ou sur un téléphone. Les XForm Models peuvent être rendus dans

d’autres langages que le XForms User Interface : par exemple, directement en XHTML

ou WML.

a) b)

Figure II-16 : a)XForms Model définit la structuration des donnés XML manipulées par le formulaire. XForms User Interface définit la façon de les présenter. b) d’autres langages peuvent être utilisés pour

assurer la présentation des formulaires XFORMS (ex : XHTML, WML, etc.).

Je m’intéresse ici plus particulièrement au langage de présentation XForms User

Interface (XFormsUI). Il s’agit d’un langage XML visant à remplacer les balises liées

au formulaire du XHTML. Ces balises sont de trop bas niveau sémantique. Les balises

XFormsUI sont orientées tâches, contrairement aux balises HTML, plutôt orientées

présentation. La Figure II-17 détaille les balises XFormsUI et leurs correspondants

HTML.

XFormsUI HTML Description

input <input type=« text »> Champ de texte court

textarea <textarea> Champ de texte long

secret <input type=« password »> Texte confidentiel

output SANS EQUIVALENT Affichage de valeur

range SANS EQUIVALENT Sélection d’intervalle

select1 <select> ou

<input type=”radio”>

Sélection unique

select <select multiple=”multiple”> ou

<input type=”checkbox”>

Sélection multiple

upload <input type=« file »> Chargement de fichier ou de

périphérique

trigger <button> Déclencheur d’événement

submit <input type=« submit »> Envoi du formulaire

Figure II-17 : Correspondances entre les balises XFormsUI et les balises HTML.

Les balises XFormsUI ne sont pas associées à une présentation particulière. C’est à

l’interpréteur XForms (en pratique le navigateur Web) qu’incombe de trouver une

présentation adaptée à la tâche (ex : select1) ET au concept (ex : date). Un choix simple

d'éléments non typés peut classiquement être représenté par le navigateur sous la forme

de boutons radio ou menu déroulant (Figure II-18).

Figure II-18 : Deux représentations possibles d’un choix simple pour un navigateur.

Un choix multiple d'éléments non typés peut classiquement être représenté par un

navigateur sous la forme de cases à cocher ou d’une liste d’éléments dont les sélections

sont surlignées ou cochées (Figure II-19). La propriété appearance permet de spécifier à

l’interpréteur si tous les choix doivent être proposés : tous (full), un certain nombre avec

possibilité de navigation (compact) ou un minimum de choix avec la possibilité

d’afficher de façon temporaire les autres (minimal) (Figure II-19).

appearance="full" appearance="compact" appearance="minimal"

Figure II-19 : Différentes présentations du choix selon la balise appearance fixée par le concepteur.

La Figure II-20 illustre des présentations possibles pour un spécificateur de date.

L'utilisateur peut soit entrer la date au clavier, soit la choisir dans un calendrier. Le

choix de la présentation est fait par le navigateur.

Figure II-20 : Différentes présentations pour un spécificateur de date.

Conclusion

XForms a été conçu en ayant à l’esprit que le WEB est et sera de plus en plus accessible

via des terminaux aux caractéristiques variées (PDA, téléphones, télévisions, PC de

bureaux, imprimantes, fours, etc.). Aussi, les parties « structure des données » et

« présentation » doivent-elles être séparées et les balises orientées tâches et non plus

présentation. Le polymorphisme est à la charge des interpréteurs (les navigateurs) qui

devront sélectionner une présentation adéquate en fonction de la plate-forme cible, de la

tâche et du concept manipulé.

XForms ne couvre que les IHM de type formulaire. La critique se limite donc à ce

cadre :

• XForms ne modélise pas les opérateurs entre tâches. Il ne semble pas

possible de modéliser directement en XForms une séquence ou un

entrelacement (qui pourrait être rendu au travers d’onglets par exemple).

• XForms ne laisse aucune possibilité au concepteur de préciser quelles sont

les présentations souhaitées. L’intégration de widgets sur mesure n’est pas

non plus possible.

• Les présentations dépendent du navigateur utilisé. Il est à craindre qu’elles

soient substantiellement différentes d’un navigateur à l’autre. Par exemple,

tous les navigateurs ne représenteront peut-être pas, par un calendrier, le

choix d’un jour de l’année, y compris sur des plates-formes similaires (par

ex : FireFox et Internet Explorer sur PC).

Tableau II-5 : Grille d'analyse pour XForms.

Niveau sémantique Les balises XFormsUI représentent des tâches utilisateur.

Empreinte

technologique

Le WEB.

Extensibilité Le langage est standardisé et non extensible par un concepteur.

Malléabilité Les styles CSS sont applicables.

Contrôlabilité /

Prévisibilité du rendu

Le rendu de l’interacteur est à la charge de l’interpréteur XForms. Il

n’est pas contrôlable par le concepteur. Celui-ci peut seulement

parfois donner des indications de rendu (ex : l’attribut

« appearance » de la balise select). Il est potentiellement

imprévisible puisqu’il pourra varier d’un interpréteur à l’autre.

Dans le document Modèles et outils pour la conception et l'exécution d'Interfaces Homme-Machine Plastiques, Ecosystème (Page 34-37)