Svelteで作られたUI密度の実験

(cybernetic.dev)

1 ポイント投稿者 GN⁺ 2024-07-28 | 1件のコメント | WhatsAppで共有

Grid は、ユーザーがUI密度を調整して試せる実験で、現在新バージョンを制作中
続編的な位置づけの Matrix は、より高いUI密度を目指し、S&P 500 と NASDAQ-100 の相関行列を表示
S&P500 構成銘柄を選択すると、25万以上のセル と 3,000万以上のデータポイント の相関関係を扱う
一部機能は下部プレビューには含まれておらず、確認するには Matrix の全画面UI を開く必要がある
サイト上の資料は情報提供のみを目的としており、投資助言や証券の売買推奨とみなすことはできない

GridからMatrixへ続くUI密度の実験

Grid はカスタマイズ可能なUI密度を試すプロジェクトで、新バージョンを制作中
Matrix はUI密度をさらに押し広げる実験で、大規模な S&P 500 および NASDAQ-100 の 相関行列 を提供
下部プレビューで Matrix の一部を確認できるが、いくつかの機能は Matrix の全画面UIでのみ利用可能

Matrixが扱うデータ規模

S&P500 構成銘柄をデータセットとして選ぶと、250,000以上のセル を含む
- 30,000,000以上のデータポイント の相関関係を計算
- Matrix 実験の About ページで追加情報を確認できる
home ページでは、現在提供されているすべての データ可視化実験 の概要を確認できる

プレビューで確認できる操作要素

Dataset の選択項目として S&P500 と NASDAQ100 がある
Horizon は 1M と 1Y を選択可能
データ前処理オプションとして Detrend Data チェックボックスがある
並び替え関連のオプションは次のとおり
- Sort By: Cluster, AvgCorr, MedCorr, Name
- Cluster Method: Avg, Complete, Ward
- Sort Direction: Asc, Desc
プレビューUIには Minimap、Search、Rolling Correlation Chart、セルの hover および click の案内が含まれる
表示された状態では、Symbols 101、Correlations 5,050、Cells 10,201 と示される

利用時の注意点

ウェブサイト上の資料は 情報提供目的 であり、投資助言や証券の売買推奨ではない

1件のコメント

GN⁺ 2024-07-28

Hacker News の意見

表形式のデータを多く扱うので、1画面にできるだけ多く表示されるものを好む。レポート設計に最も大きな影響を与えたのは、意外にも iTunes だった。必要な分だけの余白、縞模様の行、高速で簡単なソート、可能ならカラムブラウザのような構造。DataTablesを何年も満足して使っている
最近は ソートと表示 の間を実験している。Jiraから取得した課題がブロックされている場合、ソート/フィルタ用の別のブール列が必要なのか、それとも別の列（例：経過時間）にスタイルを付けるだけで十分なのかを考えている。100行を超える表で、あるセルのオレンジ、赤、太字の赤の値だけで、今対応すべき項目を見分けられるかを見ているところ
この実験の表ビューで気に入っているのは、リアルタイム更新、複数列に対する安定ソート、マウスオーバー時の行ハイライト、末尾の0を薄く表示する処理、やりすぎない色使い（基本的に3ペア程度）、24H Low/High列のスパークラインのようなグラフ。残念なのは、ほとんど見えない横スクロールバー、グラフが付いた幅広い縦スクロールバー、24H Low/Highが実際にどうソートされるのか不明確な点、フィルタリングがないこと。また、自分のレポートと比べると値の幅のばらつきが大きくないことも分かる。数字中心よりテキストが混じると、列幅の管理はさらに難しくなる
- Catalinaにアップグレードすると iTunes.app がなくなるのではと思って先延ばしにしていた記憶がある。完全に過小評価されていたアプリで、Music.appがほぼ同じアプリであり、移行も簡単だったので本当にうれしかった
- DataTables は素晴らしい。ある製品で10年以上使っている。もっと新しくて良い代替品をずっと探しているが、まだ見つかっていない
- Jiraや非同期に進む他の業務と連携する Macアプリ開発 も実験中。データ表示そのものより、何をいつ通知してもらうかのコントロールに関心があったが、このコメントとUIを見て、メインのデータ画面で行き詰まっていた別のアイデアを試してみたくなった
- 大きさを色で表す 条件付き書式 のことを言っているのかな？
表のスクロールバーをコードエディタのミニマップのように拡張して、追加情報を載せるやり方はかなり気に入った。ひと目で、画面上のデータがより大きなデータセットの中でどのあたりにあるのか把握する助けになる
ヘリックス は読みにくく、有用ではないように感じる。こうしたグラフは、周期がデータ全体の範囲よりはるかに短い周期的データにより向いている
キューブは興味を引いたが、利点はよく分からなかった。通常、3D可視化は同じ内容を3つの2Dグラフ（ここでは3つの散布図）で見せるより効果が低い。3Dから2Dへ投影されることで歪みが生じ、位置比較に対する人間の基本的な感覚も乱れるためだ。ここで意図していた効果が何だったのか気になる
- はっきりさせておくと、この美しいプロジェクトの作者ではない
- 実は ヘリックスタブ があまりにすごくて、その話をしに来た。たとえば株式や他の商品、特にデリバティブのボラティリティを描くのに使えそうだ
  過去をできるだけ自然にのぞき込みながら、直近のデータはより大きく見えるようにした方法が本当に天才的だ。なぜ今までこう考えなかったのか信じがたいほど
