PROJET AUTOBLOG


le hollandais volant

Site original : le hollandais volant

⇐ retour index

Mise à jour

Mise à jour de la base de données, veuillez patienter...

Les interfaces déficientes dans la vie courante

dimanche 20 juin 2021 à 19:30

Je suis webdev à mes heures. Une partie du boulot consiste à savoir quels éléments utiliser dans l’interface des pages web pour avoir une interaction simple entre l’humain et la machine.

Pour une action « A », est-ce qu’il vaut mieux :

Tous les développeurs d’interface graphique font face à ça.

Exemples d’interfaces et comment choisir la bonne

Parfois, les choix sont simples. Par exemple, pour proposer de choisir un pseudo, il serait malvenu de proposer 15 menus déroulants de A à Z où l’utilisateur choisit son nom :

i
Cela serait la galère, non ? Oui, on est d’accord.

Maintenant, imaginez, vous avez question : « Que voulez-vous sur votre sandwich ? »

Lequel de ces sélecteurs est plus pratique :

i
i
Évidemment, il s’agit du second. Pourquoi ? Parce qu’il reflète la vraie vie. Dans une sandwicherie, un dialogue se passerait typiquement comme ça. Prenez l’exemple de chaîne « subway », où ça se passe exactement de cette façon :

« je vous met du fromage ?
— oui
— de la salade ?
— oui
— du jambon ?
— non merci
— du beurre ?
— non merci »

Il est donc normal qu’on fasse une interface qui retranscrive tout ça. L’interface humain-machine (IHM) doit idéalement refléter une interaction humain-humain.

Laissez-moi redire ça : une interface humain-machine n’est bien faite que si elle reflète une interaction naturelle entre deux personnes. Autrement, votre interface peut-être considérée comme globalement merdique. Point.

À l’inverse maintenant, s’il n’était pas possible de combiner les ingrédients, mais qu’on était limité à un choix unique, on aurait eu le dialogue suivant :

« je vous met du fromage, de la salade, du jambon, ou bien du beurre ?
— du fromage, s’il vous plaît ! »

… et dans ce cas, l’élément d’interface appropriée aurait été le menu déroulant à choix unique (ou bien une interface à bouton « radio »), mais sûrement pas les cases à cocher qui sont — par nature — à choix multiple.

Ça peut sembler simple, tout ça. Probablement trop. Pourtant, créer des interfaces permettant une expérience utilisateur convenable, c’est un métier, et ce n’est pas pour rien.

Dans les faits, c’est dingue comme il existe des cas d’interfaces tellement pourries qu’on se demande ce qui est passé par la tête de leur concepteurs… et dans celui des managers qui ont embauché ces personnes, et aussi dans celui des chefs de projets qui vont validé ça au cours de réunions « café-croissants-cravates »

Cas d’une interface limitée par contrainte

Parfois, les limitations techniques empêchent de prendre l’interface approprié et on doit faire au mieux.

Ainsi, une guirlande de noël « RGB » qui n’a qu’un seul bouton poussoir, propose les combinaisons « R », « G », « B », « RG », « RB », « GB », « RGB ». Cela correspond à une interface style « menu déroulant » cyclique, en bouclant sur toute les possibilités avant de revenir à la première. À l’utilisateur de s’arrêter à la combinaison qu’il souhaite.

Sur la guirlande avait eu un petit écran tactile pour choisir, il aurait pu proposer des cases à cocher pour permettre de cocher/décocher les couleurs voulues.

Ici, évidemment, on ne va pas mettre un écran tactile sur un câble de guirlande. Donc on fait au mieux.

Sur un appareil plus gros par contre, où l’on n’est pas limité à un seul bouton et qu’on peut virtuellement en mettre autant qu’on veut, on doit en mettre autant qu’il en faut, ni plus, ni moins.

Dans les exemples qui suivent, ce principe n’est pas respecté.

L’interface du système de chauffage d’une voiture

Le sélecteur de chauffage dans sa voiture permet de choisir où l’on envoie l’air chaud (ou froid) :

Et l’on a donc trois boutons bien séparés pour choisir :

