Les cadres : must ou ringardise ?
Faut-il en mettre pour être à la hauteur,
peut-on s'en passer, doit-on s'en passer, qu'en penser ?
Attention, c'est un sujet qui fâche !
Essayons toutefois de rester au-dessus de la mêlée et d'exposer calmement
les arguments des uns et des autres. Les cadres sont apparus avec la
version 2 du navigateur de Netscape et ils ont indéniablement rencontré un
vif succès populaire, qui a été consacré par son adoption par le méchant concurrent Microsoft,
puis par les grands gourous du consortium WWW. Cependant, l'usage a dévoilé
quelques difficultés de cohabitation entre ces cadres et certaines pratiques
que les internautes chevronnés trouvaient bien commodes, et ceux-ci ont
maintenant tendance à vouer aux gémonies ce qu'ils auraient adoré un ou
deux ans auparavant. L'internaute moyen et le créateur amateur de pages
perso n'ont pas suivi cette évolution et ils n'ont pas forcément la même
pratique de l'Internet. Le dialogue est donc difficile.
Nous allons aborder d'abord les « avantages », puis les
« inconvénients »
généralement attribués aux cadres, avec des guillemets parce que
cette classification est bien évidemment contestée selon qu'on est pour ou
contre les cadres...
AVANTAGES
Permanence d'un menu à l'écran
C'est l'utilisation essentielle. On la considère comme une aide
à la navigation, dans la mesure où on peut s'orienter dans le
site sans aller tout au début ou tout à la fin de la page en
cours ; en d'autres termes, on économise une manoeuvre d'ascenseur.
Petite économie, mais un grand confort peut naître de beaucoup
de petites attentions...
— Peuh! Economie minable ! Sait-on qu'on peut aller immédiatement tout en haut
ou tout en bas d'une page sans cadre, aussi longue soit-t-elle, juste en appuyant
sur les touches Début de page ou Fin de page ? Juste une
touche, et on a le menu !
— Attention, ces touches n'existent pas toujours, ou bien ne sont pas
toujours accessibles...
Mais il y a plus que l'économie d'un geste. Le visiteur
peut aussi rester sur le
milieu de la page pendant qu'il étudie le menu pour décider où aller.
C'est une autre petite chose appréciable et ça n'est possible
qu'avec des cadres.
Bien entendu, l'existence de ce menu n'est pas une panacée universelle. Le
problème de fond est que le visiteur sache toujours où il est dans le site, qu'il
puisse s'y déplacer commodément, qu'il puisse retrouver une page déjà vue et
et qu'il sache s'il a tout vu ou s'il reste encore des pages à découvrir.
Dans le cas d'un site complexe, il est évident que ce cadre de menu ne
pourra pas porter toute l'arborescence du site, mais il devra néammoins
apporter une réponse valable à ces soucis de navigation, ou y contribuer.
Il incombe à l'auteur de bien réfléchir à ces problèmes.
— Mais ce menu, faut-il encore que je l'ai ! Si je suis venu sur cette
page depuis un moteur de recherche, je ne l'ai pas, et je suis bloqué !
— Tût-tût ! Un peu de patience... Pour l'instant, on parle de l'emploi
normal de ces pages, tel que l'a voulu l'auteur. On reviendra plus loin
sur cette difficulté.
C'est la deuxième justification des cadres : on peut les utiliser pour
donner un habillage graphique fort au site. Il est clair que les tables
offrent peut-être encore plus de souplesse pour élaborer des graphismes,
mais ces tables glisseront et sortiront de l'écran quand on jouera de
l'ascenseur. On aura ainsi simplement construit une image plus ou moins
complexe en haut de la page, qui laissera la place au restant
de la page. Au contraire, un graphisme construit sur des cadres pourra
rester en place, conférant ainsi au site un habillage permanent et une
véritable identité graphique.
Etant donnée l'importance de la présentation dans les questions de
communication, il s'agit évidemment d'un argument très fort.
C'est un avantage annexe, mais non négligeable.
Le problème est
d'éviter qu'il y ait plus de 60/80 caractères par ligne, afin que la
lecture ne soit pas trop fatigante lorsque l'on a des textes
abondants à parcourir. Les
lignes que vous avez sous les yeux
en ce moment même, si vous êtes en 800x600, sont déjà un peu trop longues ! Il faut
donc limiter la largeur du texte. A nouveau, cela se fait aisément avec
une table, mais au prix de grandes marges vides à droite et à gauche
(en 800x600 ou plus). Un cadre de menu permet un remplissage naturel de
cet espace.
A nouveau on va confronter cadres et tables. Si on fait ses pages sans
cadres (donc avec des tables, à cause des nécessités de mise en page), on
va devoir répéter le menu sur toutes les pages concernées. il faudra
ensuite toutes les reprendre chaque fois que ce menu sera modifié,
ce qui sera inévitable lors de la mise
au point ou de l'évolution du site. Au contraire, avec des cadres, on
n'aura que la seule et unique page de menu à reprendre. Bien évidemment,
l'écriture initiale des framesets est une petite corvée supplémentaire, mais ce
n'est pas cher payé pour la suite.
— Argument de fainéant ! Avec un bon chercher-remplacer, les mises à
jour sur des tables ne sont pas un vrai problème !
— D'accord quand il s'agit de quelques mots, mais il faut
parfois remplacer plusieurs paragraphes. Et puis, pourquoi s'infliger un
effort, même petit, qu'on peut éviter ?
Allègement des fichiers
Comme on ne répète pas le menu à chaque page, les fichiers sont plus
légers. Ils occupent moins d'espace disque et ils sont plus rapides à charger.
Ces arguments ont néammoins perdu beaucoup de poids à cause de
l'amélioration constante des hébergements et des transferts
sur le réseau, amélioration certes jamais suffisante, mais indéniable.
— Rapidité ! Une page avec des cadres demande au moins 3 requêtes (le
frameset, le menu et le texte) au lieu d'une seule !
— Je doute que ce soit perceptible, et les pages suivantes
viendront plus vite, puisqu'on n'aura pas à charger et à
reconstituer le menu !
Passage de variables javascript
Les cadres simplifient
beaucoup la vie quand il s'agit de passer des variables javascript d'une
page à l'autre. Nous n'en dirons pas plus car c'est un peu
ésotérique,
mais c'est bien pratique... pour les initiés.
INCONVENIENTS
Attention aux barres de défilement !
Les cadres peuvent faire apparaître des ascenseurs en plein milieu de
l'écran si on les charge avec des pages trop importantes. L'effet
esthétique est franchement doûteux et en règle générale, il vaut mieux éviter
ça (vous en voyez un exemple avec cette page du Coin, mais dans ce cas
précis, nous avons décidé que l'esthétique était moins importante que la fonctionnalité).
Il est donc hautement conseillé de n'accepter les ascenseurs que sur
les côtés de la fenêtre. Mais même ainsi, on peut tiquer si l'ascenseur ne
couvre pas tout le côté, ce qui arrivera souvent dans la configuration
classique illustrée ci-contre : un menu à gauche, et à droite un titre en
bandeau, puis la page principale. A l'auteur d'apprécier si la gêne
esthétique est pardonnable — ou bien s'il doit légèrement
sous-dimensionner le cadre du bandeau pour faire apparaître l'ascenseur
complémentaire...
N.B. Notez que l'importance graphique de l'ascenseur a été
délibérément accentuée dans l'image ci-contre
pour mieux faire ressentir le problème. La réalité
est moins dramatique.
On entend encore souvent qu'il serait difficile de référencer
des pages avec des cadres, mais
il semble que ce problème appartient au passé. Il vaut
mieux dire que le référencement de ces pages impose des
contraintes supplémentaires à l'auteur. D'après un
comparatif déjà un peu ancien (1998!) cité par
Luc Van Lancker, parmi
les grands moteurs de recherche, seul
Altavista saurait lire les frames, mais les autres se rattrapent sur la
section <NOFRAME> que la sagesse impose de mettre. Aux auteurs
d'aller plus loin qu'un simple
"Navré, mais ce site contient des frames"
et d'y étayer les prétentions de leurs balises METAS.
Avec la plupart des navigateurs, on ne peut pas imprimer l'ensemble de
l'affichage, mais seulement le contenu du cadre sélectionné
(celui dans lequel on a cliqué). C'est embêtant, d'autant plus
que l'impression des cadres étroits (cadres de menu, en particulier)
peut s'écarter sensiblement de ce qu'on voit à l'écran,
dans la mesure où il semble que la mise en page soit
réinterprétée aux dimensions du papier...
Même chose si on essaie d'enregistrer : on ne peut enregistrer que le
cadre dans lequel on vient de cliquer.
— D'accord, mais pourquoi imprime-t-on ou enregistre-t-on, sinon pour
garder sous la main les informations réelles, celles qui sont contenues dans le
cadre principal ?
— Je veux bien, mais j'aimerais bien aussi avoir les références de
ce que j'imprime. Explorer m'imprime ça aussi (via le nom du fichier
imprimé, en bas de page), mais pas Netscape ! Et si j'enregistre, dans les
deux cas, il faut que je mettes moi-même un nom significatif pour le
fichier, sinon on me propose simplement le titre du frameset, quel
que soit le cadre !
— Quoi dire, sinon que les navigateurs n'ont manifestement pas été
conçus pour ça...
— Sans doute, mais ce qu'ils offrent est suffisant pour les pages
sans cadres, et pas pour les pages avec cadres.
Là, c'est plus génant. Si une page vous intéresse et que vous vouliez
la mettre dans vos favoris, vous inscrivez en fait l'URL du frameset, pas
celle de la page précise que vous avez remarquée.
— Ho ! Ce n'est pas aussi dramatique que ça. Vous devez aboutir à
l'introduction du chapitre correspondant dans le site
et vous allez vite retrouver votre chemin...
— Si le site est bien fait ! Mais si l'auteur a tout mis tout son
site dans un seul frameset, et c'est très souvent le cas,
c'est sur la page d'entrée du site que je me retrouve ! Merci bien!
Tenez ! Il y a bien des choses intéressantes dans l'accueil des pages
perso de Wanadoo et pas toujours évidentes à retrouver. Allez-y, trouvez
une bonne page, mettez en favori, et essayez d'y revenir !
Le visiteur peut évidemment immédiatement éditer son signet pour y inscrire
l'URL précise qui l'intéresse, mais il devra faire ça lettre par lettre
au clavier puisque cette URL n'apparaîtra que dans une barre d'état sur laquelle
il n'y a pas de copié-collé possible. Qui parlait tout à l'heure de confort et
de petites corvées ?
En fait la situation s'est un peu améliorée avec les toutes dernières
versions NN4.7 et IE5 sur Windows, où le menu contextuel
(clic droit de la souris à l'intérieur du cadre) permet précisément de
conserver l'URL de la page. Les possesseurs de Mac n'en sont pas
encore là en mars 2000, mais ils ont tout de même droit
à une
autre astuce: on peut réouvrir le cadre intéressant dans une nouvelle
fenêtre (clic droit sous PC-Windows, clic prolongé sous Mac, et on a le
"menu contextuel") et ce cadre se rouvre sous sa propre URL, qu'on peut
alors mettre en favori.
S'il y est sensible, l'auteur du site peut minimiser ce désagrément en
découpant son site en chapitres bien serrés avec peu de pages à chaque fois et en
redéfinissant ses framesets à l'entrée de chaque chapitre.
Là, c'est un peu le contraire. Si un moteur de recherche indique l'URL
d'une page qui est normalement dans un frameset, on va charger cette page
en plein écran, sans le menu qui devrait lui être associé, et on a de
fortes chances de pas pouvoir naviguer dans le site à partir de cette page.
— Allons, ce n'est pas si dramatique que cela ! Je vais vous donner
un truc qui demande un minimum d'effort.
On va d'abord se mettre dans cette situation, celle d'un moteur
qui a noté le remarquable bout de prose que vous êtes en train
de lire, à l'URL
http://perso.wanadoo.fr/coin.des.experts/reponses/faq6_9.html Vous cliquez dessus (allez-y !). Vous vous retrouvez avec cette même
page, mais en plein écran, avec l'URL inscrite dans la case des adresses.
Enlevez le nom du fichier « faq6_9.html » de l'URL.
Juste un coup de souris et une
touche, pas trop difficile, non ? Bon, faites ENTER maintenant.
Si le site est bien fait (et notre Coin est bien fait,
n'est-ce-pas ?), vous allez retrouver le frameset qui vous manquait pour naviguer.
Bien sûr, si vous voulez retrouver cette même page dans son frameset, il
va falloir chercher un peu. Mais notre index est bien fait lui aussi, et
vous la retrouverez facilement dans les rubriques cadres ou conception de site. — Et si le site est mal fait, je me retrouve avec une liste de
quatre cents fichiers, ou une erreur 404, ou plus bêtement à l'accueil du site ?
— Ça peut arriver, malheureusement. Mais l'auteur qui utilise des
framesets et qui est conscient du problème fera sans doute un effort dans ce
sens. Dans cet exemple précis, nous avons simplement placé une page de
redirection vers ce frameset en index.html dans le répertoire
reponses/.
A noter que l'auteur qui lance un javascript dans son
<BODY> pour
recharger automatiquement l'ensemble du frameset lors du chargement
ne fait qu'empirer les choses, puisqu'il empêche de voir la page
indexée par le moteur de recherches, précisément celle
qui contenait l'information recherchée par le visiteur.
Les cadres seraient incompatibles avec de nombreux navigateurs non
graphiques, tous absolument marginaux mais plus nombreux qu'on ne le
penserait. Les adversaires des cadres citent généralement le plus connu
d'entre eux, Lynx, l'ancêtre toujours vert (il bénéficie encore
de mises à jour) et vaillant.
— Mais qui peut bien se servir de ça, sinon une poignée
d'informaticiens purs et durs (traduction soft de "illuminés", :-))) sans
prise sur la réalité sociologique d'Internet ? Et à quoi ça peut
bien servir ?
— A quoi ça sert ? Par exemple, quand on fait une recherche
difficile et qu'il faut scruter un grand nombre de sites, ça permet de ne
pas perdre de temps à attendre que les images se chargent.
— Mais on peut très bien prendre son NN ou IE favori pour ça !
Il suffit de demander de ne pas charger les images dans les préférences,
non ?
— Non, parce qu'un NN ou IE ainsi bridé ne sait pas lire les
liens dans les images map, tandis que Lynx y arrive.
— Etonnant ! Lynx serait un outil pour naviguer en turbo,
qui saurait ouvrir les liens dans les images-map, mais qui ne saurait pas
ouvrir les frames qu'on trouve dans plus de la moitié des sites ?
Ça ne paraît pas très cohérent !
En fait, c'est faux.
Lynx sait très bien ouvrir les cadres...
et si nombre d'autres navigateurs peu connus n'y arrivent pas, ne serait-ce pas
plutôt qu'ils n'y arrivent pas encore, parce qu'ils sont
développés par de toutes petites équipes, qui n'ont pas
encore eu le temps de se confronter au problème ?
CONCLUSION
Il en est finalement des cadres comme bien des outils. Ils peuvent
rendre de grands services si on les emploie à bon escient. Leurs vrais
inconvénients tournent autour du fait que l'affichage d'une page dans un
cadre ne correspond pas à un document unique avec une URL précise.
La lecture du site n'en est absolument pas gênée — et
c'est bien là l'objectif essentiel d'un site web —, mais tout
ce qui tourne autour de l'indexation des pages à l'intérieur du
site est perturbé. L'auteur du site peut très bien prendre ces
difficultés de très haut en statuant que le seul point
d'entrée qu'il accepte est sa page d'accueil, mais il peut aussi les
alléger à travers une organisation soigneuse de ses
pages.
Charles (pour) – (TOM) (contre)
– Gérald (assez pour)
Il est donc hautement conseillé de n'accepter les ascenseurs que sur
les côtés de la fenêtre. Mais même ainsi, on peut tiquer si l'ascenseur ne
couvre pas tout le côté, ce qui arrivera souvent dans la configuration
classique illustrée ci-contre : un menu à gauche, et à droite un titre en
bandeau, puis la page principale. A l'auteur d'apprécier si la gêne
esthétique est pardonnable — ou bien s'il doit légèrement
sous-dimensionner le cadre du bandeau pour faire apparaître l'ascenseur
complémentaire...