Les frames ne sont pas nuls

Cet article est la suite de Frames pour les nuls dont la lecture préalable est recommandée pour ceux qui ne sont pas familiers avec les frames. Les problèmes liés aux cadres sont exposés ici. Les solutions seront investiguées dans l'article Frames pour Phd en php. Il vaut mieux prendre connaissance des problèmes avant d'en aborder les solutions.

Si le principe des frames est simple, leur mise au point pour obtenir un système de navigation satisfaisant est un véritable casse-tête. Des centaines d'heures sont requises pour en ajuster le fonctionnement, ce à quoi cet article et le suivant peuvent remédier. Il faut, dès la conception, identifier les problèmes certains et leur apporter une solution adéquate.

Une grosse difficulté à laquelle se confronte le développeur est celle de la multiplication des fichiers sur disque. En effet, pour qu'une page s'affiche dans un cadre lorsqu'elle est appelée par l'internaute depuis un moteur de recherche, un autre site ou la liste de ses favoris, la page de définition des cadres doit y faire référence. L'exemple suivant sert d'illustration :

La page Texte2.htm est appelé et comporte l'instruction de chargement des cadres définis en DefCadre.htm :

<script language="javascript">
if(parent.frames.length == 0) parent.frame.location = "DefCadre.htm"
</script>

Mais si DefCadre.htm comporte l'instruction de chargement de Texte1.htm au lieu de Texte2 :

<SRC=http://Rep/Texte1.htm>

Ceci cause à Texte2.htm d'être remplacé par Texte1.htm lorsque le cadre se charge. Un fichier de définition spécifique DefCadre2.htm doit donc être créé pour Texte2.htm avec l'instruction :

<SRC=http://Rep/Texte2.htm>

Et le code de chargement du cadre-parent de texte2.htm doit faire appel à DefCadre2.htm :

if(parent.frames.length == 0) parent.frame.location = "DefCadre2.htm"

Il est nécessaire de créer autant de définitions de cadres que de jeux de fichiers à afficher simultanément. Dans les gros sites comme Nostradamia, cela peut représenter plusieurs centaines de fichiers supplémentaires. L'impact sur la clarté et la gestion des fichiers est désastreux, l'espace disque requis explose et la facture de l'hébergeur peut être affectée.

L'expérience tend à prouver que les développeurs se préoccupent peu de ne pas multiplier les fichiers sur disque. La conséquence de ce développement à la petite semaine est que lorsque l'administrateur souhaite plus tard modifier l'aspect ou le contenu de son site, les modifications doivent se répéter sur des centaines de fichiers ce qui peut représenter des jours de travail. Nul doute qu'il ne refera plus l'expérience des frames.

La solution existe bel et bien et doit être conçue dès le départ. Nostradamia n'utilise que 26 cadres pour ses 800 fichiers et pourtant ce sont bien les pages demandées qui s'affichent.

La 5^ème démonstration concerne les définitions de cadres dotés d'une extension php et placés sur un serveur distant. Texte5.htm s'affiche d'abord en Cadre3 et il est demandé à l'internaute de cliquer sur un lien qui provoque l'ouverture de Texte5b.htm. Lorsque l'écran est ensuite rafraîchi par la touche [F5] ou l'icône d'actualisation, Texte5.htm se substitue à Texte5b.htm. L'intention de l'internaute se limitait pourtant à rafraîchir la page en cours. Ce problème peut vite s'avèrer énervant pour l'internaute assidu qui, pour retrouver sa page, doit refaire le chemin précédent. Il peut avoir l'impression d'un site mal conçu et zapper.

Ceci s'explique par le fait que l'extension du fichier de définition du cadre de CadreDef5 est php. En fait, cela se produit à chaque fois que les sources de la page de définition des cadres sont modifiées ce qui est systématiquement le cas avec les pages dynamiques. Couplé avec la nécessité de limiter le nombre de fichiers sur disque, le problème peut paraître insolvable si l'on persiste à doter les fichiers d'une extension php. Mais il faudra bien s'y résoudre pour corriger les autres problèmes. Heureusement il y a une solution.

Lorsqu'il atteint enfin la page désirée, l'internaute se rend compte avec une dose d'énervement supplémentaire que le problème qui lui avait causé de rafraîchir sa page, comme une image non chargée, est toujours présent. La raison de ceci est simple. Texte5.htm est rafraîchi par DefCadre5.htm tandis que Texte5b.htm est rechargé depuis la mémoire cache RAM ou disque dans l'état exact où il se trouvait auparavant.