Imaginez un peu la galère en revanche si on avait un sélecteur circulaire qui boucle entre « haut », « vitres », « haut + vitres », « pieds + vitres », « vitres + haut + pied », etc..

Comme ça :

Interface chauffage voiture.
Heu… mais c’est ce que font toutes les voitures !

Et oui, et je trouve que c’est du gros n’importe quoi.

Comment faire si je veux les vitres et le haut ? On peut pas.
Par contre, je peux avoir les vitres et les pieds. C’est à rien n’y comprendre.

Va-t-on me faire croire que ce n’est pas possible — techniquement — de faire 3 boutons on/off pour choisir où envoyer l’air ? Surtout dans les voitures actuelles qui ont des climatisations bi-, tri- voire quadri-zone, où l’on peut envoyer l’air chaud à gauche, l’air froid à droite, ou vice-versa et la même chose à l’arrière au gré de chacun des passagers.

Je ne connais pas une seule @#%µ& de voiture qui propose une interface correcte pour ce système.

La mienne, qui date de 2020, et qui a plus d’options que je n’utilise, a ce style de sélecteur merdique ! Pire, il s’agit même d’un bouton tactile cyclique qui empêche de voir où on en est dans la boucle et où les autres sélecteurs — clim, désembuage auto, bi-zone — entrent en conflit ou réinitialisent ce premier sélecteur.

C’est absolument ridicule, mais ce n’est pas un cas isolé.

L’interface des fours électriques

Dans ma cuisine j’ai un four électrique avec une grille en haut, une grille en bas et un ventilateur pour faire circuler la chaleur.
Pensez-vous qu’ils auraient fait trois boutons ?

Bien-sûr que non :

Interface bullshit de four.
Et je passe sous silence les interfaces abominables des fours à micro-ondes avec « réchauffer », « cuisson », « décongélation », et tout un tas de pré-réglages à la con qui ne suffisent qu’à 0,3 % des cas et qui ne fonctionne que 5 % du temps.

En règle général, pour ce genre d’appareil, on devrait se contenter de deux choses :

La chauffe d’un plat est conditionné par l’énergie thermique qu’elle reçoit de l’appareil.

Or vous savez-quoi ? L’énergie est le produit de la puissance par la durée d’exposition à cette puissance : E = W×t.
Deux boutons suffisent donc pour un four à micro-ondes, un four, une chauffe biberon, une plaque chauffante…

Les machines à laver

Et sur les machines à laver ?

Pourquoi devrait-il être simple de constituer son propre programme avec pré-lavage (oui/non), lavage (oui/non), essorage (oui/non) ?

Est-il écrit quelque part qu’il doit y avoir systématiquement un bouton circulaire avec N choix parmi toutes les possibilités, qui plus est sans ordre logique, et de surcroît où il en manque toujours une ou deux ?

Interface machine à laver.

Là aussi, de façon général, réservez les boutons circulaires à un choix qui permette de graduellement changer un paramètre : température, vitesse d’essorage… N’utilisez pas ça pour des options décorrélées entre-elles.

ÉDIT : quelques autres problèmes d’interface

Dans ma Hyundai Ioniq, il y a une multitude d’options, mais tous ne sont pas configurables au même endroit.

Pour ma part, je pense qu’il y a plusieurs types de fonctions :

Dans la Hyundai, tout est mélangé. Certains boutons physiques ne servent jamais. Pire, l’assistance de maintient de voie est accessible via un bouton ET via les menus.

Aussi, les boutons sont en on/off. Normalement leur état est enregistré quand on éteint la voiture. Certains oui. D’autres non, comme le auto-hold du frein. C’est incompréhensible. Ça c’est typiquement l’option qui devrait être dans la catégorie « accessible très rarement » : c’est une préférence de l’utilisateur, pas une option qu’on change tout le temps.
De même que l’assistance au maintient de voie et le détecteur d’angle mort : pas besoin de boutons physique pour ça.

Tesla la bien compris : tout est dans le système d’infotainment, et dans deux sections : les fonctions accessibles très vite, et les options de préférences. Pas de mélange.

