Repository with sources and generator of https://larlet.fr/david/ https://larlet.fr/david/
Você não pode selecionar mais de 25 tópicos Os tópicos devem começar com uma letra ou um número, podem incluir traços ('-') e podem ter até 35 caracteres.

2023-02-18 - Quiz.md 4.0KB

Quiz

On aimerait pouvoir faire des quiz.

Il y a 20 ans, j’aurais commencé à modéliser cela dans une base de données relationnelles avec les bons index et tout.

Il y a 15 ans, j’aurais essayé de représenter cela avec des données liées et du RDF pour une réutilisation sémantique.

Il y a 10 ans, je me serais demandé si ça pouvait rentrer dans Redis ou MongoDB et à quel point ça passerait à l’échelle.

Il y a 5 ans, j’aurais imaginé une API pour pouvoir généraliser l’usage et décliner plusieurs services équivalents.

Et aujourd’hui alors ?

Je commence par me demander comment est-ce que les utilisateur·ices vont pouvoir saisir ces données et devenir autonomes.

Je n’envisage pas qu’iels puissent saisir du HTML — qui plus est valide et accessible — pour concevoir ce quiz. Je me demande quelle serait la structure la plus logique pour déterminer les réponses possibles et mentionner la bonne. Il y a un enjeu de feedback immédiat lors de la rédaction, par exemple en CommonMark un peu étendu dans un pad ou un forge git. J’imagine une structure qui ressemble à :

Le consentement c’est :

* [ ] Demander la permission
* [x] S’assurer à tout moment que l’autre↩ 
      est à l’aise et désire ce qu’on lui fait
* [ ] Peut se donner avec un peu de pression

C’est ensuite à moi de convertir cette structure plate, textuelle, relativement compréhensible en un formulaire web interactif. C’est le seul moment où la technique entre en jeux avec des dépendances aussi minimalistes que possible.

Ce qui a changé en 20 ans, c’est que j’ai pris conscience que la pérennité d’une donnée tient à l’autonomie que l’on peut donner aux personnes qui vont s’assurer de son évolution. La « bonne » modélisation est celle qui est explicite et non réservée à une élite de dévelopeur·euses.

Entre l’User eXperience (UX) et la Developer eXperience (DX), il y aurait peut-être la Maintenance eXperience (MX) ? Et dans ce contexte, l’autonomie vis-à-vis des données est cruciale. Ce n’est peut-être pas techniquement très propre, c’est difficile à mettre en valeur sur un CV ou dans une conférence, c’est même aux antipodes de la mode actuelle.

Mais c’est là où je positionne ma valeur aujourd’hui. De la cathédrale qu’il faut reconstruire tous les 2 ans au refuge qui ne nécessite que quelques planches et clous en maintenance annuelle pour qu’une poignée de personnes y trouvent du réconfort. Et soient en capacité de participer à l’effort commun.


Bandes-dessinées de la semaine :

Je ne sais pas si c’est le fait de résider sur ces territoires mais les deux m’ont pas mal affecté. L’héritage de la colonisation en étant sur les lieux colonisés est encore plus difficile à porter.


Film de la semaine : The Menu (essayez de ne pas vous divulgâcher…).


[en] 💯 Always remember that although a subset of the JavaScript community can be very loud, they represent a paltry portion of the web as a whole. This means that when they say something like “Best practices don’t actually work”—what they mean is “Best practices don’t actually work for a small subset of less than 5 percent of the web”.

*The (extremely) loud minority* (cache)

[en] 🐦 Spinners are the dumbest progress bar.

*A notification center for progress bars that sounds like birdsong* (cache)

accompagnement #simplicité #web