La tentation est forte pour le développeur de résoudre ce problème en introduisant une "balise méta d'instruction no-cache" dans l'entête de chaque fichier. Mais l'internaute en fait les frais lorsqu'il navigue dans l'historique car chaque fichier doit être rechargé en intégralité à chaque passage. C'est long, source potentielle de zapping, les ressources requises de communications et de CPU sont accrues et la facturation par l'hébergeur peut être affectée. Là aussi la solution existe et aucun recours à l'interdiction de la mémoire cache n'est nécessaire pour réafficher la page correctement.

Lorsqu'un internaute place une page dans ses favoris, c'est en fait la page de définition des cadres qui s'y colle. Ainsi, si son intention est de placer Texte5b.htm dans ses favoris tandis qu'il est affiché dans CadreDef5.htm, c'est malgré tout Texte5.htm qui est rappelé par le biais des favoris. Une solution satisfaisante existe.

Lorsque l'utilisateur navigue dans l'historique grâce à l'icône "retour", plusieurs clics sont requis pour atteindre la page précédente. Ceci est la conséquence du fait que plusieurs pages ont été mouvementées en même temps. Il arrive même que cela ne fonctionne pas du tout. La mise au point d'une solution pour ces problèmes est complexe du fait de l'imperfection de la gestion de l'historique des navigateurs. Mais elle existe.

Les problèmes sont récapitulés dans le tableau suivant.