Et, toujours dans la Hyundai, je ne parle pas des la disposition des boutons : il y en a au volant, dans le compteur (menus virtuels), sur la portière, sur la console centrale, autour du levier de vitesses, en bas à gauche du volant, en bas à gauche du volant mais un peu plus bas… Y en a partout. C’est pauvrement étudié.

Autres liens

Vivaldi après 1 mois… Retour sous Firefox

dimanche 20 juin 2021 à 15:45

i
Ça fait quelques semaines que j’utilise Vivaldi en navigateur principal sur mon ordi.

J’avais changé, car j’étais lassé de Firefox et quelques-unes de ses options qui partent, viennent, repartent, et de divers choix incompréhensibles faites par Mozilla sur ce navigateur, et dans l’espoir de trouver une solution plus « future-proof » que Firefox qui est virtuellement mourant et que Mozilla considère comme un fardeau plutôt qu’un fer de lance.

Vivaldi n’est pas officiellement libre, mais tous leurs composants le sont, même si en partie c’est porté par Google.
Vivaldi est le navigateur plein d’options pratique et qui reste utilisable. Du génie. Je n’ai rien à reprocher au travail que Vivaldi a fait avec ce navigateur : il est complet et pratique.

Juste un truc.
Blink.

Blink c’est le moteur de rendu (à l’origine un fork de Webkit) : le sous-programme du navigateur responsable de l’affichage des pages. C’est le même moteur de rendu que Chrome, Edgium, Chromium, Opera…

Ce qui différencie ces navigateurs, c’est tout le reste qui n’est pas le moteur de rendu, c’est-à-dire la partie visible du navigateur (menus, disposition, couleurs…).

Or :
Blink est lent.
Blink est mauvais.
Blink est lourd.
Mais Blink est utilisé par 80 % des navigateurs.

En bref, Blink c’est le nouveau IE6.

Pour l’affichage des pages, Firefox est plus fidèle aux standards.
Pour l’exécution des programmes web, Firefox est plus rapide.
Pour la gestion des ressources, Firefox est moins gourmand.

Firefox n’utilise pas Blink, mais Gecko/Servo (projet Quantum). Ce moteur est rapide, efficace, léger. Y a pas à dire. Ça n’a plus rien à voir avec le Firefox de 2015 où c’était un gros patapouf hyper-lent.

À ce jour, c’est la seule alternative au monstre Blink. Et c’est bien dommage, car même Mozilla semble délaisser le truc pour se lancer dans ses projets commerciaux (à coup de licenciements et plans de restructuration).

À l’époque d’Opera 12 (ancêtre spirituel de Vivaldi), Opera n’utilisait pas Blink/Webkit mais leur propre moteur de rendu : Presto. Il était plus rapide que Gecko et Webkit, mais Opera l’a laissé tomber pour se tourner vers Webkit (devenu Blink ensuite).

Quand Vivaldi est né, quelque temps après, ils ont fait le choix de prendre Blink et non Gecko.
Je ne suis pas là pour dire qu’il s’agisse d’une erreur, mais pour moi, ça reste un défaut et un reproche technique.

Après un mois sous Vivaldi, je le vois tous les jours : un clic droit dans un champ texte sous Vivaldi prend plusieurs secondes (c’est instantané sous Firefox). Les outils de dév sont bien plus complets et orientés utilisateur dans Firefox que dans Blink. Les éléments d’interface (input number/date/…) sont mieux pensés dans Firefox que dans Vivaldi/Chrome. Sans compter l’affichage des pages, les rendus graphiques…

Bref, Vivaldi est bon, vraiment très bon…
… si vous venez de Chrome/Opera/Edgium. Vraiment : essayez-le, vous ne verrez pas ces défauts et vous aurez un navigateur mieux foutu et mieux pour votre vie privée.

Mais si vous arrivez de Firefox, vous aurez un truc plus lent, plus lourd et les contrôles dans les pages seront ce que Firefox avait il y a 10 ans.

Si vous êtes web-dév, oubliez les outils de dév de Chrome/Vivaldi/Blink : c’est de la vraie merde. Ceux de Firefox sont plus complets, plus pratiques, même si un point plus bugué.


