Expérience de densité d’interface créée avec Svelte
(cybernetic.dev)- Grid est une expérience permettant aux utilisateurs d’ajuster la densité de l’interface, et une nouvelle version est actuellement en cours de développement
- Matrix, qui s’inscrit dans cette continuité, vise une densité d’interface plus élevée et affiche une matrice de corrélation du S&P 500 et du NASDAQ-100
- En sélectionnant les titres composant le S&P 500, l’outil traite les corrélations de plus de 2500 cellules et de plus de 30 millions de points de données
- Certaines fonctionnalités ne sont pas présentes dans l’aperçu du bas ; pour les évaluer, il faut ouvrir l’interface Matrix en plein écran
- Les contenus du site sont fournis à titre informatif et ne constituent ni un conseil en investissement ni une recommandation d’achat ou de vente de titres
Expérience de densité d’interface, de Grid à Matrix
- Grid est un projet expérimental sur une densité d’interface personnalisable, et une nouvelle version est en cours de développement
- Matrix est une expérience qui pousse encore plus loin la densité de l’interface et propose une matrice de corrélation à grande échelle du S&P 500 et du NASDAQ-100
- Il est possible d’apercevoir une partie de Matrix dans l’aperçu du bas, mais certaines fonctionnalités ne sont disponibles que dans l’interface plein écran de Matrix
Taille des données traitées par Matrix
- En choisissant les titres du S&P 500 comme jeu de données, on obtient plus de 2500 cellules
- Les corrélations de plus de 3000 points de données sont calculées
- Des informations supplémentaires sont disponibles sur la page About de l’expérience Matrix
- La page home donne un aperçu de toutes les expériences de visualisation de données actuellement proposées
Éléments de contrôle visibles dans l’aperçu
- Les options de Dataset sont S&P500 et NASDAQ100
- Pour Horizon, il est possible de choisir 1M et 1Y
- Une case à cocher Detrend Data est proposée comme option de prétraitement des données
- Les options de tri sont les suivantes
- Sort By: Cluster, AvgCorr, MedCorr, Name
- Cluster Method: Avg, Complete, Ward
- Sort Direction: Asc, Desc
- L’interface d’aperçu comprend Minimap, Search, Rolling Correlation Chart, ainsi que des indications sur le hover et le click des cellules
- Dans l’état affiché, les valeurs indiquées sont : Symbols 101, Correlations 5,050, Cells 10,201
Points à garder à l’esprit lors de l’utilisation
- Les contenus du site sont fournis à titre informatif et ne constituent ni un conseil en investissement ni une recommandation d’achat ou de vente de titres
1 commentaires
Avis sur Hacker News
En ce moment, j’expérimente entre tri et affichage. Si un ticket importé de Jira est bloqué, je me demande s’il faut une colonne booléenne séparée pour le tri/filtrage, ou si appliquer simplement un style à une autre colonne (par exemple le temps écoulé) suffit. Dans un tableau de plus de 100 lignes, j’essaie de voir si une valeur orange, rouge ou rouge en gras dans une cellule permet à elle seule d’identifier les éléments à traiter maintenant.
Ce que j’aime dans la vue tableau de cette expérience, c’est l’actualisation en temps réel, le tri stable sur plusieurs colonnes, la mise en évidence des lignes au survol, les zéros finaux atténués, les couleurs mesurées (en gros trois paires), et les graphiques de type sparkline dans les colonnes 24H Low/High. Ce que je regrette, c’est la barre de défilement horizontale à peine visible, la large barre de défilement verticale accompagnée d’un graphique, le fait qu’on ne sache pas clairement comment 24H Low/High est réellement trié, et l’absence de filtrage. Je remarque aussi que, par rapport à mes rapports, la largeur des valeurs varie assez peu. Quand du texte se mêle aux chiffres, la gestion de la largeur des colonnes devient plus difficile.
L’hélice me semble difficile à lire et peu utile. Ce type de graphique convient mieux à des données périodiques dont la période est bien plus courte que l’ensemble de la plage de données.
Le cube a éveillé ma curiosité, mais je n’en ai pas vraiment vu l’intérêt. En général, une visualisation 3D est moins efficace que trois graphiques 2D montrant la même chose (ici, trois nuages de points). La projection de la 3D vers la 2D introduit des distorsions, et notre perception de base des comparaisons de position s’en trouve brouillée. Je me demande quel était l’effet recherché ici.
La manière de regarder le passé aussi naturellement que possible tout en affichant les données récentes en plus grand est vraiment géniale. J’ai du mal à croire que je n’y aie jamais pensé.
Depuis « Material Design », que Google a pratiquement enterré, il y a eu beaucoup trop de lourdeur, d’espaces blancs, d’espacements excessifs et de gaspillage façon “aération”.
On peut toujours rêver.
Les entreprises n’ont pas envie de concevoir deux UI très différentes selon les plateformes, et les utilisateurs veulent généralement que les usages appris sur une plateforme se retrouvent sur une autre.
L’accessibilité est aussi plus simple quand le design laisse de la place à de grandes polices et n’exige pas une motricité fine très précise. En voyant mon père vieillir visiblement, je me rends compte que même les apps que je trouve spacieuses ne le sont pas forcément assez de ce point de vue.
Tant que les forces qui nous ont poussés dans cette direction au départ ne changent pas, je ne vois pas bien comment revenir à des designs à forte densité d’information.
Ces écrans utilisent une police à chasse fixe d’une seule taille. C’est rétro, comme les UI en mode texte des années 1980, et si c’était la contrainte voulue, très bien.
Mais si l’on peut établir une vraie hiérarchie de polices et de tailles, on peut mettre beaucoup plus d’informations à l’écran.
Exemple simple : la boîte “About” occupe actuellement près d’un quart de l’écran du téléphone. En passant à une police proportionnelle plus petite, on pourrait afficher cette information dans deux fois moins d’espace tout en restant lisible sur téléphone.
Quand on regarde le travail de grands designers de l’information comme Edward Tufte, on voit qu’ils sont souvent obsédés par le réglage fin de la typographie. Ses livres utilisent plusieurs éléments typographiques et plusieurs échelles, y compris pour le texte courant en dehors des visualisations.
Je me demande si l’accent porte sur la performance, la visualisation, ou sur la densité liée à autre chose.
On sent clairement une forte influence.
Les tentatives de créer une UI similaire avec React ont plutôt échoué à cause de mauvaises performances. Pour obtenir des performances de rendu acceptables, le tableau de données contournait complètement React. Malgré tout, pour éviter que le rendu du navigateur lui-même ne devienne insupportablement lent, il fallait minimiser le nombre d’éléments DOM par ligne.
WinForms reste probablement mon framework d’UI préféré. C’est clairement un outil rustique, mais on peut le manier comme on veut. Il est extrêmement flexible, assez facile à utiliser, plutôt rapide, et atrocement laid.
On peut lui jeter n’importe quel Object et ça fonctionne. On peut imbriquer des PropertyGrid dans des PropertyGrid, les étendre avec des collections d’objets, et imbriquer des contrôles à la profondeur voulue. Pas besoin de toucher à la structure interne des objets auxquels l’UI est liée, ni même de s’en soucier (dans certaines limites).
Pour moi, WinForms est l’idéal platonicien du framework d’UI. Si je devais en concevoir un, je le ferais exactement comme ça.
J’aime vraiment la densité d’information.
Je collectionne les vieux journaux, et à l’époque la densité d’information était bien plus élevée. Si vous cherchez un beau livre à poser sur une table basse, recherchez « nytimes complete front pages ». Il y avait vraiment énormément d’informations essentielles au-dessus de la ligne de pli.
Je considère qu’une forte densité d’information équivaut à une grande intelligence. Savoir définir correctement les priorités de tri est très précieux et important.
Ces dernières années, le Web semblait aller dans la direction opposée, donc je suis content de voir qu’il y a encore des gens qui rament à contre-courant.
Autre exemple : mon blog est conçu pour permettre de voir environ 20 ans d’articles d’un coup grâce au zoom/dézoom (https://breckyunits.com/).
Je vais aussi bientôt publier un travail visant à promouvoir les antisèches à forte densité d’information et à en faciliter la création. Je pense arrêter le nom Leet Sheet (https://pldb.io/blog/leetSheets.html).
C’est intéressant parce que cela prouve quelque chose sur ma vision et ma compréhension visuelle.
La vue « Grid » me convient parfaitement. La vue « Table » est inutilisable.
J’ai souvent du mal à ne pas perdre la ligne sur laquelle je me trouve quand je parcours de longues lignes comme ça. J’ai compris que c’était lié à une légère tendance de l’œil dominant à se déplacer vers la droite quand mon regard se déplace. L’alignement de mes deux yeux est subtilement décalé et je porte une correction prismatique ; un changement récent de cette correction a amélioré la situation.
Dans cette représentation, la position des repères visuels des colonnes low/high aggrave les changements de ligne accidentels (qui se produisent toujours vers le haut).
Pour moi, il vaudrait mieux que le graphique en ligne soit l’arrière-plan de la cellule, ou placé en bas de la cellule. Les lignes auraient aussi besoin d’un zébrage discret.
La leçon que j’en tire, en tant que lecteur rapide et expérimenté, sans handicap visuel ou cognitif, est qu’il ne faut pas supposer qu’on peut répartir l’information sur une grande largeur dans ce type de tableau sans problème. Il faut fournir à l’utilisateur des indices pour garder le fil de la ligne pendant qu’il la parcourt horizontalement. De fines lignes de séparation ne suffisent pas, et le changement de fond au survol de la souris n’est pas utilisable sur les appareils tactiles.
Dans l’état actuel, quand je tombe sur ce genre de chose, je désagrandis la fenêtre et réduis sa hauteur pour faire défiler, en utilisant le bas de la fenêtre ou la barre de titre d’une autre fenêtre comme « bord » constant pour lire les données. Sur iPad, il m’est déjà arrivé d’utiliser une feuille de papier ou une carte.
Premièrement, comme mentionné, le contraste entre une ligne survolée ou mise en évidence et les autres lignes est trop faible. Même avec une bonne vue, j’ai du mal à le distinguer.
Deuxièmement, pour la lisibilité, les lignes ou les colonnes d’un tableau devraient être zébrées avec au moins deux couleurs à fort contraste. Par exemple blanc, noir, blanc, noir. Ici, le tableau est noir du début à la fin.
Troisièmement, le contraste des bordures du tableau est si faible qu’elles sont presque invisibles. Combiné à la couleur unique des lignes/colonnes, cela dégrade encore la lisibilité.
En résumé, le tableau lui-même est correct, les couleurs sont catastrophiques.
Les éléments d’UI ici ont l’air très réussis, mais je me demande aussi quelle était l’expérience et quelles conclusions en ont été tirées.
Si l’on se limite au nombre brut d’éléments interactifs, d’après mon expérience (Svelte 4), le rendu pose souvent problème avant l’interaction. Autrement dit, les problèmes de performances apparaissent avec le même nombre d’éléments, qu’ils soient interactifs ou non. Comme cela a été implémenté sur certaines parties de cette page, la solution est de passer au canvas.
Svelte peut aussi dessiner sur un canvas. Il y a aussi Threlte : https://threlte.xyz/
En ce qui concerne les performances internes de Svelte, je ne pense pas qu’il ait autant besoin que React de quelque chose comme Jotai pour éviter les re-rendus inutiles.
Associer Svelte à un excellent framework WebGL comme Phaser permet un rendu graphique très rapide : https://phaser.io/news/2024/03/official-phaser-3-and-svelte-...
Ce graphique en hélice est vraiment séduisant. Je ne sais pas trop s’il est réellement exploitable, mais visuellement, c’est super impressionnant
Si c’était une expérimentation, quelle en a été la conclusion ?