Description du problème	Solution : oui /non
-Difficulté de conception et de mise en ouvre pouvant requérir des centaines d'heures pour :                -Coordonner l'affichage des pages                -Résoudre les problèmes de navigation                -Limiter le nombre de cadres au minimum.	Oui
-Comportements de navigations inattendus :                -Touche F5 rappelle le mauvais fichier                -Placement dans les favoris ne fonctionne pas                -Fichier appelé depuis l'extérieur ne s'affiche pas                -Navigation dans l'historique requiert de nombreux clics                -La touche avant de l'historique fonctionne une fois sur trois.	Oui
-Affichage des cadres inapproprié selon la résolution d'écran de l'internaute et la taille des polices par défaut du navigateur. Des informations peuvent ne pas être visibles à l'écran si le cadre est trop petit.	Oui
-Obligation de placer des entrées dans le fichier "robots.txt" et les balises Meta pour spécifier les fichiers à ne pas visiter par les moteurs d'indexation. Ils sont plus nombreux avec les cadres que dans les pages classiques.	Partielle
Comme si ces problèmes ne suffisaient pas, des commentateurs qui n'ont probablement jamais fait l'expérience des cadres en inventent de toute pièce.
Fausses idées sur les frames	Réalité sur les frames
-Les moteurs de recherche ne peuvent indexer les sites avec des cadres.	-Pour preuve, Nostradamia est tout en cadres. Il suffit de taper Nostradamia chez Google, Yahoo, Lycos, Aol, Dmoz, Voilà et une douzaine d'autres moteurs pour constater l'indexation extensive et régulièrement renouvelée des pages du site. -Mais il est vrai qu'il faut prendre le soin d'orienter les moteurs dans la bonne direction. -Et parce que les frames n'ont pas une bonne réputation, ils peuvent rebuter les bénévoles de chez dmoz.org. Il faut donc les convaincre de la qualité de la navigation et du contenu du site par un développement sans faille et des informations d'intérêt.
Les browsers ne lisent pas les frames.	Simple logique : 90% des internautes de France et du monde entier utilisent MSIE versions 4 à 6. 8 à 9% utilisent Netscape version 5 ou 6. 1% utilise Opera. Ceux qui restent utilisent des moindres standards tout aussi performants. Chacun, soit 99,99% de la couverture du web, lit les frames correctement. Le 10000ème internaute qui utilise sans doute une version antérieure à 1998 doit changer de browser, car on ne développe pas pour 1/10000. (Ceci se réfère aux frames et non aux iframes).
Les pages de cadres obligent au recours à Javascript qui ne peut être interprété par certains systèmes.	-Même réponse que précédemment : La quasi-totalité des browsers comprend le Javascript, pourvu qu'il soit activé. -Le javascript n'est pas l'exclusivité des pages de cadre. -Mais il est vrai que Google et d'autres moteurs ne suivent pas les liens écrits en Javascript. Il faut donc en tenir compte.
C'est au regard des avantages et désavantages qu'il convient de peser le pour et le contre des frames. La liste suivante n'est pas exhaustive.
Avantages des Frames
Afficher plusieurs fichiers sur une même page :                -Conception et évolution du site modularisées                -Informations disjointes visibles simultanément.
Aspect : -Homogénéité de présentation d'un bout à l'autre de la navigation avec un aspect d'application professionnelle. -On aime ou on aime pas. Mais si on aime, on remarque que l'aspect se démarque de la plupart des autres sites. -Présentations en livre, l'internaute repère rapidement les sujets qui l'intéressent :                -Menus en guise de chapitre                -Sous-menus en guise de sections et sous sections                -Liens visibles facilement atteints par un simple clic. -Lors du renouvellement des informations d'un cadre, les autres demeurent visibles. Ceci contribue à maintenir la concentration de l'internaute sur le site. Dans une page classique, la page tout entière disparaît pendant un temps.
Possibilité d'afficher des informations importantes toujours visibles dans un cadre dédié :                -Lien vers un forum                -Adresse du webmaster                -Moteur de recherche du site.
-Possibilité d'afficher des publicités incorporées non intrusives et toujours visibles qui peuvent être renouvelées selon un timing et une séquence définis par l'administrateur. -Les fenêtres pop-ups sont systématiquement fermées par les internautes qui se sentent abusés et peuvent même tout simplement en interdire l'affichage. La question ne se pose pas avec les frames, les pubs ayant une place dédiée qui n'interfère pas avec le contenu. -L'incorporation de la publicité directement dans des pages webs sans frame ne peut être gérée qu'au moment du chargement des fichiers qui est de ce fait ralenti. Avec les frames, cela peut se réaliser durant les temps morts. -A moins de ne multiplier les encarts, la pub n'est plus visible en bas d'une page classique. Avec des cadres, elle garde une place qui n'agresse pas l'internaute tout en restant visible à tout moment. -Renouveler les pubs est un jeu d'enfant avec les frames. Mais qu'il s'agisse de cadres ou de pages classiques ceux qui abusent avec des effets qui perturbent la concentration sont zappés.
Rapidité de chargement : -Ne sont mouvementées que les données nécessaires. Par exemple la suite d'un texte est affichée sans que ne bougent les menus. Dans une présentation classique, les menus sont obligatoirement rechargés avec la page de texte ainsi que les pubs et les pseudos-cadres. -Les options cache et no-cache peuvent être définies individuellement pour chaque cadre.
Indexation de qualité : -L'indexation par les moteurs de recherche se fait sur les informations d'intérêt : le texte. Dans une page classique, l'indexation commence par les informations répétées en haut de chaque page : menus, pubs, messages de l'administrateur .etc. Mais le contenu d'intérêt situé plus bas est ignoré. Dans les pages de cadres, la première donnée est celle du titre.
Robustesse : -Les cadres ne posent pas de problèmes d'affichage pour 99,99% des navigateurs.
Sécurité et confidentialité : -Les sources sont dissimulées. Il ne s'agit pas d'en interdire totalement l'accès mais de le différer. En effet, le plagia est la conséquence d'internautes peu expérimentés qui font du repiquage de sources. Celles des frames ne sont disponibles que pour les webmasters qui savent les trouver. Et ensuite, il faut un minimum de connaissances pour la mise en ouvre. Ceux qui ont les moyens de créer selon leur idée et non celle des autres en bénéficient. -Il est également possible d'interdire totalement l'accès aux sources grâce en partie aux frames, et ce quelque soit le navigateur (y.c. Opera). -Les moteurs de recherche d'adresses emails des spammers sont, à ce stade de leur développement, facilement déroutés par les cadres. On peut même leur faire des farces. -Les aspirateurs de sites et tous ceux qui ne respectent pas le protocole du fichier robots.txt peuvent être facilement interdits de navigation. Lorsqu'ils s'aventurent en zone interdite, les frames peuvent leur indiquer des chemins de liens sans fin qui les égarent et avec lesquels ils ressortent bredouilles après leur timeout ou l'arrêt brutal de l'opérateur. - Avec les frames et le php il est possible d'interdire la navigation des browsers qui n'affichent pas leurs IP ou qui la renouvellent à chaque page. Ces manières évoquent les voyous qui entrent chez les gens avec une cagoule sur la tête. -Interdire l'affichage d'une page dans un frame sur un site distant coule de source. Il suffit de tester le nom et le chemin du cadre parent puis de débouter le frame intrus, le surplomber ou lui imposer une autre page.
Simplicité : -Une fois résolus les problèmes de navigation, la publication des textes s'avère ultra-simple, rapide et légère. Les frames peuvent se transformer en véritables machines à publier.

 

Article suivant : Frames pour les PHD en PHP