@Vivaldi : le jour où vous passez de Blink à Gecko, vous aurez le meilleur navigateur du monde.
En attendant, vous avez la meilleure interface avec le pire moteur de rendu.


ÉDIT : je dis bien qu’ici tout ça concerne mon ressenti après une utilisation représentative de mon usage, avec les modules, ma configuration… bref, des conditions réelles ; soit tout le contraire d’une « fresh-install » habituellement utilisée lors des benchmark et des tests journalistiques.

Ah et aussi sous Linux (Linux Mint).

TousAnti-TousAntiCovid !

mercredi 9 juin 2021 à 18:26

Imposer un mouchard gouvernemental et rentabiliser ça, en 7 étapes, sous couvert de crise sanitaire et « pour notre bien ».

Étape 1

Gouvernement : “Faisons une application anonymisée qui regarde si l’on a croisé quelqu’un touché par le Covid. Ça n’enregistre rien, juste le fait que le porteur de l’appli ait ou non eu le virus. L’ensemble est centralisé pour coordonner les notifications”

Les geeks paranos : “Mouais, ok.”

La CNIL : *Zzzz… Zzzz…*

Étape 2

Gouvernement : “En fait, regardez, vous pouvez faire vos attestations avec l’application. Faut juste mettre votre nom, votre adresse, etc.”

Les geeks paranos : “C’est bon, je désinstalle.”

Les gens : “rhoo, tu vois le mal partout.”

La CNIL : Zzzzzzzzzz… Zzzz…*

Étape 3

Gouvernement : “et on va inclure un QRCode nominatif, en clair dedans. Il sera scannable avec une autre appli privatrice.”

Les geeks paranos : “Heu… c’est normal que l’autre appli ait besoin du réseau ? Et fasse des requêtes qui incluent les coordonnées GPS ? C’est chelou, ça sera sans moi.”

Les gens : “oh, les restos sont ouverts ! Serveur, une bière s’il vous plaît !”

La CNIL : Zblblbl…*

(source)

Étape 4

Gouvernement : “En fait, ça serait bien que nos appli récoltaient toutes les données sur tous les téléphones, pour pouvoir cibler les personnes fragiles.”

Les geeks paranos : “vous voulez siphonner tous les téléphones, en fait, maintenant que l’appli est installée partout ?”

Les gens : “Serveur, une autre bière !”

La CNIL : *Zzzzzz*

(source)

Étape 5

Gouvernement : “L’appli est désormais obligatoire pour faire vos courses, c’est pour votre bien. Et vous scannerez le ticket de caisse en sortie avec l’appli.”


Les geeks paranos : “Ah carrément ? Et si j’ai pas de téléphone ?”

Les gens : “Tout le monde a un téléphone, fais pas le con !”

La CNIL : *a fusionné avec le CSA*

Étape 6

Gouvernement : “Qu’est-ce qu’on va bien pouvoir faire de ces données ? On pourrait les vendre !”

VOUS ÊTES ICI ↑ (mis à jour le 23/08)
Les geeks paranos : “comme les anglais ?”

Les gens : “Osef, j’ai rien à cacher.”

Le CSA : “$$$”

(source)
(source, pour la France, le début en tout cas)

Nouvelles de oText (built 2021-05)

lundi 10 mai 2021 à 06:04

Capture d’écran de oText.

Présentation

oText, c’est le programme « maison » que j’utilise pour publier des articles sur ce blog.

Depuis longtemps, il s’agit d’un peu plus qu’un simple moteur de blog, puisqu’il me permet également de partager mes liens « au fil du web », d’envoyer des fichiers sur mon serveur, de suivre mes flux RSS, d’avoir un moyen de prise de notes (façon Google Keep), de gérer un agenda, et plus…

… le tout sous une même interface de gestion, ce qui était le but visé depuis le début.

Ça ressemble un peu à NextCloud, dit comme ça, mais NextCloud est beaucoup plus complet, avec application mobile, gestion Caldav, CardDav, sondages, formulaires, modules…

