<html>
<head>
<title>Phpcovid : Programmes coté navigateur</title>
<meta name=author content="Bernard Chardonneau">
<meta name=copyleft content="Logiciel et données publiés dans le domaine public">
<meta name=robots content="noindex,follow">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<link href="css/misenpage.css" rel="stylesheet" type="text/css">
<link href="css/styles.css" rel="stylesheet" type="text/css">
</head>
<body>
<div id="contenu">
<h1>Les programmes coté navigateur</h1>
<h2>Ils sont quelquefois nécessaires</h2>
A l'origine du web, le langage HTML a été conçu pour diffuser du texte et
des images. Déjà au siècle dernier, les navigateurs disponibles étaient
capables de le faire.<br>
<br>
On pouvait aussi dès le début télécharger des fichiers de toute nature.<br>
<br>
Mais certains ont réalisé des sites web demandant au navigateur de faire des
choses qui n'avaient pas été prévues au départ, comme de montrer des vidéos.<br>
Dans ce cas, c'est un programme distinct du navigateur web, lancé par lui,
qui se charge de faire le travail.<br>
<br>
Les vidéos constituent un cas particulier. Une nouvelle version du langages HTML
a permit de les intégrer dans les pages d'un site. Les navigateurs d'aujourd'hui
sont capables de montrer des vidéos de manière autonome. Dans le cas du format
mp4 qui était soumis à des brevets, Mozilla Firefox permet de le faire sous
GNU/Linux depuis 2014, mais ça a du l'être plus tôt avec d'autres systèmes
d'exploitation propriétaires et payants.<br>
<br>
Actuellement, lorsque du son ou une vidéo est enregistré dans un fichier, tous
les navigateurs peuvent en diffuser le contenu. Par contre, la transmission de
son et d'images en direct, qu'il s'agisse de télévision ou de vidéoconférences,
n'est pas supportée nativement par le langage html et donc par les navigateurs
web. Ils font donc appel à des programmes tiers.<br>
<br>
Mais cela n'explique pas que certains sites web exigent des versions de navigateur
de plus en plus récentes pour continuer à fonctionner. Par exemple, Youtube
a fonctionné dans le passé avec la version 12 (2012) de Firefox et peut être
auparant avec les versions 3 (2010). Mais alors que depuis sa version 27,
Firefox est capable nativement de montrer des vidéos, youtube refuse maintenant
de fonctionner avec cette version ou la version 31. Un numéro de version d'au
moins la 5ème dizaine est devenu nécessaire. De même, pour les diffusions vidéo
en direct, elle fonctionnaient très bien il y a quelques années avec Firefox 52,
mais il faut à présent une version d'au moins la 6ème dizaine (62) pour continuer
à voir ces vidéos.<br>
<br>
De nombreux sites web participent à la surenchère des numéros de version des
navigateurs en devenant incompatibles avec d'anciennes versions de navigateur
sur lequel ils fonctionnaient auparavant.<br>
<br>
Ce n'est pas le cas pour tous les sites web. Ainsi, le jeu massivement
multi-joueurs <a href="https://fr.wikipedia.org/wiki/Travian">Travian</a> qui
existe depuis 2005 utilise Javascript pour afficher divers compteurs (variation
dans le temps de la quantité des différentes ressources d'un village, temps
restant pour finir une construction, pour l'arrivée de marchands ou un déplacement
de troupes), ce qui fait que les données numériques de la page sont actualisées
en permanence alors qu'une nouvelle version de la page n'est envoyée par le
serveur web que lorsqu'un événement est survenu.<br>
<br>
C'est un cas où l'utilisation de petits programmes (en javascript) coté navigateur
est nécessaire. Et le système qu'ils ont développé il y a plus de 10 ans
fonctionne toujours, aussi bien avec des navigateurs devenus anciens, qu'avec des
versions récentes. A part la sécurisation des données de plus en plus ellaborée
par le protocole https qui fait qu'en 2021, de plus en plus de sites ont arrêté
de fonctionner avec Firefox 31, l'exemple de Travian montre qu'on pouvait déjà
créer des automatismes avec javascript il y a plus de 10 ans et permet de douter
de l'utilité d'évolutions qui ne fonctionnent qu'avec des navigateurs récents.<br>
<br>
<h2>En abuser peut nuire à l'ergonomie</h2>
Certains moteurs de recherche et certains wikis (notamment) font des propositions
à partir des premières lettres tapées d'une demande.<br>
Dans la mesure où ce sont juste des suggestions, qu'on peut cliquer sur l'une
d'elles pour gagner du temps, ou au contraire les ignorer, ce système qui suppose
que le serveur récupère en temps réel chaque caractère saisi au clavier ne pose
pas de problème.<br>
Mais tous les sites web n'utilisent pas ce genre de mécanisme à bon escient.<br>
<br>
<h3>Cas du serveur FOG</h3>
FOG (Free Open Ghost) est un logiciel libre qui permet d'enregistrer des
images de disques durs d'ordinateurs et de les cloner sur d'autres ordinateurs
avec lesquels le serveur FOG communique en réseau.<br>
<br>
Le pilotage du serveur FOG se fait avec un navigateur web.<br>
<br>
L'interface utilisateur du serveur FOG permet de gérer :<br>
<ul>
<li>les utilisateurs (ils disposent d'un compte pour accéder au serveur),</li>
<li>les hôtes (ce sont des ordinateurs),</li>
<li>les groupes (ce sont des groupes d'ordinateurs),</li>
<li>les images (ce sont des modèles de contenu du disque dur),</li>
<li>les tâches (opérations de capture ou de déploiement d'images),</li>
<li>la configuration du serveur.</li>
</ul>
La sélection des hôtes est probablement l'action sur le serveur qu'on effectue
la plus fréquemment. Pour celà, il y a une zone de saisie sans bouton de
validation associé :<br>
<br>
<img src="img-doc/fog.png"><br>
<br>
On va donc taper quelque-chose dans la zone de saisie. Déjà, on ne la trouve
pas vierge et la saisie de caractères n'efface pas forcément l'indication
précédemment affichée (comme si l'indication "Chercher" au dessus ne suffisait
pas !). Un effacement manuel de ce contenu inutile va faire perdre du temps.<br>
<br>
On tape alors le premier caractère du critère de recherche et le serveur FOG
affiche immédiatement la liste de tous les ordinateurs (hôtes) qu'il connait
avant de la corriger pour ne garder que certains.<br>
<br>
On tape un deuxième caractère et le même processus se produit.<br>
<br>
Quand on a fini la saisie, on s'aperçoit que certains ordinateurs sélectionnés
n'ont pas leur nom qui correspond à ce qu'on a tapé ! Peut être que la
chaine "af" recherchée figure ailleurs dans le description de ces ordinateurs,
mais dans ce cas, le minimum serait de demander à l'utilisateur à partir de quoi
on doit faire la recherche !<br>
<br>
Donc déjà 3 défauts :<br>
<ul>
<li>caractères parasites dans la zone de saisie qui ne s'effacent pas
tous seuls,</li>
<li>affichage du résultat finalement plus lent car perte de temps avec
des affichages pématurés, et javascript s'exécute plus lentement que
PHP,</li>
<li>des éléments sélectionnés qui ne correspondent pas au critère choisi
(si on veut autoriser une recherche sur autre-chose que le nom de
l'ordinateur, il vaut mieux prévoir des cases à cocher ou des boutons
radio pour que l'utilisateur spécifie ce qu'il veut faire).</li>
</ul>
Ensuite, une fois qu'on a la liste cherchée à l'écran, il peut être utile de
l'enregistrer dans un fichier. Sauf que si on le fait, au lieu de récupérer
une page HTML avec à l'intérieur l'information utile, on récupère une page
HTML avec le gros programme javascript qui a permit au navigateur d'afficher
cette information !<br>
<br>
Au lieu d'utiliser du javascript pour faire n'importe quoi, un formulaire
de saisie du critère de sélection avec un bouton de validation à cliquer
une fois la saisie terminée permettrait grâce à un programme PHP d'avoir
le résultat plus rapidement sans affichage intermédiaire parasite, et ce
résultat figurerait dans le code source de la page HTML produite.<br>
<br>
Il y a un cas où l'utilisation de javascript est nécessaire dans l'interface
web du serveur FOG. C'est pour la page qui affiche les taches en cours
d'exécution (capture d'image ou clonage) avec un suivi de leur progression.<br>
Mais pour toutes les autres pages de l'interface web de ce serveur, le
traitement des demandes entièrement en PHP donnerait de bien meilleurs
résultats à la fois en vitesse de traitement et en agrément d'utilisation.<br>
<br>
<h3>Cas d'un site de vente d'ampoules LED</h3>
Un site marchand propose à la vente des ampoules LED et des luminaires.
Pour les ampoules LED vissantes avec un culot E27, plus d'une centaine de
modèles sont proposés. Aussi, un menu permet de sélectionner les ampoules
qui obeissent à certains critères.<br>
<br>
Un premier critère proposé est le prix. Pour cela, on a un formulaire de
saisie avec le prix minimum, le prix maximum et un bouton de validation.<br>
<br>
<img src="img-doc/selprix.png"><br>
<br>
Pour ce critère, pas de problème. Grâce au bouton de validation, la page
affichée n'est actualisée que lorsqu'on a fini d'indiquer la gamme de
prix acceptée.<br>
<br>
Un deuxième critère proposé est la puissance de l'ampoule. Pour cela, on
dispose d'une longue liste de cases à cocher (la dernière puissance proposée
est 100 W), qui n'est pas munie d'un bouton de validation !<br>
<br>
<img src="img-doc/conso.png"><br>
<br>
Résultat, à chaque fois qu'on coche ou qu'on décoche une case, la page
du site met plusieurs secondes à se réafficher pendant lesquelles on ne
peut pas accéder à la liste des cases à cocher pour continuer d'indiquer
dans quelles gammes de puissance on fait la recherche.<br>
Coté utilisateur, ça fait une perte de temps, et coté serveur web, ça fait
du temps de traitement en plus pour la préparation de pages intermédiaires
qui ne serviront pas.<br>
<br>
Dans ce cas de ce site, il est possible que le traitement de la liste
des puissances choisies soit fait entièrement en PHP, mais le problème
d'ergonomie vient du fait que chaque action sur une case à cocher entraîne
le réaffichage de la page au lieu d'attendre que l'utilisateur clique sur
un bouton pour traiter d'un coup toute la sélection qu'il a effectuée.<br>
<br>
<h3>Cas d'un serveur du CNED</h3>
Le cas du serveur permettant d'autoriser des élèves à suivre un enseignement
à distance est similaire à celui de la sélection de puissance des ampoules
LED.<br>
<br>
En france, la pandémie COVID 19 a emmené le ministère de l'éducation
nationale à demander aux professeurs à faire de l'enseignement à distance.
Pour celà, la plateforme de vidéoconférences du Centre National d'Enseignement
à Distance a été utilisée.<br>
<br>
Elle dispose d'une salle d'attente pour autoriser les élèves entrants à
suivre la conférence. Elle est visiblement réalisée en javascript avec 2
listes :<br>
<ul>
<li>du coté gauche, la liste des élèves en attente,</li>
<li>du coté droit, la liste des élèves acceptés.</li>
</ul>
Le professeur doit cliquer un par un sur les élèves en attente pour les
accepter. A raison de 5 secondes par élève (dans un cas favorable !)
pour que le serveur prenne en compte une acceptation, il faut plusieurs
minutes pour accepter une classe complète.<br>
<br>
L'utilisation de formulaires PHP avec des cases à cocher, un bouton de
validation pour les sélections partielles, et un autre pour sélectionner
en bloc tous les entrants, aurait fait gagner un temps précieux tout en
limitant la charge du serveur qui aurait eu des requêtes à traiter moins
fréquemment.<br>
<br>
Certes, les serveurs du CNED ont été conçus pour les enseignements à
distance que le CNED dispense, c'est à dire beaucoup moins d'enseignements
que pour la moitié ou l'ensemble des classes d'un pays. Mais après le
confinement de 2020, travailler sur le fonctionnement de ce serveur pour
que la validation des élèves entrant ne prenne pas un temps monstrueux
aurait été utile. Et si en plus, il y avait eu la possibilité d'avoir
la liste des élèves acceptés par ordre alphabétique, plutôt que par ordre
d'arrivée (pour ça, il existe une fonction de tri en PHP), il aurait été
plus simple de noter les présents, et donc de trouver es absents.<br>
Il suffisait de se pencher sur le problème.<br>
<br>
</div>
<div id="menu">
XXXMENU
</div>
</body>
</html>