________________________________________________________________  ____   __   __ 
 /   ___________________________________________________________  ____   __   _  / `
 \  /   \[O4]/ +   ,\_____                                                   ___/ .  `
 |\/   , \__/  .        \____ /:/=[ Un affaire d'ergonomie web    ] =\:\ _____/  `  x
 || ,    .         "   :X  \_______________________________   ____ ____   /    ,  `  `
 ||         +  ,   () .         x  , .           `   '   ` \_ \  ,\\_ +\_ \ 'M  ` |  .
 ||   ` |  `       ,      `   ,         +  ,  ` ,--,   +   . \\_  \_ \ , \\_  K  -+-   
/ |+   -+-    .        ,       `      ,       ,',/ ,'.       \_ \ . \\_  \_ \  -  |   `
 /    . |  ;     +         +  .   `   | :  .  :`` ,_):   '   ` \\_  \_ \   \\_` 1   ,  
 / ` .      .        x          ,  .-=+=-     `. ,. ,'  ` ,    \_ \ + \\_` \_ \  1
 /\_____  x    ' ,      . . X         |   `     `--'  `      `   \\_  \_ \ , \\_  1 +
\\_     \___________________ ,  .  .  ` ,  +  '   ,    , ; x   ._\  \___\\___\  \ .   
\_ \                        \__________________________________/                 \  ` ,
  \\_ /:/=[ Aka:                                                         ]=\:\    \    
  \__\__________________________________________   ______________________________  \`  
                                                \__\                            /__/   
                                                  \\_ /:/=[      h3      ]=\:\ _//     
                                                  \__\________________________/__/ 



	Bon.. j'croyais avoir inventé un nouveau  terme..  mais  malheureusement  google  m'a 
ramené à la réalité en 0.18 seconde. (plus 20 secondes pour afficher 
la page en 56k :|)

Results 1 - 10 of about 194 for "software ergonomy". (0.18 seconds)

	Encore une fois, mon idée est morte dans l'oeuf.. Mais bon, j'me console en me disant 
qu'elle n'était pas si bête s'il y a des cours sur l'ergonomie au niveau software.

	Je vois déjà les e-mails de programmeurs chevronnés me disant;"C'est rien de nouveau, 
c'était le 2ieme chapitre de  mon  livre  de  premiere  session  quand  j'étudiais  en  génie 
logiciel..  Bon.. Peut-être. Mais je n'ai pas étudié en  programmation,  à vrai dire, je n'ai 
même pas étudié en informatique.

	Et c'est vrai, le sujet a surement été mieux traité dans les livres. Je  croyais  que 
mon  idée  ne  valait  plus  la  peine d'écrire un article, mais en repensant à la façon dont 
l'idée m'est venue, j'ai réalisé qu'il en valait peut-être l'effort.

	La première  question  qui  m'est  venue  à  l'esprit,  c'est pourquoi après 3 ans de 
programmation php (plus comme passe-temps  que  comme  travail). Je  n'avais  jamais  entendu 
parler d'ergonomie software.. Pourtant, je lis régulièrement sur des sujets assez avancés... 

	En gros, je trouvais que 
l'interaction entre les utilisateurs et les sites webs est souvent  "mal  foutue".  Ca  l'est 
pour les sites web, mais c'est encore plus flagrant losrqu'on utilise des "applications web". 
Avec  le temps, j'ai remarqué qu'une application  a  beau  donner  le  résultat  attendu,  si 
l'interaction entre l'utilisateur et le  programme  est  trop  complexe ou trop "mal foutue", 
l'utilisateur en question  cessera de tout simplement de l'utiliser..

	Évidemment, la question est: "Pourquoi l'interaction  sur  le  web  est  si pénible?" 
Surtout dans le contexte d'application web  dynamique. La réponse est assez simple, mais elle 
met en contexte plusieurs facteurs. Les plus importants sont les suivants:

	- Le protocol HTTP
	- Le manque cruel de standards stables, éprouvés et surtout 
	  <strong>respectés</strong> au niveau des languages interpretés 
	  (de moins en moins vrai avec l'arrivée du xhtml strict)
	
	La liste pourrait surement être plus longue, mais la plupart des problèmes inhérent à 
l'ergonomie software sur le web découlent surtout du protocol HTTP.  Pour  la simple et bonne 
raison   qu'il  n'a  pas  été  conçu,  pour  gérer   un  flot  d'informations  dynamiques  et  
bidirectionnels.  Même  le  nom le dit, Hyper  Text Transfert Protocol.. L'idée de base était 
de prendre un fichier texte, de le  mettre  sur  un  serveur,  puis  le  serveur  en question 
retourne le contenu du fichier texte  sous  forme  "plain  text".   Seul   un   language   de 
programmation à balises était supporter, le html, dérivé du SGML (Standard Generalized Markup 
Language) lui même ayant été développé pour structurer des données. 

	En tenant compte du but original qui était de formatter et de rendre plus lisible les 
donnés du web. Jusque là le but était plus ou moins  atteint. La où les problèmes commencent. 
Avec le temps et l'avancement des technologies, les objectifs ont déviés, malheureusement pas 
toujours dans le bon  sens. Beaucoup d'autres languages ont été ajoutés à la longue liste des 
languages supportés par le web d'aujourd'hui (voir la tableau 2).  Bref,  le  protocole  HTTP 
transfert maintenant plus de lignes de code que de Texte. 

	L'autre  inconvéniant  du  protocol  HTTP  est  sa  structure  qui  est basée sur des 
requêtes/réponses (qui comprennent les méthodes GET/POST), mais qui exige que le  buffer soit 
"flushé"  puis  retransféré  complètement  pour  afficher  le  nouveau  contenu.  Sa    brise 
radicalement la fluidité dans l'utilisation d'un programme web. Les  languages  "client-side" 
comme le javascript ont bien sur été implantés pour palier  à  ce manque. C'est bon pour  les 
opérations calculables du coté client, mais si une  requête  doit être faite au server et que 
de l'information doit être reçue et  traitée avant d'être renvoyée au client, vous risquez de 
frapper un mur si  vous  ne  voulez pas d'un "refresh". À moins d'utiliser des méthodes assez 
complexes,  comme  une  2ieme  connection entre le server et le client, mais persistante, qui 
gère l'interaction entre le "programme web" et sont interface remote.. On  appele ca du RPC*. 
Ce n'est pas, à mon avis, la solution idéale, car elle comporte beaucoup de faiblesses et est 
relativement complexe à utiliser, car  elle  fait appel à un programme client et un programme 
serveur  qui  communique  ensemble  via  un  autre  port TCP. Alors beaucoup de calculs et de 
processing pour rien, en plus d'avoir à utiliser un port TCP autre que le 80,  donc  qui peut 
être bloqué par un firewall. Malgré cette  perspective  plutôt  sombre,  une  solution  vient 
peut-être éclairer nos pauvres âmes de patenteux.. Le " XMLHttpRequest"..  En gros, il   fait 
exactement ce que le RPC tente de faire, mais en étant un standards accepté, il sera surement 
beaucoup plus accessible  et stable que le "pseudo RPC". Pour plus d'informations à propos du 
XMLHttpRequest, visitez le  site suivant: 

http://www.xml.com/pub/a/2005/02/09/xml-http-request.html

	Le non respect délibéré ou non des standards par les  compagnies  qui  produisent les 
fureteurs nous complique aussi incroyablement  la  tâche.  Souvent  des  dizaines,  voir  des 
centaines de lignes de codes doivent être ajoutées au  site pour que le site sorte exactement 
pareil   dans  tous  les  fureteurs. Sans  compter  que  certaines  compagnies  malveillantes 
(<B>MICROSOFT< STRONG/>) ajoutent  leurs propres standards propriétaires dans leur fureteurs. 
Ou ils refusent  catégoriquement  de se plier à un standard pourtant accepté de tous pour des
raisons inconnues, mais surement futiles. Peut-être que c'est juste pour  nous  compliquer la 
vie.. Si c'est le cas, ils ont réussi :|  Un  exemple  frappant  est  l'élément  CSS  "fixed" 
qu'Internet Explorer ne supporte pas..  Pourtant  QUOI  DE PLUS UTILE que de pouvoir dire: je 
veux que cet élément la  reste  a cette position la, MEME si le user scroll .. Biensur il y a 
des  "workaround" ou des  "tricks" pour contourner le problème,  mais  souvent  ces  solution 
apportent autant de problèmes qu'il n'en règles, en plus de prendre 100x plus de bytes que le 
mot F I X E D. Cases studies:

Méthode #1
http://tagsoup.com/-dev/null-/css/fixed/

L'effet  est  la..  tout  fonctionne  comme dans firefox et seulement avec des  tricks  CSS.. 
Félicitation champion. Mais le "hic", c'est qu'avec cette  méthode  vous  perdez l'élément de 
position "absolute" .. PRATIQUE .

Méthode #2
http://www.howtocreate.co.uk/fixedPosition.html

L'effet  est  surprenant  et je n'ai pas trouvé d'inconvéniants majeurs si ce  n'est  que  la 
grosseur du code pour arriver à un résultat qu'un mot de 6 lettres  arrive  à  faire  dans un 
browser  comme  Mozilla  Firefox  et  qu'il  fait  appel  à des fonctions obscures d'internet 
explorer dont j'ignorais totalement l'existance..

<!--[if gte IE 5.5]>
<style type="text/css">
div#fixme {
	/* IE5.5+/Win - this is more specific than the NS4 version */
	left: expression( ( 20 + ( ignoreMe2 = document.documentElement.scrollLeft ? document.documentElement.scrollLeft : document.body.scrollLeft ) ) + 'px' );
	top: expression( ( 10 + ( ignoreMe = document.documentElement.scrollTop ? document.documentElement.scrollTop : document.body.scrollTop ) ) + 'px' );
}
</style>
<![endif]-->


	... Avouez que ce n'est pas catholique :p J'avoue que <!--[if gte IE N]>  j'ai trouvé 
ca  bien  comme  "trigger",  ca  permet  de  trier  les  browser  cons des intelligents. Mais 
"expression" .. wtf ? Je vous passe les exemples avec  javascript  qui  font  refresh continu 
pour "tracker" les scroll de l'utilisateur  et repositionner l'élément .. C'est vraiment laid 
et il n'y a que Microsoft pour nous pousser à coder des atrocités du genre.

	Mais voilà qu'avec l'arrivée d'un web dit "sémantique", on voit peut-être la  lumière 
au bout du tunnel. Le XHTML strict jumelé au css, xsl, xsd, xml devrait  nous aider à séparer 
les données de la présentation graphique et forcer les compagnies de fureteur à se plier plus 
aux standards. Une fois cette étape  franchie,  développer  des applications web devrait déjà 
être plus facile. Et si  le  XMLHttpRequest tient ses promesses,  le  web  devrait  voir  une 
véritable explosion de réel "applications web" performantes  offrant  des  possibilités  dont 
nous ne fesions que rêver (*tousse* http://maps.google.com *tousse*). 

	De grands pas on été faits  pour  rendre  le  web  plus  dynamique,  mais l'ergonomie 
software ne fait pas partie du  dictionnaire  de  tous  les  programmeurs web. Un bon exemple 
d'une bonne ergonomie software et un autre un  peu  plus moyen, c'est de comparer google mail 
(gmail) à hotmail avec une  connection  dialup (56k). Gmail est vraiment conçu dans le but de 
minimiser au  maximum  le  nombre  et  le  temps  de refresh ainsi que la quantité de données 
envoyées  au  client,  ce  qui  rend  son utilisation beaucoup plus fluide et "real time" que 
hotmail. C'est très important, car l'utilisateur se lasse très rapidement devant un site trop 
long à télécharger.

	Souvent l'ergonomie se concrétise  dans  de  petits  détails,  comme  la  possibilité 
d'effectuer des tâches groupées pour gagner  du  temps et l'ajout de "shortcut keys" pour les 
utilisateurs avancés. Bref, n'importe quoi qui  n'encombre  pas visuellement l'application et 
qui rend l'interaction entre l'utilisateur et le programme plus fluide et facile.

	Utilisez  les  bon  "input  controls"  aux  bons endroits. Les input control sont les 
méchanismes d'acquisition de données comme les checkbox, radio, select,  textarea  etc.   Ils 
sont très utiles pour recevoir de l'information de la part d'un utilisateur, mais ils doivent 
être choisis avec soin selon le contexte et le  type  de  données acquises. Par exemple, pour 
choisir parmis une énumération de noms plus ou moins longue comme une liste de ville ou pays, 
le "select" est  indiqué.  Pour  un  choix de réponse restreint, utilisez plutôt les "radio". 
Plusieurs assais on été faits pour ajouter d'autres "input controls" plus avancés  comme  des 
tabulateurs ou des "slidebars" pour enrichire l'interaction  avec  l'utilisateur.  Le  chemin 
pour y arriver est souvent laborieux et les résultats  plutôt  décevants.  D'un  autre  coté, 
certains sont arrivés à des résultats plutôt impressionants, comme Mihai Bazon avec sa vision 
d'un textarea:  http://www.interactivetools.com/staff/ben/htmlarea3_demo/example.html

	Il  faut  aussi  éviter  de  mettre  trop  de  texte  pour  rien, si des informations
supplémentaires <em>pertinantes</em> sont disponibles, linkez les  plutôt  que  de  créer  un 
manuel d'instruction interactif en guise de programme. Soyez le  plus  bref  et  conçis   que 
possible, en tout temps, car le average net user  déteste  lire.  Tout  ce  qu'il  veut c'est 
atteindre son but le plus rapidement  possible  avec  le  moins  d'étapes  possible. Pourquoi 
croyez-vous que sur un des  applications  web les plus visité du monde; google, on y retrouve 
zéro annonces publicitaires, 42 mots et 1 image ?

	C'est aussi vrai pour les menus, évitez les noms trop longs. Évitez  les  noms  comme 
"Lire les nouvelles" ou "Discuter sur le Forum".  Utilisez  plutot  des  mots  simples  comme 
"Nouvelles" et "Forum", l'utilisateur comprendra quand même et  votre  design ne s'en portera 
que mieux. Si vous avez beaucoup d'items dans votre menu, n'hésitez pas de créer des "arbres" 
pour regrouper vos items de façon logique.

	Si  quelque  chose  n'est  pas  utile  à  votre  contenu ou "message", enlevez-le. Le 
meilleur exemple que je puisse penser, c'est la surutilisation sections membres  sur  le web. 
Pratiquement chaque site web à sa propre secion membre. Demandez-vous  si  c'est   réellement 
indispensable. Considérez toujours que les  utilisateurs  du  web restent rarement fidèles au 
même site très longtemps. À moins d'offrir  un  service,  comme  un  webmail ou ebay, ou être 
réellement axé sur le  coté  "communauté web"  avec  un  but  précis  comme doyoulookgood, ca 
ne  vaut  pas réellement la peine d'avoir une section membre. Par exemple, certains sites web 
forcent les utilisateurs à s'enregistrer pour downloader leurs  produits,   combien  de  fois 
croyez vous que ces utilisateurs reviennent sur le site pour .. lire le forum ? .. Participer 
au sondage ? .. Une fois qu'il a télécharger ce  qu'il  voulait.   Je  parirais plus qu'il va 
oublié sont password dans la même  ½  heure. Choisissez les éléments qui composent votre site 
avec discernement. 

	Vous devez aussi prendre en considération votre public cible. Par  exemple,  si  vous 
faites un programme pour administrer une base de  donnée  mysql,  vous  pouvez  prendre  pour 
acquis que l'utilisateur qui utilisera votre programme à  une  base  relativement  solide  en 
informatique. Mais si vous codez un client  ftp  ou  http, vous devez prendre en compte qu'un 
plus grand "range" de niveaux  d'utilisateurs  risquent  d'utiliser  votre  application.   En 
général, si vous  programmez  pour  des  utilisateurs avancés, votre interface sera complexe, 
mais votre programme simple. Tandis que pour des utilisateurs lamba,  l'interface sera simple 
et le programme sera complexe. Sa semble illogique,  mais  un  programme  qui s'adresse à des 
débutants devrait faire le maximum avec  un  minimum  d'interaction  avec  l'utilisateur.  Le 
programme doit donc déduire  beaucoup  plus  de variables. L'utilisateur avancé, quant à lui, 
n'abandonnera pas  devant  un plus grand nombre de champs de saisie de donnée. Par contre, il 
le  fera si les "input controls" ne sont pas utilisés efficacement. Le mieux  est  évidemment 
d'avoir le meilleur des deux mondes, une interface simple, mais qui cache des options avancés 
facilement accessibles.

	Le comble de l'ergonomie software étant surement de plugger  directement  le  cerveau 
humain en interaction avec le programme, nous allons nous concentrer de ce que l'average uber 
geek peut arriver à faire sans ouvrir un crâne.  J'ai  trouvé  sur  le  net  un  petit   test 
heuristique  qui  permet  de  déjouer  les  erreurs  courantes  commisent  dans  les   design 
d'interfaces  de  programmes.  Il  a  été écrit et pensé dans le contexte de la programmation 
standard et non "web",  mais avec un peu d'imagination c'est applicable sur le web aussi.

 Tableau 1
 ¯¯¯¯¯¯¯¯¯
+---------------------------------------------------------------------------+
| Évaluation heuristique d'un interface	*****				    |
+---------------------------------------------------------------------------+
| 1. État du système							    |
| ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯							    |
|     L'utilisateur devrait être informé de ce qui ce passe en arrière plan |
| de façon appropriée et ce dans des délais résonnables.		    |
|									    |
+---------------------------------------------------------------------------+
| 2. Lien entre le système et le monde réel				    |
| ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯				    |
|     Le système devrait communiquer avec un language facile à comprendre   |
| par l'utilisateur dans un ordre logique et naturel plutôt que dans	    |
| la forme "orienté système".						    |
|									    |
+---------------------------------------------------------------------------+
| 3. Liberté de mouvement						    |
| ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯						    |
|     L'utilisateur devrait être en mesure de quitter n'importe quelle 	    |
| "étape" du programme ,dans laquel il aurait pus arriver par mégarde, 	    |
| rapidement et facilement.	(Souvent réalisé avec undo\redo)	    |
|									    |
+---------------------------------------------------------------------------+
| 4. Consistance et standards						    |
| ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯						    |
|     L'utilisateur ne devrait pas avoir à se questionner sur la 	    | 
| signification des termes, situations ou actions. Suivez les conventions   |
| de la plateforme.							    |
|									    |
+---------------------------------------------------------------------------+
| 5. Prévenir les erreurs						    |
| ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯						    |
|     Encore mieux qu'un bon message d'erreur: prévenez cette erreur.	    |
|									    |
+---------------------------------------------------------------------------+
| 6. Accessibilité							    |
| ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯							    |
|     Rendez les objets, actions et options visibles. L'utilisateur ne 	    |
| devrait pas avoir à se souvenir des informations d'un "dialogue" à 	    |
| l'autre. Et les instructions d'utilisation devraient être accessible      |
|  facilement	                                                            |
| en tout temps.							    |
|									    |
+---------------------------------------------------------------------------+
| 7. Flexibilité et efficacité						    |
| ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯						    |
|     Les racourcis (cachés aux utilisateurs lamba) peuvent grandement 	    |
| accelérer l'interaction des utilisateurs plus experts. De cette façon,    |
| l'interface convient au deux types d'utilisateurs. Rendez possible 	    |
| l'optimisation des tâches répétitives.				    |
|                                                                           |
| * A mon avis Adobe Photoshop est une référence sur ce point.		    |
|									    |
+---------------------------------------------------------------------------+
| 8. Design esthétique et minimal					    |
| ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯                                             |
|     Les dialogues ne devraient pas contenir d'informations futiles et     |
| inutiles. Chaque unité d'information ajouté inutilement entre en          |
|concurence avec les information crutial et le rendrent moin		    |
| visible.								    |
|									    |
+---------------------------------------------------------------------------+
| 9. Aidez à la reconnaissance, le déboguage et la résolution d'erreurs     |
| ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯	    |
|     Les messages d'erreur devraient être exprimés en texte simple, sans   |
| codes. Ils devraient indiquer avec précision la source de l'erreur et     |
| donner une ou des suggestions constructives sur la façon de régler le	    |
| problème.								    |
|									    |
| * <sarcasme>Microsoft est passé maitre dans cet art :)</sarcasme>	    |
|									    |
+---------------------------------------------------------------------------+
| 10. Aide et documentation						    |
| ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯						    |
|     Même si dans le meilleur des monde une application ne devrait pas     |
| nécéssiter d'aide, il est souvent nécessaire de fournir une documentation.|
| Elle devrait être facile à trouver, orientée principalement sur les tâches|
| de l'utilisateur. Lister les étapes concrètes à faire et être le plus     |
| concis possible.							    |
+---------------------------------------------------------------------------+


Tricks
------


	Lorsque  l'utilisateur  doit  "browser"  beaucoup  de  lignes,  utiliser  un  systeme 
d'highlight "onMouseOver" like pour mettre en évidence  la  ligne  qu'il  survole,  vous  lui 
épargnerez  peu-être  un  mal  de  tête. La couleur du  highlight  devrait  être  subtile  et 
harmonieuse  avec  le  background  et  le   foreground  plutôt  qu'aggressive  et  éclatante. 
Généralement deux ou trois tons  plus  foncés  ou  clairs  que  le  background  donne de bons 
résultats.

	Garder les subtilités pour les élément du background, le foreground doit être évident 
et  contrasté,  le contenu doit être le plus lisible possible. Les écrans  et  les  yeux  des 
personnes rendent très différemment les nuances et les subtilités d'un sujet à l'autre.

	La validation de forms avec le JavaScript est très bien pour gagner  du  temps,  mais 
il ne faut pas pour autant négliger la validation coté serveur. Car la validation coté client 
est facile à bypasser et ne constitue pas  une  sécurité  en  soi.  On pourrait appeler ca un 
"refresh saver".

	Assurez vous que les liens ressortent bien du texte qui l'entour, et tentez  le  plus 
possible d'utiliser toujours la même couleur pour vos liens. Ca peut  sembler  poussé   comme 
raisonnement, mais le bleu est une couleur à favoriser  pour  les  liens.  Par  defaut,   les 
fureteurs  utilisent  le  bleu  comme  couleur  pour  les  liens.. Les  utilisateurs  y  sont 
généralement habitués. 

	Si le public cible de votre site comporte des personnes agées, pensez à  ajouter  des 
options  d'accessibilité,  grandeur  de  police  variable  (avec  css  et  javascript   c'est 
relativement facile), thèmes contrastés ou version imprimable pour les personnes  ayant   des 
prolèmes visuels. Ce sont des petits plus souvent oubliés.
	
	Utilisez plus d'un béta testeur, 4 ou 5 c'est parfait, selon l'ampleur du projet. 

	Spécifiez aussi les background blanc. De  plus  en  plus  d'utilisateurs  "mod"  leur 
windows et le background d'application n'est pas toujours nécéssairement   blanc, ce qui peux 
jouer énormément sur le rendu de vôtre design.

	À moins que le défilement de votre contenu soit horizontal, évitez que votre  contenu 
dépasse les 800px de largeur. C'est toujours surprenant (ou décourageant)  de  voir le nombre 
de taupes qui utilisent encore cette résolution ..

	Le shockwave flash même s'il ne fait pas partie des recommandations du  W3C vaut bien 
une mention spéciale. Il est considérablement répendu et il faut  avouer ses avantages. Flash 
offre beaucoup d'avantages qui seraient techniquement  très difficiles, voir même impossibles 
à réaliser avec du simple html ou même dhtml. Toutefois,  même  si  vous ou votre client êtes 
très enthousiasmés par le flash,  résistez  à la tentation de faire votre site entièrement en 
flash. Cette  technologie a beau être en constant essort, le nombre de types de "clients" qui 
peuvent  lire  le  format  flash  reste  plutot  limité. Il est certain que la nature du site 
importe  dans  cette  décision.. Si les cellulaires, palm, .. frigidaire ? fureteur textes ou 
les os  qui  ne sont pas supportés par flash ne sont pas visé .. so what ? .. Mais attention, 
même  s'il  est  peu  probable  que  vous  ayez  boucoup  de  visiteurs utilisant lynx, si un 
navigateur texte ne peut visiter votre site, un robot de moteur de recherche ne le pourra pas 
plus. Pensez-y bien :)


 Tableau 2 *fort probablement incomplet ..
 ¯¯¯¯¯¯¯¯¯
+---------------------------------------------------------------------------+
| Languages client side						            |
+---------------------------------------------------------------------------+
|	html		|	HyperText Markup language		    |
|	dhtml		|	Dynamic HyperText Markup language	    |
|	xhtml		|	eXstensible HyperText Markup language	    |
|	vml		|	Vector Markup language			    |
|	css		|	Cascading Style Sheet		    	    |
|	vbs		|	VisualBasic Script		   	    |
|	js		|	JavaScript				    |
| 	js		|	JScript					    |
|	class ?		|	Java (compilé)				    |
|	ocx		|	ActiveX					    |
|	xml		|	eXstensible Markup Language		    |
|	xsl		|	eXstensible Stylesheet Language		    |
|	xslt		|	eXstensible Stylesheet Language Transform   |
|	xsd		|	XML Shema Defenition			    |
|	dtd		|	Document Type Defenition		    |
|	swf		|	ShockWave Flash	(compilé)		    |
|-- autres standards dérivés (généralement non supportés) ------------------|
|	sgml		|	Standard Generalised Markup Language	    |
|	thml		|	Theological Markup Language		    |
|	xrml		|	Digital Rights Language for Trusted         |
|			|	Content & Services	                    |
|	gml		|	Geography Markup Language		    |
|	qml		|	Quantum Markup Language :> **		    |
|	sbml		|	Systems Biology Markup Language		    |
|	uiml		|	User Interface Markup Language		    |
|	cml		|	Chemical Markup Language		    |
|	cml		|	Chemical Markup Language		    |
|	xaml		|	"Longhorn" Markup Language ***	    	    |
|	wml		|	Wireless Markup Language	            |
|	cnxml		|	Connexions Markup Language		    |
|	mathml		|	Mathematic Markup Language		    |
|	idml		|	International Development Markup Language   |
|	rdf		|	The Resource Description Framework	    |
|	smil		|	The Synchronized Multimedia Integration     |
|                       |       Language		                    |
|	svg		|	Scalable Vector Graphics		    |
+---------------------------------------------------------------------------+
| Languages server side							    |
+---------------------------------------------------------------------------+
|	cgi			|					    |
|	pl			|	perl				    |
|	php			|	Hypertext PreProcessor		    |
|	rb			|	ruby				    |
|	py			|	python				    |
|	asp			|	Active Server Page		    |
|	aspx			|	Active Server Page	x ?	    |
|	tcl			|					    |
|	jsp			|	Java Server Page		    |
|	cfm			|	Cold Fusion 			    |
+---------------------------------------------------------------------------+


*		RPC (Realtime Procedure Call). Pour plus d'infos: 
		http://www.bazon.net/mishoo/rpc.epl
**		http://www.qc.fraunhofer.de/doc/qml/QMLspecification.html <- ish.
***		Nouveau language markup supposément "révolutionaire" de microsoft .. messemble :p
****	Heuristique: Méthode de recherche empirique ayant recours aux essais et 
		erreurs pour la résolution de problèmes. C'est une méthode fréquemment 
		utilisée en intelligence artificielle, à l'intérieur de ce qui est 
		techniquement appelé univers incertains. (source: www.dictionnaire.com)
*****	Tiré d'un texte de Jakob Nielsen at:
		http://www.useit.com/papers/heuristic/heuristic_list.html


Note:	Entre temps où j'ai commencer à écrire cet article et celui où je l'ai finalisé,
		j'ai finalement eu une connection haute vitesse :) thx a lot TheCops ;>