Mon outil, en contrepartie du nombre restreint de fonctions, est plus léger (seulement 1,3 Mo, contre 375 Mo pour NextCloud). Il suffit néanmoins si vous voulez simplement un petit script web dans le navigateur. Et c’est mon cas.

Ça fait longtemps que je n’en ai pas parlé ici, mais je considère que cette version est relativement aboutie. Les principales nouveautés concernent un thème admin peaufiné avec un choix clair ou sombre (on peut forcer l’un ou l’autre, ou alors laisser le navigateur choisir en fonction des préférences du système). Le thème public — refait lui aussi — s’adapte par défaut aux paramètres du navigateur de l’internaute.

Comme toujours, l’accent est mis à la fois sur l’UX/UI en material-design, et respect des standards du Web et la légèreté (l’interface en JS reste très rapide), et sur la présence des options les plus utiles sans tout le superflu présent sur d’autres programmes du genre.

Astuce : vu le poids du script (1 Mo), vous pouvez l’installer et l’utiliser comme un lecteur RSS seul, ou pour l’agenda ou les notes seules… bref, en profiter même si vous n’avez pas besoin d’un blog, mais que vous cherchez quelque chose de léger quand-même.

Téléchargement

Fichier 7z : otext.7z

Taille : 408 967 octets
Sha1 : 8cf6fc8a657ff0e1657e75b3c9d23a2cdecc1ef4

Installation

  1. dézippez le fichier dans un dossier « ./blog »
  2. envoyez ce dossier sur votre serveur
  3. rendez-vous dans le dossier ./blog
  4. suivez les quelques étapes d’installation (création d’un pseudo, d’un mot de passe, etc.)

Captures d’écran

Voir sur le folio.
La capture d’en-tête donne déjà une idée.

Dépendances

Côté serveur :

Modules PHP :

(PDO : pour la base de données ; cURL : pour les flux RSS et pour récupérer les titres des liens ; GD : pour le traitement des images uploadées ; XML : pour le parsage des flux RSS ; ZIP : pour la fonction d’export de les données dans une archive ; MBString : pour un support Unicode étendu)

Côté client :

Défauts et fonctions absentes

Des bugs ? Des suggestions ?

En commentaire ci-dessous.

Par contre, j’ai codé tout ça avant tout pour moi et je le mets en ligne à qui le veut, tel quel, dans l’espoir qu’il puisse être jugé utile à d’autres.

Considérez que ce script a simplement le mérite d’exister et d’être à disposition. Il n’y a pas de support ni de maintenance publique du script. Je n’ai pas le temps (ni l’envie) pour gérer le projet ou de façon plus active.

Si vous voulez une fonction spécifique, je vous conseille de la coder vous-même ou de trouver quelqu’un d’autre que moi pour le faire.

Soutien ?

J’ai eu le cas pour d’autres trucs : si certains se sentent l’envie de payer pour ce script, déjà merci, ensuite veuillez me contacter pour qu’on en discute.

Autre chose ?

Non.

Quelques astuces .htaccess

mardi 4 mai 2021 à 22:18

J’avais déjà fait un article sur ça il y a longtemps, mais là aussi il semble qu’elle ne soit plus au goût du jour.

Après moult tests et quelques surprises, je mets ici quelques snippets de code, pour mémo, surtout pour moi.

Notes :

Notes 2 :
Selon votre fichier et les règles qui s’y trouvent déjà, il peut être nécessaire d’y ajouter (une fois) les instructions suivantes :

RewriteEngine on
RewriteBase /

Je ne les fais pas figurer partout ci-dessous.

Forcer la redirection HTTPS

Les navigateurs le font tout seuls parfois, mais il vaut mieux l’ajouter :

## Force HTTPS
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301]

Supprimer le « www », au début du nom du site

Certains préfèrent le conserver, d’autres non. Dans tous les cas, il est préférable d’avoir un choix et de forcer la redirection de l’une des URL vers l’autre. C’est plus propre et c’est aussi mieux pour le référencement d’avoir une seule URL pour chaque ressource :

## Removes www.
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1%{REQUEST_URI} [R=301]

Supprimer les slashes redondants