こういうプロジェクトが、よく設計されつつも 情報密度 が高く、空間を節約するインターフェースへ戻る兆しであってほしい
Googleが事実上葬った「Material Design」以降、肥大化、白い余白、過剰な間隔、「空気感」のような無駄があまりにひどかった
夢を見るくらいはできる
- モバイルではタッチ対象が指の大きさである必要があるため、ある程度ゆったりしたUIが必要になる
  企業はプラットフォームごとに大きく異なるUIを2つ設計したがらず、一般にユーザーも、あるプラットフォームで覚えた使い方が別のプラットフォームでも通用することを望む
  アクセシビリティも、デザインに大きなフォントのための余裕があり、精密な運動制御を求めないときのほうが容易になる。父が目に見えて年を取っていくのを見ながら、広いと感じるアプリでさえ、この観点では十分ではないのだと気づいている
  そもそも私たちをその方向へ押しやった力が変わらない限り、どうやって情報密度の高いデザインへ戻れるのか、よく分からない
- starting with (now Google-dead) "Material Design"
  まだ活発に開発中だと思っていた。Googleがこれを殺したという意味なのか？
  https://m3.material.io/
- OS 9からOS Xへ移行するときに Apple から始まったように思う。当時は説明できなかったが、高価な画面スペースがあまりにも多く無駄にされているのが、今でも残念に感じる
この実験には、UI密度を設計する際の重要要素である タイポグラフィ が欠けていると思う
これらの画面は単一サイズの等幅フォントを使っている。1980年代のテキストモードUIのようなレトロ風で、それが意図した制約だったなら問題ない
しかし書体とサイズにきちんとした階層を付けられるなら、はるかに多くの情報を画面に入れられる
基本的な例として、「About」ボックスはいま携帯電話画面のほぼ1/4を占めている。より小さなプロポーショナルフォントに変えれば、携帯電話でも読めるまま、この情報を半分のスペースに収められる
Edward Tufteのような優れた情報デザイナーの仕事を見ると、タイポグラフィをきちんと合わせることに執着している場合が多い。彼の本は、可視化以外の本文テキストにも複数のタイポグラフィ要素とスケールを使っている
- このテーマでおすすめできる Edward Tufte の具体的な著作はある？
正確な比較対象として Perspective のようなものを挙げられるだろうか？（https://perspective.finos.org/)
焦点が性能、可視化、それとも別のものに関係する密度なのか気になる
- 元記事のサイトより読み込みがかなり遅かった。ちなみに元記事の ヘリックスタブ は本当に驚きだった
- 最初に開いたときは Perspective で作られたものだと思った
  確かに大きな影響を受けている感じがする
Windows Formsでデータ量の多い金融アプリを作るときに特に気に入っているのは DataGridView コントロール。フィルタリング、ソート、ドラッグ＆ドロップによる列の並べ替え/サイズ変更を備えつつ、密度と性能が高い。ページネーションも不要。10,000行を入れたければ、そのまま入れればいい。私たちが作るUIのほとんどはDataGridViewパネルで埋まった画面だ。見た目は悪いか？そうだ。速いか？それもそうだ

Reactで似たようなUIを作ろうとした試みは、性能が良くなく、おおむね失敗した。許容できるレンダリング性能を得るために、データ表ではReactを完全に迂回した。それでもブラウザのレンダリング自体が耐えられないほど遅くならないようにするには、行ごとのDOM要素数を最小限に抑える必要がある

