Léa Verou défend l'usage d'un interrupteur à deux états pour basculer entre les modes clair et sombre, plutôt qu'un système à trois options (clair, sombre, système). Elle argue que la plupart des utilisateurs n'ont pas besoin de cette troisième option, qui complique l'interface sans réel bénéfice, car leur objectif principal n'est pas de configurer le thème mais d'utiliser le site. Un interrupteur simple permet de répondre aux besoins réels des utilisateurs tout en évitant une surcharge cognitive.
L'auteure explique que les interrupteurs à trois états sont souvent motivés par la structure technique sous-jacente plutôt que par les besoins utilisateurs. Bien que le modèle de données puisse nécessiter trois états, seul l'un d'eux est pertinent à un moment donné. Elle illustre ce point en comparant avec un robinet mélangeur, où l'interface simplifiée correspond mieux à l'objectif de l'utilisateur que la complexité technique sous-jacente.
Enfin, Verou souligne que les interrupteurs à deux états sont plus intuitifs et évitent de confronter l'utilisateur à des choix sans différence visible, ce qui va à l'encontre du principe de feedback en UX. Elle reconnaît que des exceptions existent, notamment dans les paramètres dédiés où trois états peuvent être justifiés, mais pour la majorité des cas, une solution plus simple et efficace est préférable.
Jim Nielsen réfléchit sur la simplicité et l'évidence en bloguant, soulignant que partager des idées perçues comme évidentes peut être utile. Il cite John Gruber, qui critique les pratiques intrusives des sites web (popups, cookies) en rappelant que leur rôle est avant tout d'afficher leur contenu. Nielsen admet que ses propres billets lui semblent parfois trop basiques, mais constate que pointer des problèmes évidents mais ignorés par d'autres peut être pertinent.
L'auteur compare cette démarche à l'histoire du Vêtement neuf de l'empereur, où le simple bon sens est souvent négligé. Il note que les meilleurs articles sont souvent ceux qui osent énoncer des vérités simples que personne n'exprime, ou qui amplifient des idées déjà partagées par d'autres. Pour lui, la clé du blogging réside dans cette franchise face à l'évidence.
Le billet met en lumière une tendance où les blogueurs hésitent à publier des contenus jugés trop simples, alors que ces prises de position peuvent résonner avec un public lassé des pratiques abusives en ligne. Nielsen encourage ainsi à assumer ces évidences, quitte à les répéter ou à les relayer.
L'article propose une approche simplifiée du CQRS (Command Query Responsibility Segregation) en séparant clairement les opérations d'écriture (modification de données) et de lecture (récupération de données) au sein d'un service Node.js, sans recourir à des architectures complexes comme l'event sourcing ou des bases de données distinctes. L'idée centrale est de scinder un service monolithique en deux parties distinctes : une dédiée aux commandes (écritures) et une autre aux requêtes (lectures), afin d'éviter les conflits de responsabilités et d'améliorer la maintenabilité.
L'auteur illustre ce concept avec un exemple concret, comme un OrderService qui mélange des méthodes de gestion des commandes (validation, règles métier) et des méthodes de récupération de données (requêtes, transformations pour l'interface utilisateur). Cette séparation permet de faire évoluer indépendamment les deux parties en fonction des besoins changeants de l'application, réduisant ainsi la complexité et les risques d'erreurs. L'approche reste légère et applicable rapidement dans un projet existant.
Ce billet de blog explore un problème subtil mais persistant dans les équipes d'ingénierie : la valorisation excessive de la complexité au détriment de la simplicité. L'auteur observe que les ingénieurs qui sur-ingénierisent leurs solutions sont souvent mieux récompensés et promus que ceux qui livrent des solutions simples et efficaces. Ce biais se manifeste dans les entretiens d'embauche, les évaluations de promotion et les revues de conception. La complexité est perçue comme plus intelligente et impressionnante, même si elle n'est pas nécessaire, tandis que la simplicité, bien que souvent plus efficace, est moins visible et moins valorisée. L'auteur appelle à une réévaluation de ces systèmes de récompense pour encourager la simplicité et éviter les pièges de la complexité inutile.
L'article plaide pour l'utilisation de PostgreSQL comme solution universelle pour les bases de données, remettant en question l'idée de "l'outil adapté à la tâche". L'auteur argue que la multiplication des bases de données spécialisées (comme Elasticsearch, Pinecone, Redis, etc.) entraîne une complexité inutile, surtout à l'ère de l'IA où la simplicité est cruciale. Il souligne que PostgreSQL, avec ses extensions, peut gérer efficacement des tâches variées (recherche, vecteurs, séries temporelles, files d'attente, etc.), réduisant ainsi la gestion et les coûts. L'article démontre que, pour la plupart des entreprises, PostgreSQL est une solution plus simple et plus efficace que l'utilisation de plusieurs bases de données spécialisées.
Cet article explore la tendance croissante des frameworks HTML-first, comme htmx, qui révolutionnent le développement web en revenant à une approche plus simple et performante, centrée sur le HTML et le serveur, plutôt que sur des applications monopages (SPA) complexes. Il met en lumière les problèmes de surcharge JavaScript, les avantages en termes de performance, de simplicité et de maintenance, ainsi que les cas d'utilisation idéaux pour cette approche. L'auteur souligne également les bénéfices pour le SEO, l'accessibilité et l'expérience utilisateur, tout en discutant des situations où une approche différente pourrait être plus appropriée.
L'article met en garde contre la sur-ingénierie et l'utilisation excessive de motifs de conception complexes dans des projets qui ne le nécessitent pas. L'auteur illustre son propos avec un exemple extrême où une simple concaténation de chaînes de caractères est transformée en une architecture complexe impliquant des interfaces, des usines et des modules. Il identifie plusieurs drapeaux rouges, comme la "future-proofing" fallacieuse, les interfaces avec une seule implémentation, et les abstractions prématurées. L'auteur propose une checklist pour évaluer la nécessité d'une abstraction et encourage à supprimer les mauvaises abstractions. Il conclut en rappelant que le code "scalable" ne doit pas être surestimé et que la simplicité est souvent la clé.
Ploum explore le concept de calendar.txt, un fichier texte simple pour gérer son emploi du temps, et partage comment il l'a intégré dans son workflow Unix. Il apprécie la simplicité et l'efficacité des commandes basées sur le texte pour afficher les événements du jour, ajouter des événements récurrents, et gérer les invitations, contrastant cela avec la lourdeur des interfaces web et les "redesigns" constants. Il voit en calendar.txt un exemple parfait de la puissance des outils Unix pour créer des solutions personnalisées et élégantes, loin des plateformes commerciales complexes.
Suite de https://lorenzofox.dev/posts/lets-build-a-framework-part-1 l'auteur simplifie le composant / framework qu'il avait créé. Il plaide en faveur de l'utilisation de solutions maisons pour lutter contre l'augmentation de la taille des frameworks JS
Tout est dans le titre
Une réflexion intéressante
Un article anniversaire, et quelques liens très intéressants dedans sur le web, la simplicité, les CMS, flash :-)