J’ai mis du temps à trouver un code qui fonctionne quelle que soit la position des doubles-slashs. Généralement les forums en proposaient plusieurs selon que le slash soit au début, à la fin ou au milieu de l’URL.

## Removes multiple consecutive slashes anywhere in URL
RewriteCond %{THE_REQUEST} \s[^?]*//
RewriteRule ^.*$ /$0 [R=301,NE]

Maintenant, les urls suivantes :

Sont toutes réécrites en :

Supprimer le code derrière le chemin d’un script

## Rewrite ^*.php/*$ to *.php$ (removes anything after a "*.php/")
RewriteCond %{REQUEST_URI} ^(.*)\.php/(.*)$
RewriteRule . %1.php [R=301]

Celui-là est plus compliqué.
Quand on appelle un fichier fichier.php, on en exécute le contenu. Si l’on l’appelle avec un paramètre fichier.php?parametre, c’est toujours le même fichier qui est exécuté, mais maintenant l’exécution tient compte de la valeur du paramètre.

Dans le cas suivant par contre, il y a possibilité de problèmes : fichier.php/.
Le fichier est appelé (et donc exécuté), mais il est traité comme un dossier (car il est suivi d’un slash et non d’un point d’interrogation), et avec lui la notion de profondeur de l’arborescence, etc.
C’est un problème assez sévère et je préfère l’éviter.

J’y vais donc assez lourdement : quand je vois un fichier .php qui est directement suivi d’un slash, on vire tout ce qui suit le slash, incluant ce dernier.

Les urls suivantes :

Sont toutes réécrites en :

Notez que ça ne visera que le script exécuté. Rien n’empêche en effet d’avoir la chaîne « .php » suivi d’un slash dans un paramètre d’un autre fichier php (celui exécuté).
Cette URL ne sera pas modifiée, par exemple : exemple.com/fichier.php?parametre=fichier.php/bla/bla

Supprimer le « index.php » à la fin des URL

## Rewrites "/index.php" to "/"
RewriteCond %{REQUEST_URI} ^(.*)/index\.php$ [NC]
RewriteRule . %1 [R=301,L]

Quand on affiche un dossier sur un site, comme example.com/folder/, le « index.php » ou « index.html » qu’il contient est implicitement affiché. C’est la page par défaut. Le demander de façon explicite est donc généralement inutile.

Afin d’éviter d’avoir des URL redondantes, je préfère ne conserver que les URL sans le « index.php ». Les éventuels paramètres, eux, sont maintenus.

Pour résumer

Avec tout ça, toutes les URL suivantes :

Renvoient toutes sur :

Petite note sur les cascades de fichers .htaccess

On peut mettre un fichier .htaccess dans chaque dossier et leurs sous-dossiers si l’on veut, et les directives seront appliquées à tous les fichiers inclus dans le dossier, y compris leurs sous-dossiers.

Par contre, mettre un RewriteEngine on dans un des sous-dossiers pourra avoir pour effet d’annuler les directives des fichiers situées dans les dossiers parents. C’était le cas chez moi récement, même si je n’ai pas souvenir d’un tel comportement lors de la mise en place de ces fichiers.
Il est possible que ça vienne de la configuration du serveur.

Error happened! 0 - Undefined variable: xml In: /home/cochisebee/www/autoblog/autoblogs/autoblog.php:77 http://autoblog.cochi.se/autoblogs/lehollandaisvolantnet_f9e3899f52053c0dd7253d25ca504c7b4265953e/?10 #0 /home/cochisebee/www/autoblog/autoblogs/autoblog.php(77): exception_error_handler(8, 'Undefined varia...', '/home/cochisebe...', 77, Array) #1 /home/cochisebee/www/autoblog/autoblogs/autoblog.php(368): VroumVroum_Feed_Exception::getXMLErrorsAsString(Array) #2 /home/cochisebee/www/autoblog/autoblogs/autoblog.php(932): VroumVroum_Blog->update() #3 /home/cochisebee/www/autoblog/autoblogs/lehollandaisvolantnet_f9e3899f52053c0dd7253d25ca504c7b4265953e/index.php(1): require_once('/home/cochisebe...') #4 {main}