WinFormsは今でも、おそらくいちばん好きなUIフレームワークだ。確かに鈍重な道具ではあるが、思う存分振り回せる。ものすごく柔軟で、かなり使いやすく、相当速く、ひどく不格好だ
任意のObjectを放り込んでも、そのまま動く。PropertyGridの中にPropertyGridをネストし、オブジェクトのコレクションへ拡張し、コントロールを望む深さまで入れ子にして作れる。UIが接続されるオブジェクトの内部構造をいじったり気にしたりしなくていい（限界はあるが）
WinFormsは自分にとってUIフレームワークのプラトン的理想形だ。自分が設計しても、まさにこう作ると思う
情報密度が本当に好きだ
古い新聞を収集しているが、当時は情報密度がずっと高かった。良いコーヒーテーブルブックを探しているなら「nytimes complete front pages」で検索してみてほしい。折り目より上の面に、本当に多くの核心情報が載っていた
高い情報密度は高い知性に等しいと思う。並べ替えの優先順位をきちんと決めることは非常に価値があり重要だ
ここ数年、Webは逆方向へ進んでいるように見えたが、それでも反対側へ漕いでいる人たちが見えるのはうれしい
別の例として、自分のブログはズームイン／アウトによって約20年分の記事を一度に見られるように設計している（[https://breckyunits.com/](https://breckyunits.com/））
また、情報密度の高いチートシートを広め、より簡単に作れるようにする取り組みも近く公開する予定だ。名前はLeet Sheetで固めようと思っている（[https://pldb.io/blog/leetSheets.html](https://pldb.io/blog/leetSheets.html））
- I think high information density === high intelligence.
  小さなフォントや小さな余白などで画面に多くのものを一度に詰め込むと、知的な人にとってもアクセシビリティの問題が多く生じる
  Googleのような企業が余白やパディングを増やしているのは、より多くの人にUIを利用しやすくするためだ。視力だけの問題ではなく、パーキンソン病のように小さな対象を正確にクリック／タップしにくい身体的な問題もあるし、画面にあまりに多くのテキストや要素が同時にあると、その量だけで方向感覚を失うことがある神経多様性の問題もある（例：てんかん）
  非常に知的であっても、よく設計されアクセシブルなUIの助けを受けられる。そうした助けを必要とする人たちが知的でないと仮定してはいけない
これは自分の視覚と視覚的理解について何かを証明してくれるので興味深い
「Grid」ビューはまったく問題ない。「Table」ビューは使えない
こういうふうに長い行を横切って読み取るとき、自分がどの行にいるのか見失うことが多い。視線が移動するときに、右方向へわずかに優位眼が移動する傾向が原因だと気づいた。両眼のアライメントが微妙にずれていてプリズム補正を受けており、最近のプリズム補正の変更でこの状況は改善した
この表現では、low/high列の表示線の位置が、偶発的な行移動（常に上方向に起きる）をさらに悪化させる
自分には、折れ線グラフがセルの背景にあるか、セルの下側にあるほうがよさそうだ。行には控えめな縞模様も必要だ
素早く熟練した読み手で、視覚または認知の障害がない立場から得た教訓は、こうした表で幅の広い行を横切って情報を置いても大丈夫だと仮定してはいけない、ということだ。ユーザーが横方向に目で追う間、行をつかまえておく手がかりを提供する必要がある。細い区切り線だけでは不十分で、マウスオーバー時の背景変更はタッチデバイスでは使えない
今の状態なら、こういうものに出くわしたときはウィンドウを最大化解除してウィンドウの高さを縮め、スクロールしながらウィンドウ下端や別ウィンドウのタイトルバーを一貫した「端」として使ってデータを見ることになる。iPadを使うときは紙やカードを使ったこともある
- 表で感じる困難は、作者のデザイン、とくに色の選択とはるかに関係がありそうだ
  第一に、述べられているように、マウスを載せた行や強調表示された行と、そうでない行とのコントラストが低すぎる。視力に問題のない自分でも見づらい
  第二に、可読性のために表の行や列は、2つ以上の高コントラスト色で縞模様にするべきだ。たとえば白、黒、白、黒のように。この表は最初から最後まで全部黒い
  第三に、表の罫線のコントラストが低すぎてほとんど見えない。単一の行／列色と組み合わさって、可読性をさらに下げている
  要約すると、表そのものは問題なく、色がひどい
ここのUI要素はとても格好よく見えるが、実験が何で、どんな結論を得たのかも気になる
純粋なインタラクティブ要素の数だけで見ると、自分の経験上（Svelte 4）、インタラクションよりレンダリングのほうが先に問題を起こすことが多い。つまり、要素がインタラクティブかどうかにかかわらず、同じ数の要素で性能問題が生じる。このページの一部で実装されているように、解決策はcanvasへ行くことだ
- Svelteはレンダリングしないコンポーネントと一緒に使える。https://imfeld.dev/writing/svelte_domless_components
  Svelteはcanvasにも描画できる。Threlteもある：https://threlte.xyz/
  Svelte内部の性能に関しては、不要な再レンダリングを防ぐためにReactほどJotaiのようなものが必要だとは思わない
- you run into performance problems at the same number of elements regardless of whether they're interactive. As you implemented for the some of these pages, the solution is to go to a canvas.
  意外だ。Svelteの利点は、コンパイル段階と仮想DOMがないことによって、非常に精密で効率的なDOM更新を行う点だと思っていた。そういうパラダイムでも、単純な大きな表はまだ問題になるのか？ここの要素のうち、たとえばどれがDOMでレンダリングすることもできたが、純粋に性能のためにcanvasが必要だったのか？
Svelte を Phaser のような優れた WebGL フレームワークと組み合わせると、非常に高速なグラフィックレンダリングが可能になる: https://phaser.io/news/2024/03/official-phaser-3-and-svelte-...
あの ヘリックスチャート は本当に魅力的。実際に使えるかどうかはよく分からないが、見た目はものすごくかっこいい
これが実験だとしたら、結論は何だったのだろうか？
- Firefox では動作していないように見えるけど、自分だけ？