Y at-t-il une utilité à déplacer le problème ?

Hello.

<disclaimer>
Le premier qui dit Flash est pendu en place publique, OK. Mais pour le second, c'est pas grave, on est vendredÿ, on lui dira rien, surtout s'il se renouvelle.
</disclaimer>

Je vais taper dans une ou deux évidences, et je vais le faire grossièrement, à très gros traits. Mais vers la fin, je vais dire des trucs moins triviaux.

L'interface (graphique ou non) est le véhicule de l'information, dans l'expérience utilisateur. Elle ne l'est pas dans l'accès "machine" au contenu, où elle n'est pas supposée être utile, et se trouve théoriquement ignorée (théoriquement, car il existe par exemple les mécanismes de compensation des défauts d'intégration, comme lorsqu'un lecteur d'écran suppute que le texte anonyme placé immédiatement à gauche d'un champ de formulaire est son label).

Peu importe le media de cette interface, qui peut être graphique ou non : la problématique est la même que ce soit en partant d'une interface définie pour le media screen, speech, tactile, ou un diffuseur de parfums.

Qu'elle soit graphique ou scatologique, c'est un véhicule et non la source de l'information, selon le canon des standards, qui n'a à ma connaissance encore pas été remis en cause avec pertinence, faute par exemple de réponse positive et générale à "Pourquoi limitez-vous votre audience ?", "Pourquoi augmentez-vous les risques non maîtrisés?", "Pourquoi limitez-vous votre propre maîtrise sur la diffusion de vos contenu ?". Cela laisse la place à des exceptions, bien-sûr. Exceptions, on a dit, dont il reste à chaque fois à examiner le contexte très attentivement pour mesurer leur pertinence, aucun des exemples précédemment fournis n'ayant d'ailleurs été convainquant (j'ai beaucoup aimé Audi, qui est tout sauf un exemple de Web maîtrisée et spécifiquement "expérience de la marque").

Mais bref... l'interface est le relais indispensable lors de l'expérience utilisateur (d'accord, l'information est dans le contenu structuré, indépendamment de sa présentation, mais on ne consulte jamais cette structure nue : désactiver CSS et les images, par exemple, ne fait qu'appliquer une autre couche graphique, celle de l'UA. Désactiver celle de l'UA laisse celle de l'utilisateur. Désactiver la "couche graphique"... Arsène n'a jamais expliqué ce qu'il entendait par ce concept à mon avis très imprécis, allant jusqu'à dire qu'on pouvait se passer de l'interface graphique sans désactiver CSS par exemple. Cela dit personne ne le lui jamais demandé non plus). Quelques-soient les opérations efectuées sur le contenu, il y aura une expérience utilisateur au bout, et une interface. J'ose espérer que cela reste le but du jeu

De même que la séparation entre le contenu structuré et sa mise en forme n'avait pas d'autre but que de mieux les marier, le Web sémantique, par exemple, n'a pas pour but l'expérience de la machine, mais celle, finale, de l'utilisateur. On en sépare pas pour jeter, mais pour utiliser. Et nous sommes les utilisateurs.

A noter : le caractère indispensable de l'interface n'est évidemment pas propre au Web et celui-ci n'apporte rien de neuf à cet égard: elle est propre à toute expérience de l'information, quelque-soit le support. Nous accédons toujours à une représentation de l'information, et non à celle-ci. Nos machines aussi. Sur le Web, cette représentation elle-même, en fait, comporte plusieurs aspects: le graphisme en est un, mais pour tout dire, la structure HTML en est une autre : Le HTML est une représentation de l'information, pas l'information. Paf, zut, dégât collatéral: le HTML est mort.

Mais ne désespérons pas Billancourt et revenons à nos moutons : si on pose cette représentation structurelle comme étant la source, le graal, le Bââl-Moloch, ce que vous voudrez, et ce qui est une démarche tout à fait pertinente... quelles sont ses limites ? Sa nature ou l'état de l'art, aujourd'hui, lui permettent-elle d'être suffisante, c'est à dire, dans ce questionnement, suffisante pour qu'une interface pertinente puisse en être déduite à coup sûr ? Il est immédiatement évident que non. Mais ce n'est pas une limitation par nature. Juste l'état de l'art.

(au passage, j'ai du mal avec "les marketeux et le contrôle"). D'abord, les gens du marketing sont rarement des serial killers ayant à ce point le besoin d'"avoir le contrôle". Ensuite, ces gens-là seraient ravis de pouvoir juste ne pas se faire complètement baiser en cas de personnalisation de l'expérience utilisateur. Pas contrôler, juste ne pas se faire baiser. Ofrez-leur la possibilité de décrire de manière sémantique l'expérience utilisateur qu'ils projettent, et ils seront tout contents et vous aussi.)

Revenons au mouton et à notre dispute sur comment on le dessine : à ce stade, un des concepts qui peut venir dire "coucou ? Je suis là ?" est celui de l'ergonomie. Le plus petit dénominateur commun sur lequel on arrivera sans doute à obtenir un accord dans ce genre de sujet trollesque est que la représentation graphique (ou vocale, ou tactile, etc.) est l'instrument de ce besoin d'ergonomie. Ce n'est pas le seul exemple que je pourrais prendre, mais j'espère qu'il sera assez consensuel : Enlevez l'ergonomie, et vous arrivez à situer assez précisément où est notamment la perte de sens quand on enlève la fameuse "couche graphique".

Bwa, c'est pas grave, je/l'outil vais/va rajouter la mienne/sienne. Mais... il n'existe pas de format de description de l'ergonomie associée à un contenu ou à un service. L'entreprise de conceptualisation ou d'abstraction qui serait nécessaire à une telle possibilité n'a, à ma connaissance, pas encore été entreprise, ou transformée en outil. On peut exploser un site ou un service en autant de couches que l'on veut, il y a un certain travail en amont qui s'appelle ergonomie et qui ne sera pas transcriptible aujourd'hui en tant que tel. Et qui est indissociable de la valeur de l'information dans l'expérience utilisateur qui est le but du jeu (ça, c'est peut-être propre au Web, tiens).

En fait, notre souci est peut-être là : des aspects nécessairemment associés à un contenu (avec un degré de nécessité variable selon le contenu spécifique) ne sont pas gérées en tant que telles, de manière explicite et formalisée, ou structurée si vous préférez. C'est le cas de l'ergonomie. Mais c'est aussi le cas de l'"expérience de marque" que yoddl (yodl ? enfin, bref, celui auquel nous pensons tous) mettait en avant : certes, on peut la voir comme de la pure mise en forme. Mais je trouve très intéressant que que l'on soit train de tenter de la rendre exploitable sémantiquement à travers le devéloppement d'API et de nouvelles capacités d'outils transposant un contenu prévu pour une mise en forme graphique dans un media non graphique (là, encore, les lecteurs d'écran, pour rester sur un exemple familier).

Bref, nous ne sommes pas encore à même de décrire certaines couches de manière suffisante. Mais <mode provocateur is back>ce n'est pas une raison pour les jeter </>

Lâchez les fauves.
Modifié par Laurent Denis (10 Oct 2008 - 08:49)

Laurent a écrit :
...allant jusqu'à dire qu'on pouvait se passer de l'interface graphique sans désactiver CSS par exemple. Cela dit personne ne le lui jamais demandé non plus)

Hi hi, content que quelqu'un l'aie débusquée cette dernière "hénaurmité" de mon dernier post. Ça fait au moins un qui lit et analyse en même temps Je me demandais depuis 24h si on pouvait lancer des choses comme ça.
Et merci à Florent d'avoir fermé le topic.

Laurent Denis a écrit :
Mais... il n'existe pas de format de description de l'ergonomie associée à un contenu ou à un service.

Merci. C'est l'idée que j'avais quand je disais qu'il manquait un format de description d'interface, et que je verrais bien Fl... pardon Silverlight, en "feuille de style".

Parce que l'interface, l'ergonomie, ce n'est pas la couche graphique, et ça n'est pas le contenu non plus. C'est à cheval sur les deux, et ça concerne l'ensemble des ressources d'un contenu ou d'un service, qu'on regroupe actuellement... heuu... à l'arrache.

(apparté: c'est marrant comme les sujets ont tendances à être fermés ici, alors que tout le monde discute et que finalement il dse réouvre à coté . Au moins il n'a pas été purement supprimé comme celui sur le portage... bref)

Laurent, enfin un discours censé, et finalement pas loin de ce que je tente de dire depuis le départ. Mais je nuance, parceque je pense que ça n'est pas qu'une question d'ergo. Vous allez voir que c'est très simple, pourvu qu'on reste objectifs.

admettons un site en DHTML avec une interface olfactive (j'omets l'ergo volontairement).
- Soit une marque qui veut parfumer son site
- Soit une "couche" de contenu
- on admet qu'on peut sémantiser cette couche avec des balises, genre "senteur de rose des champs"
- on l'affiche brut de décoffrage, l'utilisateur lis "senteur de rose des champs"
- OU on l'affiche dans une UA, que l'utilisateur, qui ne peut souffrir l'odeur de la rose des champs, a programmé pour sentir l'odeur du lilas à la place de la rose des champs à chaque fois que la balise "rose est affichée

De cette hypothèse, me vient 2 questions, simples, auxquelle j'aimerai avoir une réponse:

- La marque voulait parfumer son site à la rose. C'était son choix de départ, PAR HYPOTHÈSE. cette hypothèse n'a pas à être jugé, qu'on aime ou pas la rose, c'est ce que la marque voulait faire percevoir. C'est un CHOIX.
- L'odeur de rose, c'est ce qui fait que le site est intéressant. Les gens privés d'odorat n'en profiterons pas, c'est un fait.

Question 1:
- Partant de là, pourquoi la marque dépenserai un seul euro supplémentaire (et je parle même de 1 ou deux euros) pour sémantiser cette odeur, alors que ce qui est intéressant c'est de la sentir ?
Corollaire:
Les gens sans odorat pourraient "voir" l'odeur grâce aux balises, mais est-ce que ça en vaut la peine puisqu'il ne la sentiront jamais ? N'est-ce pas tomber dans la surqualité que de faire du dev en plus pour un public qui n'en est pas un ?

Question 2:
- Pourquoi la marque voudrait que son propos "rose" soit transformé en "lilas" ? Lilas, c'est pas du tout ce qu'elle veut dire !! Pourquoi, si ça n'est pas son but, donner la possibilité de le faire ?
Corrollaire: les utilisateurs qui veulent du lilas ne vont pas attendre sa permission pour "atomiser" son site. Mais pourquoi leur faciliter la tache et payer pour ça ? (c'est à dire dépenser de l'argent pour permettre aux gens de faire ce qu'on ne veut pas qu'il fassent), et deuxièmement, les gens qui affichent du lilas à la place de la rose, c'est très très bien pour eux, sauf que c'était pas le propos. Donc ok c'est très bien, mais à quoi bon ?

Question 3:
Quelle est le public qui à réellement envie de faire ça ?

Voilà mes trois questions.

Je vous devance sur votre réponse, qui serait par exemple:
"sémantiser l'odeur, ça servirait par exemple dans un mashup qui permettrait à un module dans ton appartement d'aller chercher les flux RSS de tous les sites distribuant le parfum "rose" et de les diffuser selon des heures que tu auras programmé à l'avance, ou même en diffusant les odeurs selon ton humeur affichée dans twitter et récupéré via le même module. On pourrait m^me dire que en programmant toi même ce module, tu pourrait subtilement mixer les parfums de tous les sites pour avoir PILE celui à ton gout.

Certes, ce sont des applications intéressantes qui seront développées si c'est demandé et nécessaire.

Mais il faut admettre des autres qu'ils aient le CHOIX. ça s'apelle de la tolérance. Si une marque ne VAUT PAS que ces applications soient possibles (que ce soit gratuit ou pas) elle ne le fera pas.

Les utilisateurs qui veulent vraiment le faire ne vont pas attendre son accord, mais pourquoi lui simplifier la tache ?

Et pour certaines marques qui proposent une expérience parfumée, disons chanel: pourquoi chanel voudrait que ne serait-ce QU'UNE SEULE personne sente UN JOUR son parfum de rose mélanger sauvagement à celui de violette de St Laurent ?

Ils ne vont pas empécher les gens de le faire, mais ne vont pas le faciliter: aucun intérêt. Sauf si un jour il y'a de la demande bien sûr, c'est à dire en accord avec la stratégie de la marque.

Bien sûr, ces cas sont des exceptions, et dans la grosse majorité des cas, sémantiser le contenu DOIT être fait, en PREMIER LIEU car c'est bénéfique pour tous, y compris la marque.

Mais des fois, non. c'est un CHOIX, vous vous devez de le respecter, ou du mioins, si vous ne le respectez pas, vous n'avez pas à dire à l'auteur ce qu'il doit faire ou pas.

Il faut juste être tolérant là dessus et comprendre (et accepter) que le web ne "devrait" pas être comme ci ou comme ça et que des fois, on ne nous demande pas notre avis.

Voilà pour les digression, si vous pouviez me donner votre avis sur les questions, on éviterai de repartir pour 12 pages

yosh a écrit :

- La marque voulait parfumer son site à la rose. C'était son choix de départ, PAR HYPOTHÈSE. cette hypothèse n'a pas à être jugé, qu'on aime ou pas la rose, c'est ce que la marque voulait faire percevoir. C'est un CHOIX.
- L'odeur de rose, c'est ce qui fait que le site est intéressant. Les gens privés d'odorat n'en profiterons pas, c'est un fait.

On ne peut pas répondre à tes questions, encore une fois, tu n'as pas compris ce que nous avons dit.

La question qu'on se posait plutôt à te lire dans le sujet précédent, c'est pourquoi tu veux empêcher les gens qui ne peuvent, ou ne veulent pas sentir la rose, d'accéder au site. A moins que l'odeur de rose ne soit la seule information du site, le reste a également un intérêt. Et si c'est la seule information, alors effectivement, c'est une information atomique que l'on ne peut pas diviser. Mais dans ce cas ce n'est plus un site, c'est une ressource.

Question 2 et 3 : un visiteur peut avoir envie de diffuser une odeur de lilas pendant qu'il visite ce site, par exemple parce qu'elle était déjà diffusée avant qu'il ne clique sur un lien qui mène au site. C'est une question de conditions de consultation qui échappe totalement à l'auteur, voire à l'utilisateur (qui par exemple consulte le site dans les toilettes parfumées au lilas d'un bâtiment public, le portable sur les genoux ).

Après effectivement on peut avoir envie de "sémantiser" l'odeur de rose et tout ça, mais sans aller jusque là, ce qu'on demande, c'est qu'on puisse voir le reste du site, même si on n'a pas accès à l'odeur de rose.
Modifié par Lanza (10 Oct 2008 - 12:22)

a écrit :
c'est pourquoi tu veux empêcher les gens qui ne peuvent, ou ne veulent pas sentir la rose, d'accéder au site.

Parce que délivrer un message altéré ne m'intéresse pas, ou même, je ne VEUX PAS diffuser un message altéré ? Délivrer une experience comme un tout ?

C'est un choix, ça existe, c'est pas une tare, et des fois même c'est pertinent

Les utilisateurs feront de toutes façons ce qu'ils veulent avec mon site, mais ça reste un droit de ne pas le cautionner.

yosh, stp : je crois que tout le monde t'a entendu et que le message était clair. On peut parler d'autre chose ?

(On pourra reparler de la confusion entre l'expérience de marque et l'expérience utilisateur, des raisons de sémantiser la rose aussi évidentes que la panne de cartouche de phéromone de rose chez le visiteur, mais plus tard, au calme, un autre jour, ailleurs, devant une bonne bière )
Modifié par Laurent Denis (10 Oct 2008 - 12:33)

Allez, hop. Vous sémantiseriez comment une interface, vous ?

Il s'agit bien-sûr de ce qui n'est pas exprimable actuellement de manière structurelle, sinon, ce n'est pas drôle.

Allez ! Hop ! Intervention de dominique, merci de bien vouloir modérer tes propos, yosh
Modifié par dominique (10 Oct 2008 - 14:25)

Ha voui, on en était là...

Laurent Denis a écrit :
Allez, hop. Vous sémantiseriez comment une interface, vous ?

Il s'agit bien-sûr de ce qui n'est pas exprimable actuellement de manière structurelle, sinon, ce n'est pas drôle.

Laurent Denis a écrit :
Bwa, c'est pas grave, je/l'outil vais/va rajouter la mienne/sienne. Mais... il n'existe pas de format de description de l'ergonomie associée à un contenu ou à un service. L'entreprise de conceptualisation ou d'abstraction qui serait nécessaire à une telle possibilité n'a, à ma connaissance, pas encore été entreprise, ou transformée en outil. On peut exploser un site ou un service en autant de couches que l'on veut, il y a un certain travail en amont qui s'appelle ergonomie et qui ne sera pas transcriptible aujourd'hui en tant que tel. Et qui est indissociable de la valeur de l'information dans l'expérience utilisateur qui est le but du jeu (ça, c'est peut-être propre au Web, tiens).

De plus en plus de nouveau services offrent aux utilisateurs des options de mise en forme de leur contenu, on choisi un format d'affichage de notre galerie sous Flirck, on affiche ensuite cette galerie dans notre blog, c'est bien un "format de description d'ergonomie".

Dans mon cas l'évolution de ma pratique de graphiste qui s'est mit au web:
1. je fait des belles maquettes Ilustrator et je me prend la tête a faire la même chose avec dreamvewer, flash ou avec des tableaux.
2. je fait des belles maquettes Ilustrator et je me prend la tête a faire la même chose avec des css
3. je fait toujours des belles maquettes Ilustrator mais je passe un peu plus vite qu'avant sur mon css histoire de pas faire plein de courbe qui vont me couter 2 jours de travail.
4. je fait des cms , les utilisateurs finissent toujours par exploser les designs, je finit par lâcher prise, et je les laisse choisir typo couleur et même la forme (template) et format de l'affichage (des images par exemple). Je laisse de la place dans les menus dans les bloc, bref je prend moins de place et j'en laisse plus aux utilisateurs. Je n'impose pas une mise en forme qui reflète ce que moi je crois avoir compris du sujet, non je laisse la mise en forme évoluer avec son contenu,
5. j'en ai marre de faire des header horizontal au format impossible je créer donc un format de mise en forme pour que les utilisateurs puisse mettre leur jolies images dans le header (quand il y a un header bien sûr). J'utilise un éditeur wysiwyg, bing les design explosent de nouveau les couleurs partent dans tout les sens, pas grave! qui suis je pour imposer ma vision et mes couleur sur ce qu'un autre veux dire?
6. Je rajoute des services web qui explosent tout mes design qui restent (malgré tout ce cheminement) quelque peu étriqués. Je ne sais même plus ce qui va être publié ni d'où ça va venir, ni ou ça va aller, comment je peux dans ce contexte tout prévoir en amont sans abstraire et conceptualiser l'ergonomie?

J'oublie plein de trucs, notamment comment la découverte des langages serveur ou clients on modifié ma conception d'un graphisme en fonction d'un algorithme. Ou bien comment un algorithme peux être une mise en forme graphisme (conception d'un nuage de tags par exemple).

Je ne sais pas ou cela mène et je sais très bien qu'il y a d'autre pratiques ou "on s'occupe de tout", mais ce qui est sûr c'est que le travail de conception graphique est radicalement différent que pour le papier et qu'il devient justement plus conceptuel, abstrait, voir architectural. Pour ma part je trouve cela beaucoup plus intéressant que le processus maquette -> design web au pixel .
Modifié par matmat (10 Oct 2008 - 15:25)

Au vue du sujet de départ je ne pensais pas que cela aurait suscité tant de remous !

La conception des applications est aussi chamboulé par les applicatifs RIA qui casse nos modèles de site en mode Page.

Tiens un nouveau concours alsa, ça fait deux dans le mois ça !

OK je suis déjà dehors

Laurent a écrit :
Allez, hop. Vous sémantiseriez comment une interface, vous ?

Moi à terme je ne sémantiserais plus d'interface. Suis assez d'acc avec Lanza pour dire qu'il manque un méta-outil universel chapeautant les contenus et qui en soit complètement indépendant, genre "canaux" distincts selon les types d'objets (objets interactifs, objets consultables-only, etc.).
Je nous verrais bien commencer basiquement par un truc du genre :
<html><head><tools><body>
où <tools> regrouperait un certain nombre d'objets type menus (option 1), ou, plus intéressant, un certain nombre de "feuilles de formats" -- agissant comme CSS agit sur la mise en forme -- et qui viendraient décrire/qualifier/conditionner les différentes interactivités de <body>. Du coup on aurait une "utilisabilité" un peu plus indépendante de la mise en forme/interface.

En attendant on peut essayer d'émuler ces canaux absents par une nomenclature rationnelle genre microformats, mais les initiatives en vue de normaliser ça sont encore peu développées semble-t'il.

Laurent Denis a écrit :
Allez, hop. Vous sémantiseriez comment une interface, vous ?

En utilisant les formats existant tel que les microformats, atom et peut être dans un futur proche SPARQL.

Ça se fait déjà beaucoup surtout pour les types de structure commune a quasi toute les applications, c'est a dire les données spéciales et temporaires. Google calendar ou google map sont des applications complètement sémantiques ce qui les rend compatible avec n'importe quelle interface.

Dans un registre plus libre, utiliser les tags "category" d'un flux rss permet par exemple de faciliter des outils comme NetVibes à catégoriser les flux et a améliorer la puissance des assistants qui offre du contenu selon les intérêt des personnes. Donc si une application produit un flux rss avec des "category" on peut considerer que c'est une forme de sémantisation de l'application.

SPARQL va beaucoup plus loin, mais si on regarde le format cela ressemble aux microformats en plus complet et avec une notion de requêtes qui manque à ceux ci. Mais bon ça c'est pas encore utilisé. Ceux ci dit, à mon avis ceux qui si interressent dès à présent garantissent une place et une utilité à leurs applications.

EDIT pardon j'avais pas lu la suite :

Laurent Denis a écrit :
Il s'agit bien-sûr de ce qui n'est pas exprimable actuellement de manière structurelle, sinon, ce n'est pas drôle.

Donc réponse : je m'intéresserais de très prés à SPARQL
Modifié par matmat (10 Oct 2008 - 19:12)

Et cette foutue balise link si elle n'était pas sous exploitée par les différents navigateurs est-ce que ce ne serait pas un début ?

a écrit :
Alternate
Designates substitute versions for the document in which the link occurs. When used together with the lang attribute, it implies a translated version of the document. When used together with the media attribute, it implies a version designed for a different medium (or media).
Stylesheet
Refers to an external style sheet. See the section on external style sheets for details. This is used together with the link type "Alternate" for user-selectable alternate style sheets.
Start
Refers to the first document in a collection of documents. This link type tells search engines which document is considered by the author to be the starting point of the collection.
Next
Refers to the next document in a linear sequence of documents. User agents may choose to preload the "next" document, to reduce the perceived load time.
Prev
Refers to the previous document in an ordered series of documents. Some user agents also support the synonym "Previous".
Contents
Refers to a document serving as a table of contents. Some user agents also support the synonym ToC (from "Table of Contents").
Index
Refers to a document providing an index for the current document.
Glossary
Refers to a document providing a glossary of terms that pertain to the current document.
Copyright
Refers to a copyright statement for the current document.
Chapter
Refers to a document serving as a chapter in a collection of documents.
Section
Refers to a document serving as a section in a collection of documents.
Subsection
Refers to a document serving as a subsection in a collection of documents.
Appendix
Refers to a document serving as an appendix in a collection of documents.
Help
Refers to a document offering help (more information, links to other sources information, etc.)
Bookmark
Refers to a bookmark. A bookmark is a link to a key entry point within an extended document. The title attribute may be used, for example, to label the bookmark. Note that several bookmarks may be defined in each document.

Au final on aurai un document du type

<html>
<head>
	<link rel="section" href="/Blabla-humour" title="Blabla" />
<link rel="section" href="/Xhtml-css" title="Standards et Accessibilité" />
<link rel="section" href="/Tutoriels-alsa" title="Tutoriels Alsa" />
<link rel="section" href="/Astuces" title="Astuces" />
<link rel="section" href="/Forum-alsa" title="Forum et communauté Alsa" />
<link rel="section" href="/Conception-web" title="Conception Web" />
<link rel="section" href="/Interviews" title="Interviews" />
<link rel="section" href="/Recapitulatifs" title="Récapitulatifs" />
<link rel="archive" href="/2008/10" title="octobre 2008" />
<link rel="archive" href="/2008/09" title="septembre 2008" />
<link rel="archive" href="/2008/08" title="août 2008" />
<link rel="archive" href="/2008/07" title="juillet 2008" />
<link rel="archive" href="/2008/06" title="juin 2008" />
<link rel="chapter" href="/2008/10/03/434-optimisez-vos-images-avec-smushit" title="Optimisez vos images avec smushit !" />
<link rel="chapter" href="/2008/10/02/433-concours-doctobre-cest-parti" title="Concours d'octobre : c'est parti !" />
<link rel="chapter" href="/2008/10/01/432-un-chat-organise-ce-vendredi-3-octobre" title="Un chat organisé ce vendredi 3 octobre" />
<link rel="chapter" href="/2008/09/30/431-fin-du-concours-mensuel-la-couleur-rose" title="Fin du concours mensuel "La Couleur Rose"" />
<link rel="chapter" href="/2008/09/25/430-2nd-concours-mensuel-phase-de-vote" title="2nd concours mensuel : phase de vote" />
<link rel="chapter" href="/2008/09/19/429-annuaire-de-sites-accessibles" title="L'annuaire de sites accessibles de HandiCapZéro" />
<link rel="alternate" type="application/rss+xml" title="RSS" href="/rss.php" />
<link rel="alternate" type="application/xml" title="Atom" href="/atom.php" />
<meta name="DC.title" content="Blog Alsacréations : XHTML, CSS et Standards web" />
<title>Blog Alsacréations : XHTML, CSS et Standards web</title>
<link rel="stylesheet" type="text/css" href="/themes/sib/style.css" media="screen" />
<link rel="stylesheet" type="text/css" href="/themes/sib/print.css" media="print" />
</head>
<body>
Pas de structure pas de mise en forme un document vide mais quand même du contenu accessible.
</body>
</html>

Donc en reprenant les exemples d'Arsène ajouter des possibilités :

Menu
Skip link
Interactifs
objets consultables-only

Edit:
Ha tiens je serai bien un peu à l'ouest avec mon histoire de link moi
Modifié par knarf (11 Oct 2008 - 03:50)

pourquoi ne pas mettre une balise autour de chaque mot ? Pour en traduire exactement ce que l'auteur à voulu dire, comme l'intonation, si c'est une second ou pas, si c'est sérieux, si c'est officiel, si c'est de l'info etc ?

Un peu comme le css speech actuellement.

Encore plus loin, ajouter des sentiments dans les balises, pour comprendre si un texte est colérique/informatif/ironique ou pas etc...

Ou encore inventer un code, même en front, qui permettrai d'être interprété par une machine ou un humain directement sans système de balises, et donc sans aucune connaissance nécessaire en code pour la rédaction des documents (pour rendre le système accessible à tous, et supprimer une lourde couche au passage).

Une espèce de nouveau langage du web, transparent pour tous, interpretable par les machines, qui ne laisse pas d'ambigüités dans l'interprétation et pourrait être traduit à la volé par n'importe quel périphérique, (visuel olfactif whatever) qui du coup pourrait produire quelque chose d'après ce langage. Ce genre de langage ouvrirait d'énorme possibilités, en plus d'être bien plus souple qu'un balisage systématique (car il faudra bien sortir du balisage un jour, ce n'est qu'une solution de repli pour le moment)

Le balisage reste une technique lourde, on peut simplifier tout ça en faisant passer des messages clairs directement coté front, tout le monde y gagnerait en souplesse,en tout cas pour certains documents, notamment informatifs.

En partant sur la base de mots clef, directement, que chaque UA interprèterait à sa sauce, pour une souplesse maximum.

On ferait l'économie d'une couche et on laisserait le choix à l'utilisateur (ou à une UA pré-programmée) d'interpréter le tout .

knarf a écrit :

Edit:
Ha tiens je serai bien un peu à l'ouest avec mon histoire de link moi

Nonon, surtout pas, t'en va pas

Arsene a écrit :

où <tools> regrouperait un certain nombre d'objets type menus (option 1), ou, plus intéressant, un certain nombre de "feuilles de formats" -- agissant comme CSS agit sur la mise en forme -- et qui viendraient décrire/qualifier/conditionner les différentes interactivités de <body>. Du coup on aurait une "utilisabilité" un peu plus indépendante de la mise en forme/interface.

Le mot "widget" peut-il aider ?

Laurent Denis a écrit :


Le mot "widget" peut-il aider ?

Comme le site de la BBC?