L’informatisation et la mise en réseau des ordinateurs nous ont apporté beaucoup de choses formidables ces trente dernières années. Toute la culture musicale, cinématographique et encyclopédique est désormais à une portée de clic de quiconque. Téléphoner de n’importe où à n’importe qui tout autour de la terre est devenu quelque chose de tellement courant que plus personne ne s’en extasie. Et même si l’interlocuteurice s’exprime dans une autre langue ça n’est presque plus un problème avec les différents services de traduction en ligne que l’on peut avoir.
Ne parlons même pas de ce mini-ordinateur que presque tout le monde a désormais dans sa poche, équipé d’une chaîne hifi complète, d’un caméscope, d’un appareil photo d’excellente qualité et d’une connexion permanente au réseau mondial.
Nos logements sont désormais entièrement automatisables et pilotables à distance.
Je peux avoir de la musique ou la radio quand je veux dans mon casque sans fil grâce à la baladodiffusion.
Tous ces rêves numériques des années 90 se sont concrètement réalisés aujourd’hui, mais nous avons tout de même perdu quelque chose : le temps réel des interfaces
N. D. M. : par « temps réel » est ici utilisé dans le sens réponse immédiate humainement parlant, sans latence perceptible, réactives (voir les définitions Wiktionary ou Wikipedia pour temps réel qui, pour l’informatique, vont amener des exigences supplémentaires sur la durée maximale de réponse, la garantie du temps de réponse, etc.
Sommaire
- Le temps réel des interfaces
- Les systèmes sont devenus mous
- Revenons aux interfaces réactives
- Manifeste des interfaces temps réel
- Vers un Score-Interfaces-Temps-Réel ?
- Conclusion
Le temps réel des interfaces
En effet, avec la diffusion du numérique à tous les étages, les interfaces se sont ramollies. Aujourd’hui, lorsque nous appuyons sur un bouton pour jouer une musique, lancer une vidéo ou valider un formulaire sur Internet nous n’avons pas un retour immédiat de cet appui.
Il s’écoule souvent un temps non négligeable entre l’appui sur ledit bouton et la réaction du système. Ce problème ne se limite pas aux boutons bien sûr, c’est le même problème avec les branchements des chargeurs et autres interfaces USB, HDMI…
Nous ne sommes jamais immédiatement sûrs que l’action se soit bien passée. Si la réaction met trop de temps à venir (lancement de la musique, icône de mise en charge, validation du formulaire…) nous allons avoir tendance à réessayer au risque de se retrouver avec un « dys »fonctionnement anormal. Le bouton « play » de la musique est également le bouton pause, un ré-appui sur le bouton coupe la musique. Une absence de réaction de l’appareil au branchement va nous amener à débrancher puis rebrancher jusqu’à jeter le câble et en prendre un autre. Un ré-appui sur le bouton du formulaire va en renvoyer un autre, etc.
Nous parlons bien ici des interfaces qui ne sont pas en temps réel. Cela n’a rien à voir avec la puissance de calcul des machines. Les appareils des années 90 avaient beau avoir des interfaces temps réel, ils n’étaient pas puissants, beaucoup ne disposaient même pas de microprocesseurs.
Sur mon lecteur de cassettes audio, lorsque j’appuyais sur le bouton « play » le bouton émettait un « clic » bien distinctif et une petite vibration dans le doigt qui m’assurait que mon appui était bien pris en compte. Et si j’étais à la fin de la cassette le bouton remontait immédiatement, je savais instantanément que cela n’avait pas marché et qu’il fallait que j’appuie sur « eject » pour retourner la cassette… ou « rewind » pour rembobiner.
Pour lire ma cassette de petit ours brun, j’appuie sur le triangle et ça fait «clic» instantanément !
Alors que pour allumer la boite à histoires, il faut appuyer sur un bouton planqué sur le côté, et attendre plusieurs secondes que l’écran affiche un sourire. Ai-je bien appuyé ? Dois-je retenter ? Y a-t-il suffisamment de batterie pour que j’obtienne une réaction ? Et je ne parle même pas des deux boutons rotatifs rouge qui ne réagissent pas instantanément (en plus celui de gauche est à tourner pour le volume et celui de droite est à CLIQUER pour changer d’histoire…)
Les télévisions cathodiques des années 70-80 prenaient un certain temps à chauffer avant d’afficher l’image, mais l’appui sur le bouton « on » était marqué par un « clang » bien net, et nous savions que la télé était allumée, nous pouvions attendre d’avoir l’image. Les télés d’aujourd’hui mettent également du temps à s’allumer, mais elles ne signalent pas toujours la bonne réception de notre action sur la télécommande. Et ne parlons même pas des écrans d’ordinateur avec leur interface tactile à la noix (on doit pouvoir parler d'interfaces digitales pour le coup non ?) dont on ne voit même pas où se trouve le bouton.
Les systèmes sont devenus mous
Et cette mollesse les rend dysfonctionnels. Je ne compte plus le nombre de fois ou voulant ré-appuyer sur un bouton de validation, j’ai finalement appuyé sur un nouveau bouton venant d’apparaître sous mon doigt/curseur. Sans parler de tous ces systèmes électroniques portables qui prennent un temps dingue avant d’afficher quelque chose quand on appuie sur le bouton “ON”. Systèmes qui ne sont pas toujours réellement éteints d’ailleurs et dont l’appui long… les éteint !
Ne parlons même pas des systèmes avec boutons rotatifs de type « potards numériques » qui — non contents de générer des rebonds ou de sauter des pas — fonctionnent avec la même mollesse que les boutons « standard ».
Mais le problème ne se limite pas aux systèmes embarqués. Oh que non ! Toute l’informatique « desktop » et mobile est touchée. Les sites Web ont rouillé avec leurs méga-octets de bibliothèques javascript à télécharger avant de pouvoir appuyer sur le moindre bouton.
Le réseau étant désormais massivement sans fil (WiFi, GSM, 4g, 5g, gégé, …), l’on ne sait pas toujours pourquoi cette page met tant de temps à se charger. Attention, il n’est pas question ici de vitesse de connexion, mais plutôt d’absence d’indication claire de ce qui est en train de se passer : ai-je déconnecté, ou le lien réseau est-il tout simplement lent ?
Revenons aux interfaces réactives
C’est un problème d’ergonomie. Et l’ergonomie est visiblement toujours reléguée en fin de projet «tant qu’on a un truc qui marche». Cependant, on pourrait considérer que non, ça ne marche pas si l’interface est si lente à réagir.
Je suis persuadé que ce problème n’est pas une fatalité. Il est possible de revenir à des interfaces humain-machine qui soient vraiment temps réel.
Mais il faut que tout le monde s’y mette.
- Aux électroniciennes et électroniciens de mettre systématiquement le voyant (ou vibreur, ou son) qui va bien pour signaler le bon branchement du câble, et le bon appui sur le bouton.
- Aux développeuses et développeurs noyau de soigner l’ordonnanceur pour s’assurer que la partie interface soit bien traitée dans un temps acceptable (moins de 100 ms ?).
- Aux développeuses et développeurs d’applis de considérer un temps de réaction trop long des interfaces comme un bug qu’il faut corriger.
- Aux utilisatrices et utilisateurs de ne plus accepter un seul ralentissement de l’interface et remonter systématiquement le problème comme un bug et/ou ne pas acheter/utiliser le produit.
Manifeste des interfaces temps réel
Voici donc une proposition/un manifeste de règles pour des interfaces temps réel :
- Toute action humaine (appui ou clic-toucher sur un bouton, branchement d’un câble…) doit être validée par un retour en moins de 100 ms par un visuel, un son ou une vibration.
- Si le système est bloqué l’utilisateurice doit le savoir. On doit pouvoir faire la différence entre un blocage et un temps de chargement. Un genre de watchdog de l’ergonomie.
- On peut certainement ajouter d’autres règles quand on fera des audits ITR (Interfaces Temps Réels) dans les bureaux d’études et de développement des grosses boites.
Vers un Score-Interfaces-Temps-Réel ?
Évidement, il est impossible que ces règles s’appliquent du jour au lendemain sur tous les appareils et logiciel du marché. On pourrait inventer un système de notation, à l’image du nutri-score mais pour les interfaces. Par exemple le SITR pour Score-Interfaces-Temps-Réel et développer une appli pour pouvoir récupérer le score des produits qu’on utilise.
Appli qui aurait le culot d’avoir un mauvais score histoire de faire causer.
Conclusion
Pour conclure sur ce manifeste décousu :
✊🏼 Oui l’ergonomie est importante !
✊🏽 Oui un temps de réaction trop long est un BUG !
✊🏿 Oui il faut que ça change !
Aller plus loin
- L'article Wikipédia sur l'ergonomie (37 clics)
# Oui
Posté par Julien Jorge (site web personnel) . Évalué à 10.
Fut un temps où j'étais en bout de ligne ADSL, loin du DSLAM. Dans le meilleur des cas le débit descendant montait à 300 ko et le montant à 80 ko. Ça me permettait de voir le web au ralenti :
Je rigolais doucement en voyant les Gradle et Docker lancer quatre téléchargements en parallèle.
Dans des conditions comme celles-ci les interfaces temps-réels sont un peu utopique. Quand bien même le bouton réagit en moins de 100 ms. il va juste représenter un état temporaire sans intérêt genre grisé ou… un spinner. Au final on se demande quand même si la demande a bien été prise en compte.
Sans doute que ça pourrait être mieux fait mais encore faut-il que les devs, avec leurs machines surpuissantes et leur connexion idéale, puissent remarquer le problème.
Militons pour équiper les devs avec des CPUs du début du siècle et des connexions en 56K. Vous verrez que nous nous mettrons à économiser les ressources et que les machines des clients finaux auront l'air plus réactives :)
[^] # Re: Oui
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
En début d'année, j'avais encore une connexion ADSL (~3 Mbps) et tu fais bien la différence entre LinuxFr.org et un site gavé de pubs, traqueurs et autres sources d'embonpoint.
Les dev web vont parfois tester avec plusieurs navigateurs et plusieurs tailles d'écran, mais je n'ai pas vu souvent des gens mentionner des tests en limitant le CPU ou le réseau… Pas mieux pour les dev backends je dirais… l'exception est sans doute l'embarqué (et la frange particulièrement atypique des gens qui travaillent sur Voyager I, ou autre sujet approchant). Il y a bien des outils qui évaluent ça, mais ils ne font pas partie des chaînes CI/CD classiques et on ne va pas considérer qu'il y a régression parce qu'une appli a gagné 50 MiB de surcharge pondérale (oui toutes les applis mobiles je pense à toi) ou parce que la page est blanche le temps qu'un truc très lourd soit arrivé jusqu'au navigateur en raison d'une connexion par pigeons voyageurs.
[^] # Re: Oui
Posté par Faya . Évalué à 8.
C'était le débat d'hier entre HTMX/David Heinemeier Hansson (créateur du framework qui fait tourner LinuxFR il me semble) d'un côté et les devs frontend de l'autre. Les devs JS qui expliquent qu'en ralentissant la connexion (l'option de limitation de la bande passante disponible dans l'outil de développement des navigateurs), les Hypermedia Driven Application (HDA, avec un backend qui renvoie directement du HTML plutôt que du JSON à traiter par client REST) affichent de gros lags avec des divs vides. Tandis que les framework JS en front permettent d'informer l'internaute qu'on attend les données (genre spinner). Bref sur de grosses applications je pense qu'ils testent aussi en conditions de ressources limitées mais les divers sites bourrés de pubs c'est sûr que non. À priori si tu es enclin à bourrer ton site de pub c'est que tu t'en fous de l'expérience utilisateur…
[^] # Re: Oui
Posté par potate . Évalué à 3.
Pareil avec du rendu côté client : si tu n'as pas les données, tu ne peux pas les afficher. Tu pourras peut-être commencer à afficher une coquille vide le temps que les données soient récupérées, mais pour faire ça il faut avoir récupéré les templates avant.
Pour les spinners et indicateurs génériques, il n'est pas interdit d'en avoir sur une appli en mode HDA. Par exemple le concurrent à HTMX qu'est Unpoly1 propose d'afficher une barre de chargement en haut de page si la réponse à une requête met trop de temps à arriver.
Je n'ai utilisé aucun des deux. La complexité des frameworks front me chagrine, et je lorgne sur les alternatives aux Single Page Apps. ↩
[^] # Re: Oui
Posté par Faya . Évalué à 4.
Je ne doute pas qu'il y a des solutions pour les HDA et moi aussi j'évite les frameworks front. C'était surtout pour dire qu'il y a quand même des gens qui testent leurs applis en conditions dégradés et qui débattent des meilleures solutions. Merci pour Unpoly, je ne connaissais pas.
[^] # Re: Oui
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Mettons les d'accord: les deux approches sont mauvaises !
Faire des sites classiques avec peu de js comme linuxfr, c'est la meilleure approche (théorique validée par la pratique).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Oui
Posté par Mildred (site web personnel) . Évalué à 4.
Sauf que pas forcément. Avec les framework côté client, l'application s'alourdit et même sur une connexion pourrie ça devient ingérable. Exemple : le bon coin qui lorsqu'il est passé d'un frontend HTML tout simple à un truc bourré de javascript, c'est devenu tellement lent que je n'y allais presque plus. Et je ne compte pas les personnes qui pestent que ça ne marche plus, que lorsqu'on appuie sur le bouton de recherche, pile au moment ou on appuie, l'interface a finalement fini de charger et on appuie à côté pour être redirigé n'importe où et il faut revenir en arrière, attendre que çá ait fini de charger, faire la recherche, attendre sinon on fera la même erreur, et appuyer sur le bouton. Et avec une connexion un peu moins bonne ça charge d'autant plus lentement. Ça m'est arrivé d'attendre 10/20s devant l'interface entre chaque action, et c'est très pénible!
[^] # Re: Oui
Posté par zerodeux (site web personnel) . Évalué à 8.
Attention, la bande passante et la latence ne sont pas la même chose… J'ai eu une ADSL des familles à 512kbps mais j'avais "30ms de ping". Ca permet de créer des interactions temps réel dont parle l'auteur de l'article (comme jouer à Quake & co).
Pour moi il est indubitable que le "web est mou", quand les dévs sont très satisfaits d'avoir 20 à 50ms de calcul pour pondre une page HTML alors qu'avec la puissance des processeurs actuels on devrait limite rougir de mettre plus de 1 ms. Je ne parle même pas de la tuerie JS qui rend n'importe quelle ordiphone d'il y a 3 ans assimilable à un vieux bousin asthmatique.
Au fait notre perception de l'instantanéité est plutôt de 20 ms pour le visuel et 5 ms pour le sonore. Je pense que 100ms ça manque d'ambition. On est quand même partie de 0ms pour pas mal d'applis analogiques (le potar, le changement de chaîne instantané - soupir -, etc), je vois pas pourquoi on devrait se satisfaire de 100ms et appeler ça un progrès…
Si vous voulez un bon benchmark, cliquez sur https://lichess.org/ - voilà ce qu'on peut obtenir en s'appliquant (ils ont gagné sur les 2 tableaux : latence pour le 1er afficahge et temps de chargement pour la page complète). Et c'est une page riche en infos.
PS: je désactive le "speculative loading" sur mon brouteur, j'ai mes raisons, je pense que je vois tout plus "mou" que vous.
[^] # Re: Oui
Posté par martoni (site web personnel, Mastodon) . Évalué à 5.
J'avais mis 20ms à la base. C'est le temps utilisé pour faire du filtrage de rebond dans l'embarqué en général.
J'ai plus qu'une balle
[^] # Re: Oui
Posté par Nibel . Évalué à 3.
Pour essayer d'avoir une expérience +/- similaire (selon vote localisation physique) et pour ceux qui ont un intelliphone capable d'aller sur l'Internet, forcez la réception 3G/3G+ et essayez de naviguer.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Oui
Posté par martoni (site web personnel, Mastodon) . Évalué à 4.
Attention je parle bien des Interfaces, qui doivent être temps réel.
Donc si je fait une requête pour afficher une page web je dois être certain qu'elle a été prise en compte et que la communication est en cours.
On peut tout à fait faire des interfaces temps réel avec du très vieux matos.
Mon 386 sous dos 6.22 met du temps à s'allumer, mais je sais que je l'ai allumé quand j'appuie sur le bouton «power»: non seulement le bouton fait du bruit et me fait vibrer le doigt mais en plus l'engin fait un tel barouf à l'allumage que je sais que c'est parti !
J'ai plus qu'une balle
[^] # Re: Oui
Posté par Faya . Évalué à 5.
On peut t'afficher un spinner ou autre pour illustrer que la requête a bien été prise en compte mais sur le web il arrive que le résultat n'arrive jamais. Et là tu regardes un loading gif tourner pendant plusieurs secondes avant de te demander est-ce qu'elle est vraiment partie. Pour les communications réseaux il y a toujours moyen de se faire avoir parce qu'une requête partie n'implique pas que la réponse arrivera forcément…
[^] # Re: Oui
Posté par zerodeux (site web personnel) . Évalué à 2.
Ah mais je suis à fond d'accord. C'est pour ça que j'en veux un max aux concepteurs/réalisateurs qui ont à leur dispo des monstres multi-GHz multi-cores GPU-tralala.
# Alors là oui !
Posté par Rozé Étienne . Évalué à 7.
Merci d'avoir fait le journal qui dénonce grave et que je rêvais de faire…
exemple de ma box : quand on l'allume avec la télécommande le voyant rouge s'éteint (ou plutôt non je crois que la couleur est beaucoup moins lumineuse…). Non seulement c'est aberrant : quand on allume un truc, le voyant lumineux devrait s'allumer… ou à la rigueur être plus lumineux, mais en plus il y a ce décalage de réaction qui fait que l'on se demande si on a bien appuyé sur la télécommande et donc on ré-appuis et donc on éteint…
[^] # Re: Alors là oui !
Posté par Faya . Évalué à 2.
Idem pour certains téléviseurs. Enfin il y a la diode rouge qui devient blanche à l'allumage mais il y a un tel lag entre l'appui et la réaction de la télé que régulièrement mes parents appuient plusieurs fois et donc ré-éteignent l'appareil. Un autre exemple récent dont je ne sais pas si il colle vraiment au journal : les jeux en javascript. Mon fils aime bien un certain casse-brique mais j'ai beaucoup de mal à y jouer parce qu'il faut impérativement utiliser la souris mais surtout la barre du casse-brique ne suit pas la position du pointeur souris ! Donc quand tu bouges, la barre parcoure une certain distance et le pointeur (une grosse main qu'on ne peut pas masquer) bouge dans le même sens mais plus rapidement. C'est très perturbant pour moi, quand le pointeur est au bout de l'écran tu t'attends à ce que ça soit le cas de la barre en-dessous mais en fait non.
Bon cela dit le problème existait déjà sous Windows 95 : qui n'a pas appuyé plusieurs fois sur l'icône IE pour se retrouver avec 7 instances du navigateur ouvertes…
[^] # Re: Alors là oui !
Posté par raphj . Évalué à 2.
Pour le coup, ça ressemble à un truc intentionnel non ? Pas un "vrai" ralentissement à cause d'un code en carton.
(ça me perturberait aussi je pense)
[^] # Re: Alors là oui !
Posté par monseigneur . Évalué à 2.
Les télécommandes bluetooth : il faut souvent appuyer deux fois. La première fois ne fait que réveiller la télécommande qui s'était mise en sommeil pour épargner sa source d'énergie. Et c'est seulement la deuxième (voir troisième…) fois que l'appareil commandé reçoit enfin le signal de réveil et là seulement débute l'attente avant la parfaite disponibilité de ce dernier…
# Anecdote sans pertinence
Posté par Benoît Sibaud (site web personnel) . Évalué à 9.
L'autre jour, j'appuie sur l'interrupteur pour allumer la lumière dans un escalier, j'ai eu le temps de me demander pourquoi ça restait noir et d'envisager de réappuyer, et la lumière est apparue. Je me suis dit « la lumière est lente ici ». Il y a fort à parier (ou alors pas mal d'argent à se faire) que l'électricité ou la lumière ne sont pas plus lents ou rapides que un autre escalier, mais que par contre l'ampoule à LED est une électronique plus lente…
Il y a quelques situations où la patience est très réduite (l'éclairage me semble un bon cas pour ça) ou l'effet de latence assez visible (typiquement la voix et les collisions dans les échanges si on atteint les centaines de millisecondes de délai aller/retour). D'autres où la patience est limitée (classiquement une à quelques secondes quand on a cliqué sur un site web, avant qu'on re-clique comme encouragement au paquet réseau précédent pour lui dire vas-y mon champion accélère).
Ça implique quand même un changement certain avec par exemple pour une GUI, au lieu d'avoir un bouton au repos, puis un bouton enfoncé, avec un présupposé d'instantanéité en réaction et enfin un bouton de nouveau au repos, il faut avoir un bouton au repos, puis un bouton enfoncé tendance c'est en cours, puis une transmission de l'action à faire çà qui de droit, et au bout d'un moment un retour pour dire ça a réussi / échoué / timeout, et enfin un bouton qui revient au repos. (bref plus de boulot pour les dév pour gérer plus de comportements et d'états et de transitions).
Dernier point : la physique limite. S'il faut un tour de planète ou un aller-retour aux antipodes, la vitesse de la lumière donne un minimum nécessaire (sans compter que ce n'est pas en ligne droite et que les équipements intermédiaires ne sont pas sans introduire de latence). Il y a aussi des limites sur l'électricité ou le son évidemment ou le temps de remontée d'un bouton de radiocassette. Ou des cas où on bride volontairement (pas envie qu'un lecteur CD s'ouvre suffisamment vite pour briser/tordre un doigt, ou éjecte un DVD de manière cinétiquement dommageable, ou que le retour haptique d'une manette puisse faire de même…) -> ça veut dire que l'interface doit le prendre en compte (ie. ça ne va pas se résoudre tout seul) si on se retrouve dans les cas limites.
[^] # Re: Anecdote sans pertinence
Posté par cli345 . Évalué à 1.
Surtout que plus le nombre d'états et de transitions augmente, plus la complexité augmente jusqu'à parfois devenir pratiquement ingérable. En effet, les états et transitions sont globaux, c'est un défaut bien connu de la programmation événementielle. C'est pour cela qu'il y a toute une série de langages expérimentaux qui cherchent à alléger ce problème, par exemple, SugarCubes, Pendulum, Céu, tbc et FuncSug (le mien).
# Merci Windows !
Posté par PhRæD . Évalué à 3.
En 2024, il faut parfois plus d’une minute pour lancer un logiciel, parfois une demi-seconde. Du coup, il m’arrive des fois de lancer 3 fois le même logiciel… Fatiguant à la longue…
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
# Au bon vieux temps des IHM automobiles.
Posté par xavier philippon . Évalué à 6.
Quand j'ai commencé à bosser chez des équipementiers automobile, au début des années 90, la règle était claire.
Il ne devait pas se passer moins de 200 ms entre une action sur un bouton et la prise en compte par le système. On pouvait à la rigueur atteindre 300 ms, mais pas plus.
Par la suite, je me suis aperçu qu'avant même les IHM tactiles, on avait bien dérivé … Je n'ose pas imaginer une latence d'une seconde sur la pédale de frein. :-(
Plus près de nous, je vous invite à tester une interface Android TV sur un récepteur d'entré de gamme. ;-)
[^] # Re: Au bon vieux temps des IHM automobiles.
Posté par Pol' uX (site web personnel) . Évalué à 8.
Du coup il faut systématiquement programmer des centaines de millions de nop ?
Adhérer à l'April, ça vous tente ?
[^] # Re: Au bon vieux temps des IHM automobiles.
Posté par ElectronLibre63 . Évalué à 5. Dernière modification le 10 juin 2024 à 15:03.
Puisque tu parles d'automobile, ce qui me gonfle le plus, c'est le bouton de volume de l’autoradio. Au démarrage, il faut plusieurs secondes avant que celui-ci soit fonctionnel. Et une fois qu'il fonctionne, il y a une latence entre le moment où on le tourne, et le moment où le son change. Donc il faut tourner le bouton, attendre le changement de volume pour le réajuster si nécessaire. En analogique, le changement de volume était suffisamment rapide pour avoir l'impression qu'il était instantané, il était plus facile de le régler, et je n'avais jamais besoin de le réajuster plusieurs fois. Le potar analogique a aussi des défauts, notamment le vieillissement qui peut créer des crachotements pendant le réglage, mais au quotidien, ça reste tout de même beaucoup plus agréable.
[^] # Re: Au bon vieux temps des IHM automobiles.
Posté par martoni (site web personnel, Mastodon) . Évalué à 4.
Voila qui illustre exactement le problème. Je pense qu'on peut lui mettre un E à cette bagnole ;)
J'ai plus qu'une balle
# Flim Like Interface Humain Machine
Posté par devnewton 🍺 (site web personnel) . Évalué à 10. Dernière modification le 01 juin 2024 à 13:53.
Plutôt que temps réel dont le sens est ambigu, je propose de parler de FLIHM: les interfaces doivent aussi réactives que celles qu'utilisent les héros dans les flims.
- Regarde cette photo, Mulder, le suspect a l'habitude d'aller à ce restaurant le vendredi.
- Je cherche le nom - taptaptap -, ah c'est dans la ville d'à côté.
- Très bien, je réserve une table - clic clic -, voilà c'est fait, on va pouvoir l'espionner.
- Je commande un micro espion - tap tap, clic -, je choisis la livraison pour demain - tap clic -, c'est bon on l'aura pour… Oh non!
- Quoi?
- Le livreur… C'est DPD…
- Oh non, c'est foutu !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Flim Like Interface Humain Machine
Posté par ted (site web personnel) . Évalué à 4.
J'appelle Internet!
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Flim Like Interface Humain Machine
Posté par Micromy (site web personnel) . Évalué à 4.
Rhoo! C'est pas bien de taper sur DPD alors qu'ils peuvent être… En avance ! Je viens d'avoir le cas:
< ma vie >
Jeudi 30 mai en soirée, par mail et SMS :
"Bonjour, votre colis zzz va être livré le 3/06 entre 11h et 18h. Merci de préciser vos options blabla…"
Vendredi 31 mai vers 8h :
"Bonjour, votre colis va être livré aujourd'hui entre 11h et 18h…". Bien entendu j'étais absent - j'ai un travail, c'est idiot mais ça me permet de d'acheter des trucs - et donc avis de passage dans ma boîte + mail et SMS "Oh vous étiez absent quel dommage…"
Aujourd'hui lundi 3 juin j'ai été livré par un livreur vénère et pas sympa, qui n'a pas voulu écouter les raisons de mon absence le 31…
Vive l'uberisation et les systèmes informatiques à 2 balles !
< /ma vie >
[^] # Re: Flim Like Interface Humain Machine
Posté par lasher . Évalué à 2.
Ici, DPD devait me livrer un truc entre le 8 et le 12 juin. Le 5 à 22h30, je reçois un mail me disant qu'ils me livreront le 6 entre 8h et 18h. Je décale au 8, ça m'arrange, c'est un samedi. Le lendemain, quand je me réveille un peu avant 8h, je vois que j'ai un appel manqué, et un SMS envoyé à 6h30 pour me demander si je suis chez moi.
Wouhou.
Heureusement que j'avais repéré le mail de dernière minute la veille…
# avant avec Firefox
Posté par bertrand . Évalué à 10.
Dans le passé, avec Firefox, quand on cliquait sur un lien, il y avait sur la gauche du titre de l'onglet dans la barre de même nom, une flèche qui tournait dans le sens des aiguilles d'une montre pendant un certain temps puis dans l'autre sens, avant de disparaître au moment ou la page s'affichait.
De mémoire la rotation en sens inverse durait le temps de la résolution DNS et peut être de l'envoi de la requête, puis se mettait à tourner dans le sens normal pendant la réception d(u|es) contenu(s).
C'était très pratique pour justement savoir ou on en était.
Maintenant on a une animation avec un point qui se dandine de gauche à droite en ne fournissant aucune information.
C'est la tendance des IHM depuis une vingtaine d'année à surtout fournir le minimum d'information pour ne pas surcharger l'unique neurone supposé de l'utilisateur.
# Selon les bureaux...
Posté par Maderios . Évalué à 6.
Selon le type de bureau que l'on utilise, ce temps de décalage varie beaucoup (la connexion au Net est une autre histoire). Utilisateur d'Enlightenment, j'ai testé récemment KDE/Plasma, Gnome, XFCE4, LXDE et beaucoup d'autres. La palme de la lenteur revient à KDE/Plasma. Il faut dire que déjà, sans aucune appli lancée, Plasma consomme plus de 1Go en ram. Gnome s'en tire mieux: un peu moindre consommation de ram, plus réactif. Les bureaux les plus rapides sont ceux qui optimisent les ressources cpu et ram, privilégient la rapidité et non les effets visuels. Mon palmarès: Enlightenment, qui réussit la performance d'être très réactif, consommer peu de ressources (+- 100 Mo ram) tout en offrant la possibilité d'effets visuels (désactivables) pour les accro au bling-bling. XFCE4: un peu moins réactif qu'Enlightenment, plus conservateur mais une bonne solution pour celles et ceux qui veulent du simple qui fonctionne bien et fuient les effets de mode.
[^] # Re: Selon les bureaux...
Posté par tisaac (Mastodon) . Évalué à 2.
Tu as testé KDE Plasma 5 ou KDE Plasma 6 ?
J'ai cru comprendre que réduire les ressources nécessaires pour faire tourner le bureau était un de leur objectifs dans le cadre du développement de Plasma 6
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Selon les bureaux...
Posté par Maderios . Évalué à 3.
J'ai testé Plasma 6.05 dans Arch stable. Plasma 6.0.90 est dispo dans le dépôt KDE-Unstable
[^] # Re: Selon les bureaux...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 5.
Je fais partie de ces utilisateurs de XFCE4. C'est réactif, simple et ça fait juste le boulot.
Le seul hic, c'est l'explorateur de fichiers vraiment pas top (bugs, lags, plantages)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Selon les bureaux...
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Tu es sur quelle version de XFCE ? Je le trouve plutôt véloce et je n'ai pas de plantage.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Selon les bureaux...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
XFCE 4.16 - je suis sur Debian 11. Le gestionnaire de fichier c'est thunar 4.16.8.
C'est véloce généralement, mais à certains moments ça se met à laguer puis "pop", le navigateur disparaît :-o
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Selon les bureaux...
Posté par Sylvain Colinet (site web personnel) . Évalué à 1.
Prendre plus ou moins de RAM ça a aucun rapport avec la réactivité ou la performance d'une application. D'ailleurs c'est une source de gain de performance : prendre plus de ram pour mettre plus de chose en cache et éviter des accès fichiers/DB.
Plasma fait beaucoup plus de chose qu'un simple Windows manager aussi, c'est dur à comparer à xfce par exemple.
[^] # Re: Selon les bureaux...
Posté par Mildred (site web personnel) . Évalué à 2.
C'est étrange, je suis partie de GNOME justement pour sa lenteur. Pas de manière générale, mais dans certains cas lorsque je PC tourne (il compile par exemple) l'interface devient leeeeente. Avec Plasma c'était plus réactif au contraire.
# Js
Posté par Watchwolf . Évalué à 1.
Je vois la classique critique de JavaScript.
Pourtant le js permet d’avoir l’interface chargée côté utilisateur et ainsi télécharger uniquement les données depuis le serveur.
Plus généralement ce sujet me fait penser au bip sur les claviers des téléphones ou sur les montres que je désactive systématiquement parce que c’est lourds …
[^] # Re: Js
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
C'est précisément là tout le problème des SPA, encore faut-il télécharger ce javascript côté utilisateur.
Perso je suis de plus en plus séduit par les solutions comme HTMX.
Le mieux serait un truc comme Elixir + Phoenix + LiveView mais quand j'en parle autour de moi, les gens ont pas l'air prêts :-(
[^] # Re: Js
Posté par Franck Routier (Mastodon) . Évalué à 2.
Le problème n'est pas le JS en lui-même, c'est l'écsystème JS (node, les frameworks, etc…).
Le résultat est des développeurs souvent mal à l'aise avec le JS pur, promptà importer l'internet entier dans les dépendances de leur projet, etc.
Bref, du bloat, du bloat, du bloat.
# C'est Kafkaïen...
Posté par Franck Routier (Mastodon) . Évalué à 1.
Marrant, j'étais persuadé de tomber sur un article sur Kafka https://www.redhat.com/fr/topics/integration/what-is-apache-kafka …
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.