※本記事は、Dominik Moritz氏によるスタンフォード大学HCIセミナー「Build Less, Design More (Interactive Systems)」の内容を基に作成されています。オリジナルの動画は https://www.youtube.com/watch?v=6DIIkX19ihs でご覧いただけます。本記事では、講演の内容を詳細に記述しておりますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご覧いただくことをお勧めいたします。
登壇者について： Dominik Moritz氏は、カーネギーメロン大学ヒューマンコンピュータインタラクション研究所の教員であり、Data Interaction Group（https://dig.cmu.edu/ ）を共同で指揮しています。彼の研究グループは、誰もが効果的にデータを分析し伝達できるようにするインタラクティブシステムを開発しています。また、AppleのML（機械学習）組織において可視化チームのマネージャーも務めています。彼が開発したシステム（Vega-Lite、Falcon、Draco、Voyagerなど）は、学術会議（IEEE VISやCHIなど）で受賞し、産業界やPython・JavaScriptデータサイエンスコミュニティで広く使用されています。Dominik氏はワシントン大学Paul G. Allen Schoolで博士号を取得し、Jeff Heer氏とBill Howe氏の指導を受けました。
Stanford CS547 Human-Computer Interaction Seminarの詳細については、https://hci.stanford.edu/seminar/ をご参照ください。
1. イントロダクションとHCI研究の加速に向けた提案
1.1 発表者の背景と「Build less, design more」の主張
Dominic： 皆さん、こんにちは。私はDominicと申します。今日は「Build less, design more」というテーマでお話しします。私がここで主張したいのは、HCI研究者として、一回限りのツールを構築することよりも、APIの設計やシステムがどのように協調して動作するかに、もっと投資すべきだということです。ある意味で、これは挑発的な主張です。しかし私は、設計について、そしてインターフェースの設計やソフトウェアがどのように連携するかについて、より深く考えることで、実際にはより多くのものを構築できると考えています。
まず自己紹介から始めましょう。私はカーネギーメロン大学の教員で、Data Interaction Groupを共同で指揮しています。同時にAppleの研究マネージャーでもあります。全般的には、可視化と機械学習のためのインタラクティブなツールを構築しています。この3日間、友人たちとヨセミテで過ごしてきました。湖の上で一晩過ごしたのですが、本当に素晴らしい体験でした。
CMUで私たちが取り組んできた仕事について少しお話しします。今日ここで紹介する研究は、私一人のものではありません。素晴らしい仲間たちとのグループワークです。私たちはデータプロファイリング、可視化の作成のためのインタラクティブなツールに取り組んできました。特にMosaicという、チャートを構築しバックエンドと調整するフレームワークについてお見せします。VegaやAltairといった可視化システムや言語についてもお話しします。Vegaについて聞いたことがある方はいますか？良いですね、部屋の半分ほどの方が手を挙げてくださいました。これらについて少し説明します。なぜなら、これが私がお話しする内容の文脈を提供するからです。
さらに、アクセシブルな可視化、可視化レコメンデーション、スケーラブルな可視化、そしてより広範なデータツーリングにも取り組んでいます。AppleのML Visualizationチームでは、Swift Chartsというライブラリを設計・構築してきました。これはAppleプラットフォーム、つまりApple WatchやiPad、iPhoneなどでチャートを作成するためのライブラリです。このチャーティングフレームワークから出力されるすべてのものが、デフォルトでアクセシブルになるよう取り組んできました。また、Apple Foundation Modelsにも取り組み、可視化を埋め込む作業をしてきました。一般的には、Michelleのような素晴らしいインターンと一緒にAIポリシーに取り組んでいます。
KaiでのAIのためのデータ拡張に関する論文も発表したばかりです。機械学習のためのツーリング以外にも、外部の可視化記事にも取り組んできました。例えば、月経周期の長さの変動性に関する記事です。人々が月経に関する情報を記録できるアプリに関する研究があり、ハーバードと協力してこのデータセットを探索できる記事を作成しました。ぜひ一度ご覧になることをお勧めします。繰り返しになりますが、今日認めたい多くの人々が関わっています。
今日、私は新しいことに挑戦しています。これは初めて行うこの講演で、ここで少し議論を展開しようとしています。私たちはヒューマンコンピュータインタラクション研究の科学を加速できると考えています。ですから、この講演には少しspicyな見解が含まれているかもしれません。皆さんには、私と議論し、異論を唱えていただきたいと思います。議論のために詳細を省略する部分もありますので、どうかご容赦ください。しかし、HCI研究をどのように加速できるかという点について考えを深められると思います。
1.2 HCI研究を科学として捉える視点
Dominic： まず、ヒューマンコンピュータインタラクション研究を科学として考えることから始めましょう。ここでは科学という言葉を最も厳密な意味で使います。科学とは、何らかの仮説を立て、その仮説のための実験を設計し、その仮説を評価することを意味します。実験を行うことで、仮説が検証されるか、あるいはまだ結論が出ないかのいずれかになります。このプロセスを正しく行えば、知識、つまり情報を創出し、何かを学びます。そしてそれが新しい仮説を立てることを可能にします。
通常、洞察を得ると、そこからさらに多くの仮説が生まれます。これはある意味で指数関数的に広がっていきます。ですから、私たちの知識は決して完全になることはありません。しかし、この科学的手法こそが、私たちが知識を得るのを助けるものです。そして私たちの全体的な目標は、より多くの知識を創出し、より速くそれを行うことです。つまり、仮説から実験、評価、そして仮説へと戻るこのループを加速させるべきなのです。
では、HCIにおいてどのようにそれを実現するのでしょうか。HCIは、世界について何かを実験し理解するという伝統的な科学と、新しいものを創造するデザインとが混在している分野です。HCI研究のこれら二つの領域について考えてみましょう。一つは、人々がコンピュータをどのように使用するか、ソフトウェアが社会にどのように影響するかを研究する領域です。もう一方は、新しいツールの設計を仮説立て、おそらくテストする領域です。
後者にはより多くのデザインが含まれています。そして後者で私たちが行っているのは、何らかの仮説をテストするための新しいアーティファクトを開発することです。私はこの後者の側面に焦点を当てたいと思います。これがHCI研究の簡略化された見方であることは承知していますが、有用だと考えています。
後者に焦点を当てるのは、ここが最も多くのソフトウェアが構築されている場所だと思うからです。ここが本当に、私がツール駆動型HCI研究と呼ぶものの大部分が存在する場所です。ここでは、仮説をテストするために構築したかもしれないソフトウェアを作ります。つまり、何らかのツールを作成し、それをユーザースタディで実行できるようにして、そこから何かを学びます。これが科学のループを回すことを可能にします。
1.3 一回限りのツール vs 基盤・フレームワーク
Dominic： しかし、私たちがそこで構築しているツールは、多くの場合一回限りのものです。運が良ければ、GitHubのリポジトリにオープンソースとして公開されます。そして、もしかしたら人々に採用されるかもしれません。しかし通常、実際にそのソフトウェアを使用する人の数は少ないのが現実です。
一方で、私たちには基盤とフレームワークがあります。ここでは、組み合わせ可能なソフトウェアを構築しています。これにより、より多くのツールを構築でき、おそらくそれをより速く行うことができます。
私がこの講演で主張したいのは、実験を行うために一回限りのツールを構築する場合でも、基盤やフレームワークについてもっと考えるべきだということです。なぜなら、それは長期的には私たち全員にとって、より速い科学を行うために報われると考えるからです。そして、このフレームワーク研究自体も、科学的な取り組みだと思います。つまり、ツールをどのように構築できるかについての仮説をテストしているのです。依然として強力なデザインの実践ですが、科学でもあるのです。
では、どのようにしてそれを実現するのでしょうか。これらの基盤とフレームワークをどのように構築するのでしょうか。それを実現するためのレシピは何でしょうか。
2. 組み合わせ可能なソフトウェアの原理
2.1 Tukeyの洞察と組み合わせの数学
Dominic： 最初のレシピは、組み合わせ可能なソフトウェアを構築することだと思います。ここで、Tukeyの引用に戻りたいと思います。彼は1965年に「Data Analysis and Statistics」という論文でこう書いています。「今日の最初の課題は、全く新しいグラフィック技術を発明することではない。もちろん、それらも必要だが、最も重要なのは、古い技術の本質を認識し再構成すること、新しい方法で組み立てを容易にすること、そして新しい機会に合わせて外見を修正することである」と。
この論文は素晴らしい引用に満ちていますが、私はこの一節を取り上げたいと思います。なぜなら、これは可視化について語っていますが、本当に重要なのは、それ自体では必ずしも新規性がないように見えるコンポーネントから多くのものを構築できることを強調しているからです。しかし、そこから多くの新規性が生まれ得るのです。
数学的な公式として表現するなら、このようになるでしょう。個々のコンポーネントN、M、Oがあり、それらを組み合わせることで、構築可能なものの指数関数的な空間、組み合わせ空間を創出します。
2.2 Vega-Liteの成功事例
Dominic： この具体例がVega-Liteです。Vega-Liteでは、ここにあるような単純なドットから始めて、原子的な修正を加えることで大きな設計空間を探索できます。Vega-Liteは主にマークとエンコーディングに基づいて構築されています。これらは、レゴのピースやパズルのピースのように組み合わせて、より大きなもの、つまり可能な可視化の大きな設計空間を創出する構成要素なのです。
しかし、このような組み合わせを可能にする言語を構築することは、多くの時間と多くの議論を必要とします。これは、伝統的には研究者がすべきことだとは思われていなかったかもしれません。しかし、私はそこに大きな価値があると主張します。
特にVega-Liteの場合、言語の細かい詳細について、20以上のコメントがつくような多くの議論を重ねてきました。しかし、Vega-Liteは現在ほぼ10年の歴史があります。CDN上で月間約300万回のダウンロードがあります。それを使用し、それを中心に構築されているスタートアップが多数あり、それを使用している大企業もあります。ですから、その多くの作業は報われたと思います。
Leon Wilkinsonは、Grammar of Graphicsの著者で、可視化をどのように考えるかについての数学的視点からの本を書いた人物ですが、実際にVega-Liteについてコメントしています。彼は言いました。「Grammar of Graphicsにインスパイアされた多くのシステムを経験してきたが、あなたのシステムが最も本格的な実装だと信じている。私は毎日これを使っている」と。円グラフに関する私たちのGitHubディスカッションの一つに彼が参加してくれたのは、非常にクールでした。
Altairチームも、Vega-Liteについて興奮しており、それをAltair自体よりもはるかに大きな取り組みの一部として見ています。VegaとVega-Liteの仕様は、おそらくデータ可視化の原理的な共通語として、現存する最良の候補です。
つまり、ここでソフトウェアは、単に物を構築するためのツールとしてだけでなく、設計空間について考える方法としても機能しているのです。
2.3 Vega-Liteの限界
Dominic： さて、私はここでVega-Liteを大いに称賛しましたが、長年にわたって気づいた大きな制限があると思います。それは、Vega-Liteが凡例、エンコーディング、軸などの異なるコンポーネントをすべて組み合わせて可視化を作成しますが、エコシステムの他の部分とうまく相互運用できないということです。
Reactのようなものと統合することは困難です。インタラクションのためのセレクションがReactとうまく機能しません。D3やSvelte、アプリケーションコード、バックエンドと一緒に使用することも困難です。ですから、良いフレームワークや、HCIを本当に加速させるような良いツールを作るためには、単なる組み合わせを超えて、さらに一歩進む必要があります。それが相互運用可能にすることです。
相互運用可能とは、自分のソフトウェアだけでなく、他の人々のソフトウェアとも連携することを意味します。そして、それは構築できるものの空間をさらに大きく広げます。自分のソフトウェアをM×N×Oと考えるとき、今度はそれを他の人々のソフトウェアとその組み合わせと結合させます。すると、無限に大きな空間が得られます。
聴衆： 通常、これはバグやエラー、悪いことが起こる空間も爆発的に増やすのではないですか？
Dominic： その通りです。より大きな設計空間を創出しますが、注意深い設計を行い、相互作用点を小さく保つことが重要です。つまり、小さなインターフェースを設計するのです。本当に一つのことだけを行い、インターフェースは意図的に設計されたものであるべきです。
この講演で主張したいのは、動作とインターフェースについて考えるべきだということです。構築したものの副産物としてそれらを残すのではなく、です。ですから、時には一歩下がって、論文では「これが私たちが構築したインターフェースです。これが私たちが望んでいたものです」と、外見をどうしたいかに焦点を当て、実装はそれに従わせるべきかもしれません。
3. 相互運用可能なソフトウェアとインターフェース設計
3.1 相互運用性による設計空間の拡大
Dominic： インターフェースについてもう少しお話ししましょう。ここでHerb Simonからの引用があります。Herb Simonはカーネギーメロン大学の教員で、ノーベル賞とチューリング賞の両方を受賞した数少ない人物の一人です。彼は「The Sciences of the Artificial」という本を書きました。この本を読んだことがある方はいますか？素晴らしい本です。強くお勧めします。
この本では、基本的にコンピュータサイエンスを科学としてどのように考えられるかについて書いています。その中の一つの引用は次のようなものです。「アーティファクトは、今日の用語で言えばインターフェースである会合点として考えることができる。それは、アーティファクト自体の物質と組織である内部環境と、それが動作する周囲の環境である外部環境との間の接点である」と。
つまり、システムの動作を理解するために、内部の働きの正確な詳細を必ずしも理解する必要はないということです。しかし、私が主張するのは、その外部の動作についてもっと考えるべきだということです。「ああ、このライブラリを使ったから、システムはこのように動作する」というように、構築したものの副産物として動作を残すのではなく、動作を明確に定義し、小さく、そして相互運用可能に保つべきです。
ですから、アーティファクトをその組織と機能の観点から、内部環境と外部環境の間のこのインターフェースとして考えましょう。このようにソフトウェアを構築することには、多くの利点があります。
3.2 標準とAPIの利点
Dominic： 再利用可能なインターフェースがなければ、あるツールを何らかのシステムと相互作用させたい場合、あらゆる可能な相互作用点を実装しなければなりません。しかし、標準や標準フォーマット、インターフェースについて考えるなら、何かを互換性のあるものにするために書かなければならないグルーコードの量を、はるかに少ない行数に削減できます。右側の赤い線の数が、再利用可能なソフトウェアを使った場合にはるかに少ないことがわかります。
これらの例としては、HTTPのような標準があります。サーバーを任意の言語で書くことができ、任意のブラウザや、HTTPをサポートする任意のツールからそれと相互作用できます。これはある種魔法のようなものです。Apache Arrowは、バイナリデータ、つまりバイナリ形式の表形式データのためのものです。Language Server Protocolは、プログラミング言語とオートコンプリート、IDEのためのものです。一方にプログラミング言語があり、もう一方にエディタがあります。Language Server Protocolが定義するのは、オートコンプリートがどのように機能すべきかということです。
ですから、すべてのバックエンド、すべてのプログラミング言語がすべてのエディタをサポートする必要はありません。このLanguage Server Protocolを満たしさえすればよいのです。SQLは、データベースのためのクエリ言語です。SQLの構文は大きいと思いますが、かなり小さなインターフェースがあり、システムが協力して動作できます。他にも多くの例があります。
これらの背後にあるもの、つまりこのインターバルソフトウェアの背後にあるものは、特にこれらのインターフェース、API、つまりアプリケーションプログラミングインターフェースについて考えることです。これらを使用し、APIに焦点を当てることには多くの利点があります。
つまり、ゼロから構築するのではなく、ソフトウェアを組み合わせることができます。これは、より少ないコード、保守可能なコード、より速い科学を意味します。それは知的に挑戦的です。これらは発明と設計の活動です。そして、ある意味で、研究者が行うべきことです。
そして、ここには疑問符があるかもしれません。LLMが良くなってきているので、動作やインターフェースについて正確に指定することが、ソフトウェアを開発するために必要なすべてになるかもしれません。もうコードを書く必要がないからです。これはまだ少し疑問符がついています。仮説です。しかし、例えば、Vega-Liteはすでに多くのLLMによって使用されています。ですから、ここでの仕様には確実に価値があります。
私の呼びかけは、より相互運用可能なソフトウェアフォーマットと標準を設計することです。そして、論文は実装ではなくAPIの設計に焦点を当てるべきかもしれません。それは、設計により多くのスペースを割くことを意味するかもしれません。事後的にAPIを定義するのではなく、です。
3.3 成功事例：アクセシビリティとソフトウェア標準
Dominic： 私たちにはこれに関する素晴らしい例がいくつかあります。例えば、アクセシビリティコミュニティでは、これはソフトウェアについてでさえなく、標準についてです。Web Accessibility Guidelines（WAAG）は、アクセシビリティ研究コミュニティによって影響を受けました。多くの人が、これは研究コミュニティが行った最も影響力のあることだと言っています。
あるいは、Michaelによる論文があります。この論文では、VegaとVega-Lite、VegaとD3が、互換性のあるソフトウェアの例として取り上げられています。
さて、これが私の議論です。そして、特に相互運用可能な可視化システムのいくつかの例をお見せしたいと思います。まず、anywidgetから始めます。これは、任意のJavaScriptライブラリをPythonウィジェットにするためのツールです。次に、データベースとインタラクティブなビューをリンクするためのMosaicをお見せします。そして、これによって私たちが2つのツール、つまりEmbedding AtlasとTextureを構築できたことをお見せします。
Embedding Atlas自体は、実際には次のデータツールで組み合わせることができるコンポーネントのライブラリです。そして最後に、アクセシブルなデータナビゲーションのためのフォーマットであるData Navigatorです。しかし、ここまでのこの部分について質問はありますか？講演の最後にこれについて話したいと言っていただいても構いません。
4. anywidget：相互運用可能なウィジェット仕様
4.1 Jupyter notebooksにおける課題
Dominic： それでは、anywidgetについてお話しします。これはTrevor Manzによる研究で、私は全く関与していません。ですから、これは素晴らしい例だと思います。彼らが行ったのは、主にPythonノートブック用のJavaScriptウィジェットを構築するための仕様を構築することでした。後でこの点に戻りますが、まずこの例を見ていきましょう。
彼らが取り組もうとした問題は次のようなものです。Jupyterノートブックがあります。Jupyterノートブックを使ったことがある方はほぼ全員ですね。非常に人気があります。Jupyterノートブックが行うことは、計算が実行される何らかのカーネルと通信することです。フロントエンドには異なるバージョンがあり、バックエンドにも異なるバージョンがありますが、ここではJavaScriptとPythonのバージョンに焦点を当てましょう。
これら2つの間で実際に通信できるようにするのがJupiter widgetsです。しかし、多くのプラットフォームとの間に非常に密接な結合があり、異なるプラットフォームが実際にこれらのウィジェットの独自の実装を持っています。
ですから、ウィジェットを作りたい場合、まずJavaScriptとPythonを知っている必要があります。その両方をパッケージ化する必要があります。そして、これらのフロントエンドのいずれかと互換性を持たせたい場合、最終的にはnode、yarn、webpack、babelとパッケージング、そしてパッケージングについて学ばなければなりません。そして、異なるすべてのフロントエンドに適合するこれらのパズルピースを配送しなければなりません。
ですから、別のものがあると、これも繰り返されます。そして、それらは互換性がないかもしれません。これは機能せず、多くのバグをもたらしました。これらは、生物学者が多く働くグループで働いていたTrevorのスライドです。そこでこの問題が浮上しました。
4.2 anywidgetの解決策
Dominic： 解決策は仕様でした。それがanywidgetです。標準のESモジュールを使用しています。ESはECMAScriptの略で、これはJavaScriptの背後にある標準です。ECMAScriptという名前を聞いたことがないかもしれませんが、おそらくJavaScriptは聞いたことがあるでしょう。ほぼ同じものです。
この標準がここで定義するのは、書かなければならない言語、つまりインターフェースの一種です。そして、それは異なるフロントエンドとアダプターを通じて互換性を持たせることができるインターフェースを公開します。つまり、anywidgetアダプターがあり、ウィジェットを書くために行わなければならないのは、anywidgetプロトコルを満たすことだけです。この三角形がアダプターに適合するので、異なるすべてのフロントエンドで動作します。
素晴らしいのは、これがこれらすべてのビルドツールを学ぶ必要なく動作することです。ですから、プロトタイプから本番環境へ移行するのがはるかに高速になります。そして、ウィジェットは、私たちが行った研究の一部を、人々がJupyterノートブックで使用できる方法にパッケージ化する方法だと思います。そして、そうするためのオーバーヘッドは実際にはかなり最小限だと思います。
4.3 実装例と驚異的な普及
Dominic： 簡単な例をお見せしましょう。これは単なるPython Jupyterノートブックで、anywidgetライブラリを読み込んでいます。そして実際にできることは、ここにインラインでコードを書くことです。詳細を理解する必要はありませんが、フロントエンドとバックエンドの間で通信できるようにするカウンターを作成するために、どれだけ少ないコードで済むかを見てください。
このようにして、再びここから出ることもできます。Pythonカーネルのフロントエンドから値を取得できます。ここでは値が11です。これを増やして再度実行すると、更新された値が得られます。素晴らしいのは、これがほんの少しのコードだということです。
anywidgetはこれほど小さいので、人々はそれについて熱狂してきました。そして採用は印象的でした。anywidgetは2023年1月に登場しました。このチャートで、人々がウィジェットを作成するために何を使用したかを見ることができますが、基本的に一夜にして、誰もがanywidgetでウィジェットを作ったり、古いウィジェットをanywidgetに移植したりしました。ですから、ここで非常に成功しています。
実際には、現在、anywidgetプロトコルや仕様を直接サポートするフロントエンドがあります。さて、これは実際に再び登場します。なぜなら、私たちはこれらの他のツールのためにanywidgetを使用したからです。
4.4 研究時間投資に関する議論
聴衆： 研究者として、あなたはトレードオフに直面しています。アイデアの概念実証のようなものを作成しているわけですよね。それを埋め込み可能、組み合わせ可能などにできることは、おそらく時間的コミットメントを簡単に2倍にすることになります。基本的には、ゼロから行う場合でもです。正直に言えば、研究プロジェクトがあなた以外の人々に採用されることは稀です。もっと頻繁に起こってほしいと思いますが、ある意味で、あなたのグループ、Jeffのグループなど、例外的に本当にうまくやっているグループがあると思います。
ですから、ここで学ぼうとしているのです。なぜなら、ある意味では、多くの研究者が適応的な最良の道を選んでいるように感じるからです。それはやらないということです。なぜなら、人々が使い始めれば、いつでもそこに到達できるからです。有用な問題を解決するなら、より組み合わせ可能にする方法を見つけることができます。しかし、私たちが常にこれを行っているなら、少し野心的に物事をビジョンする能力を失っているのではないかと心配しています。そうすると、3倍の時間がかかるようになり、最終的には加速していないことになります。
Dominic： そうですね。これは、私が言っていることと、実際にどうあり得るかの間の緊張だと思います。2倍の時間ではなく、もう少し多くの時間を費やすことができると思います。
そして、フレームワークとツールに純粋に投資することで、これらの実験に取り組んでいる個々の研究者にとって、その追加作業を行うために必要な時間を削減できると思います。そして、良い例の一つは実際にanywidgetだと思います。これは私が全くやらなかった仕事です。
ですから、これは素晴らしい例だと思います。これはTrevor Manzによるもので、彼らが行ったのは、主にPythonノートブック用のJavaScriptウィジェットを構築するための仕様を構築することでした。この点に戻りますが、Jupyterでこれを機能させるためにanywidgetを使用したのは、実際には午後で構築しました。ですから、このような種類のツールを持つことは非常に価値があると思います。
5. Mosaic：データベース連携可視化フレームワーク
5.1 Mosaicの目標とアーキテクチャ
Dominic： 次に、Mosaicについてお話ししたいと思います。これは、ワシントン大学のJeff Heerらと一緒に取り組んでいる仕事です。
Mosaicは、データベースと相互運用可能な可視化とビューのためのフレームワークです。これにより、可視化とフロントエンドを構築できます。すでにPrefuse、Protovis、Vega、D3があるのに、なぜまた別の可視化ツールキットが必要なのかと思われるかもしれません。
私たちの目標は、これらのツールの多くがサポートしていたものを超えることでした。つまり、より多くの柔軟性、相互運用性、そしてスケーラビリティを持たせたかったのです。スケーラビリティとは、より最新の分析データベースを活用することで大規模なデータセットにスケールすることです。マークとセマンティクスが既知の場合にローカルで最適化し、ビューとインタラクションサイクル全体で最適化することも意味します。
より柔軟で相互運用可能な開発とデプロイメントが必要でした。自動化や最適化を自動的に適用し、異なるライブラリやプログラミング言語間でコンポーネントをリンクし、ノートブック、ローカルサーバー、Web全体にデプロイできるようにしたかったのです。
これらの課題に対する私たちの答えがMosaicです。Mosaicは、チャートやドロップダウンなどの可視化クライアントと、バッキングデータベースの間に位置します。これにより、このようなものを構築できます。これはGaia星カタログのダッシュボードです。
Gaiaは地球の周りを飛んでいる望遠鏡です。軌道上にあり、空の物体を記録しています。このカタログには約20億のオブジェクトがあります。ここでできることは、例えば、これらのオブジェクトの視差を見て、それらが空のどこに分布しているかを確認することです。
あるいは、このHertzsprung-Russell図を見ることができます。これは星の進化を示しており、これらの星がどこに分布しているかがわかります。より高い等級と低い視差を持つ星は、天の川の中心に少し多く分布していることがわかります。天の川は左上にこのようにあります。私たちは天の川の中心を見ています。
ブラウザでこの探索を可能にする方法、より大きなバックエンドと調整する方法をお見せします。Mosaicには、テーブル、ドロップダウン、回帰分析など、サポートしている多くの異なるコンポーネントがあります。空間分析もあります。これはタクシーデータで、降車地点とピックアップの相関を見ることができます。
Mosaicアプリケーションの構成、これが一般的なMosaicアーキテクチャですが、コーディネーターを通じて必要性を伝達する多くのクライアントから成ります。クライアントはそこにクエリを送信し、コーディネーターはバッキングデータベースのようなデータソースにSQLクエリを送信します。
私たちの場合、それはDuckDBで、サーバー上またはWebAssemblyで実行される可能性があります。そして、データを返します。そこでキャッシュされる可能性があり、その後クライアントで可視化できます。ですから、これはバックエンドで任意の可視化システムを構築したい場合の伝統的なパスです。ここでは効率的な転送のためにApache Arrowを使用しています。
これは標準フォーマットです。ですから、バックエンドをRust、Python、またはJavaScriptで実装できます。文字通り、私たちはこれら3つを持っています。ですから、簡単に行うことができます。
5.2 Gaia星カタログデモと基本動作
Dominic： そしてキャッシュと言いましたが、素晴らしいのは、クライアントでインタラクションをサポートしたいときに起こることです。例えば、ブラシを描くことができます。この入力がインタラクターを定義し、それがクラスを作成し、それをセレクションに結合します。そして、セレクションがpredicateを定義します。コーディネーターはこのpredicateを使用して、バックエンドに送信するクエリを更新し、それに応じてチャートを更新します。
このようにして、フィルタリングされたビューを作成できます。これは、インタラクターとpredicateを定義する複数のクライアント間でも機能します。例えば、ここでは2つのブラシがあります。一つはAからB、もう一つはUからVです。そして、セレクションでは、それが一つのpredicateに結合されます。
ですから、これが一般的なアーキテクチャです。そして、この上に、vgplotという対話的グラフィックスの文法を構築しました。様々なマークタイプをサポートしています。ここに、構築できるものの例があります。これは、ランダムに生成されたデータを示す標準的な折れ線グラフです。
このプロットは、このwalkから、エリアyチャートを定義することで作成できます。これはナイーブには、ここでxとyのデータを取得するSQLクエリを定義します。その結果、約50,000行になるので、これらすべてをレンダリングするのはかなり高コストです。
ここで自動的に適用する最適化は、M4と呼ばれるもので、実際にチャートのピクセルパーフェクトな表現をレンダリングするために必要なデータ量を約3,000行に削減しますが、データベース内でデータを削減します。そして、それが起こるので、それについて心配したり考えたりする必要さえありません。
素晴らしいのは、インタラクションを作成している場合にも機能することです。ここでは、同じチャートを2回追加しているだけです。そして、最初のチャートに適用できるブラシセレクションを定義しています。そして、そのブラシで2番目のチャートをフィルタリングしています。
これで、フォーカスとコンテキストが得られます。チャートの特定の部分を見て、その詳細を下部で確認できます。M4の最適化は、ここでのすべての更新で自動的に適用されます。ですから、これは、この可視化について知識があり、それが正確にどのようにレンダリングされるかを知っているために実行できる最適化です。
5.3 Mosaicの技術的詳細
Dominic： チャート全体にわたる最適化もあります。例えば、ここにはフライトに関するデータを示すヒストグラムがあります。遅延、フライトが開始した時刻、そして飛行距離があります。これらのチャートにセレクションを適用して、ブラシをかけられるようにします。これにより、これらの異なる次元間の相関関係を確認できます。
ここでは、私がお見せした数十億のレコードのような非常に大規模なデータセットに対してこれを行うことができます。しかし、このような高速な更新を可能にするために、ヒストグラムを計算するナイーブなことはできません。それはおおよそこのSQLクエリになるでしょう。
代わりに行うことは、ブラッシングしている次元によって追加で集約する事前集約テーブルを作成することです。それがここの黄色の部分です。そして、実際に必要なデータを、この事前集約されたデータに対するクエリとして取得できます。ですから、もう生データに行く必要はありません。これよりはるかに小さいこの事前集約データに行き、このようにしてはるかに高速な更新を得ます。
聴衆： 細かい質問です。これらのデモから判断すると、ネットワーク遅延は表示されていないと思います。これはすべてローカルクライアントで実行されているのですか？
Dominic： これらの例はローカルクライアントで実行されています。しかし、例えばこの事前集約テーブルを作成する場合、実際にクライアントにそれを置くことができれば、もうネットワーク遅延はなくなります。これはまだ実装していませんが、実装する予定です。
聴衆： つまり、原理的には、これらの種類の技術により、コンパクトな表現を配送してそのままレンダリングできると考えているのですね？
Dominic： はい。
聴衆： わかりました。事前集約テーブルを作成するのにどれくらい時間がかかりますか？明らかにデータセットのサイズに依存しますが、大まかに言って。
Dominic： 私たちはDuckDBを使用していて、1000万行以上であれば、ブラウザで簡単に処理できます。1秒未満です。
聴衆： つまり、ミリ秒単位の話ですね。
Dominic： そうです。フィルターをオンにすると。
聴衆： はい。それで更新はリアルタイムです。60フレーム毎秒が理想的です。大規模なデータセットで実際にどのように見えるかをデモでお見せします。
聴衆： これはデータがテーブル形式であるという事実に依存しているように思えます。画像のようなものだったらどうでしょうか。理論的には、ピクセル値と位置などでデータベースとして表現できますが、これを使用する前に、使用している表現をデータベースに変換する必要があるのでしょうか、それとも別の形式のデータでこれを行う方法があるのでしょうか？
Dominic： 私たちは表形式データに依存しています。それは正しいです。しかし、おっしゃったように、画像は表形式データとして表現できます。少し加工する必要があるかもしれませんし、画像データでより直接的に動作すると良いでしょう。モデルをあまり変更せずに可能であるべきだと思います。しかし、今のところ表形式データに依存しています。
5.4 インタラクション処理
Dominic： これらの透過的な最適化をここで適用でき、棒グラフ、折れ線グラフ、ヒストグラム、エラーチャート、密度プロット、六角ビンなどの様々なチャートでかなりうまく機能します。初期レンダリングと、これらのローカル最適化の一部については、実際にはほとんどの利点はDuckDBの素晴らしさと、このプリレンダリングから来ています。
研究時間の質問に戻ると、実行時間、つまりおおよそどれくらいかかるかですが、1億ポイントについて話していて、1秒未満です。数十億ポイントに達すると、少し時間がかかります。しかし、これは持っているサーバーの種類にも依存します。また、今はテラバイト単位のデータについて話しているので、ほとんどの人はそれを持っていません。
インタラクティブな更新は基本的に0.1秒以下に保たれています。ですから、データのスケールにほぼ関係なく、本当に高速です。これらの最適化を行っていない場合、Vega Fusionが示すこの線が見えるでしょう。これは指数関数的に上昇します。Vega Fusionも効率的なバックエンドを使用していますが、これらのトリックを使用していないだけです。
そして、これでMosaicを構築しました。これらはダッシュボードと呼ばれるものを構築できますが、実際にノートブックなどの他の環境にも埋め込むことができます。ここでanywidgetが登場します。実際に私が午後で構築したのは、anywidgetを使用してJupyterで動作するようにしたことです。ですから、このような種類のツールを持つことは非常に価値があると思います。
Vega-LiteやD3などの言語と統合する作業をさらに行っています。しかし、ここにデモがあります。これは、vgplotと連携するためにMosaicによって仲介されたVega-Liteです。ですから、異なるフロントエンドを使用でき、これが私が以前指摘した相互運用性であり、非常に価値があると思います。近日公開予定のPython APIもあります。うまくいけばすぐにリリースされます。
Mosaicで構築できる様々なチャートや様々なフロントエンドがあります。今はこれを飛ばしますが、すべてGitHub上でオープンソースとして公開されています。そして、実際にAppleでMosaicの上に構築したツールの一つであるEmbedding Atlasをお見せします。これはDongha Hen、Fredらとの仕事で、これもオープンソースで、論文もオンラインで公開されています。
6. vgplotと自動最適化技術
6.1 vgplotの概要
Dominic： vgplotについては、すでに少し触れましたが、これは対話的グラフィックスの文法です。様々なマークタイプをサポートしています。ここに例があります。ランダムに生成されたデータを示す標準的な折れ線グラフです。
このプロットを作成するには、このwalkから、エリアyチャートを定義すると言います。これはナイーブには、xとyのデータを取得するためのSQLクエリを定義します。その結果、約50,000行になります。ですから、これらすべてをレンダリングするのはかなり高コストです。
6.2 M4最適化
Dominic： ここで自動的に適用するのは、M4と呼ばれる最適化です。これは実際に、チャートのピクセルパーフェクトな表現をレンダリングするために必要なデータ量を約3,000行に削減します。しかし、データベース内でデータを削減するのです。
そして、これが起こります。ですから、それについて心配したり考えたりする必要さえありません。素晴らしいのは、インタラクションを作成している場合にも機能することです。ここでは、同じチャートを2回追加しているだけです。そして、最初のチャートに適用できるブラシセレクションを定義しています。そして、そのブラシで2番目のチャートをフィルタリングしています。
これで、チャートの特定の部分を見て、その詳細を下部で確認できるフォーカスとコンテキストが得られます。M4の最適化は、ここでのすべての更新で自動的に適用されます。ですから、これは、この可視化について知識があり、それが正確にどのようにレンダリングされるかを知っているために実行できる最適化です。
6.3 クロスチャート最適化
Dominic： チャート全体にわたる最適化もあります。例えば、ここにはフライトに関するデータを示すヒストグラムがあります。遅延、フライトが開始した時刻、そして飛行距離があります。再びセレクションを適用して、これらのチャートにブラシをかけられるようにします。これにより、これらの異なる次元間の相関関係を確認できます。
ここでは、私がお見せした数十億のレコードのような非常に大規模なデータセットに対してこれを行うことができます。しかし、このような高速な更新を可能にするために、ヒストグラムを計算するナイーブなことはできません。それはおおよそこのSQLクエリになるでしょう。
代わりに行うことは、ブラッシングしている次元によって追加で集約する事前集約テーブルを作成することです。それがここの黄色の部分です。そして、実際に必要な列やデータを、この事前集約されたデータに対するクエリとして取得できます。ですから、もう生データに行く必要はありません。これよりはるかに小さいこの事前集約データに行き、このようにしてはるかに高速な更新を得ます。
6.4 技術的詳細に関する質問応答
質問者： 細かい質問です。これらのデモから判断すると、ネットワーク遅延は表示されていないと思います。これはすべてローカルクライアントで実行されているのですか？
Dominic： これらの例はローカルクライアントで実行されています。しかし、例えばこの事前集約テーブルを作成する場合、実際にクライアントにそれを置くことができれば、もうネットワーク遅延はなくなります。これはまだ実装していませんが、実装する予定です。
質問者： つまり、原理的には、これらの種類の技術により、本質的にコンパクトな表現を配送してそのままレンダリングできると考えているのですね？
Dominic： はい。
質問者： わかりました。事前集約テーブルを作成するのにどれくらい時間がかかりますか？明らかにデータセットのサイズに依存しますが、大まかに言って。
Dominic： 私たちはDuckDBを使用していて、1000万行以上であれば、ブラウザで簡単に処理できます。1秒未満です。
質問者： つまり、ミリ秒単位の話ですね。
Dominic： そうです。
質問者： フィルターをオンにすると。
Dominic： はい。そうです。それで更新はリアルタイムです。理想的には60フレーム毎秒です。大規模なデータセットで実際にどのように見えるかをデモでお見せします。
質問者： これはデータがテーブル形式であるという事実に依存しているように思えます。画像のようなものだったらどうでしょうか。理論的には、ピクセル値と位置などでデータベースとして表現できますが、これを使用する前に、使用している表現をデータベースに変換する必要があるのでしょうか、それとも別の形式のデータでこれを行う方法があるのでしょうか？
Dominic： 私たちは表形式データに依存しています。それは正しいです。しかし、おっしゃったように、画像は表形式データとして表現できます。少し加工する必要があるかもしれませんし、画像データでより直接的に動作すると良いでしょう。モデルをあまり変更せずに可能であるべきだと思います。しかし、今のところ表形式データに依存しています。
6.5 パフォーマンスと対応チャートタイプ
Dominic： これらの透過的な最適化をここで適用でき、棒グラフ、折れ線グラフ、ヒストグラム、エラーチャート、密度プロット、六角ビンなどの様々なチャートでかなりうまく機能します。初期レンダリングについては、実際にはほとんどの利点はDuckDBの素晴らしさと、これらのローカル最適化の一部、このプリレンダリングから来ています。
Michaelの質問に戻りますが、実行時間、つまりおおよそどれくらいかかるかについてです。1億ポイントについて話していて、1秒未満です。数十億ポイントに達すると、少し時間がかかります。しかし、これは持っているサーバーの種類にも依存します。また、今はテラバイト単位のデータについて話しているので、ほとんどの人はそれを持っていません。
インタラクティブな更新は基本的に0.1秒以下に保たれています。ですから、データのスケールにほぼ関係なく、本当に高速です。これらの最適化を行っていない場合、Vega Fusionが示すこの線が見えるでしょう。これは指数関数的に上昇します。Vega Fusionも効率的なバックエンドを使用していますが、これらのトリックを使用していないだけです。
7. Mosaicの統合と拡張性
7.1 anywidgetとの統合
Dominic： そして、これでMosaicを構築しました。これらはダッシュボードと呼ばれるものを構築できますが、実際にノートブックなどの他の環境にも埋め込むことができます。ここでanywidgetが登場します。実際に私が午後で構築したのは、anywidgetを使用してJupyterで動作するようにしたことです。ですから、このような種類のツールを持つことは非常に価値があると思います。
7.2 他言語・フレームワークとの統合
Dominic： Vega-LiteやD3などの言語と統合する作業をさらに行っています。しかし、ここにデモがあります。これは、vgplotと連携するためにMosaicによって仲介されたVega-Liteです。ですから、異なるフロントエンドを使用でき、これが私が以前指摘した相互運用性であり、非常に価値があると思います。
7.3 Python APIと公開情報
Dominic： 近日公開予定のPython APIもあります。うまくいけばすぐにリリースされます。Mosaicで構築できる様々なチャートや様々なフロントエンドがあります。今はこれを飛ばしますが、すべてGitHub上でオープンソースとして公開されています。
そして、実際にAppleでMosaicの上に構築したツールの一つをお見せします。それがEmbedding Atlasです。これはDongha Hen、Fredらとの仕事で、これもオープンソースで、論文もオンラインで公開されています。
8. Embedding Atlas：再利用可能なコンポーネントライブラリ
8.1 開発背景と共通コンポーネントの発見
Dominic： チームと一緒に作業する中で私たちが発見したのは、多くの分析が類似したコンポーネントを必要とするということでした。データセット比較を行う場合、どの領域がカバーされていないかを見たり、コメントを見たり、文献の概要を見たり、画像分析を行ったり、安全ポリシーに取り組んだりする際に、これらの多くが、テーブル、理解を得るための何らかの埋め込みビュー、そしてチャートという類似したコンポーネントを必要とすることがわかりました。
ですから、これらのケースそれぞれでゼロから構築するのではなく、これを統一してテーブルコンポーネント、埋め込みビューコンポーネント、チャートを構築し、これらの異なる分析に適応できる十分に汎用的なツールを構築できないかと考えました。そして、それがEmbedding Atlasの登場です。MosaicとDuckDBの基盤の上で作業し、これらの再利用可能なコンポーネントを持ち、分析ツールを構築できます。これらはJupyterノートブック、Streamlit、独自のデータアプリなどに埋め込まれます。
今お話ししたところですが、私たちが構築したコンポーネントの一つは仮想化テーブルです。何十万行もの大規模なデータセットをスクロールしたりジャンプしたりできます。仮想化テーブルと呼ばれるのは、実際にはすべての行をレンダリングしているわけではないからです。その瞬間に見えているものだけをレンダリングしています。
だからこそ、ここで何十万行もスクロールできるのです。埋め込みビューがあり、異なる領域に簡単にズームでき、密度を計算することもできます。これはリアルタイムで計算されます。異なる領域を見ながら、データセットの異なる部分によってどの領域がカバーされているかを確認できます。
これらすべてが、Embedding Atlasと呼ばれるこのツールで一体となっています。実際に別のJupyterノートブックでこれをお見せします。ここで行ったのは、データセットを読み込むことです。これはワインに関するデータセットで、Embedding Atlasと呼ばれるこのツールに読み込みました。
実際にこれを開きます。ちょっとしたスライドの技で、少し大きく表示します。しかし同じツールです。ワインに関するこのデータセットがあり、ここの任意の領域に素早くズームしたり、密度を計算したり、特定のワインがどの領域にあるかを確認したりできます。実際には説明文を使用してTF-IDFを行い、これらのラベルを生成しています。
側面にクイックフィルターがあります。米国のものだけを見たり、このデータがある場所でフィルタリングしたりできます。これらすべてがどれだけ素早く更新されるかがわかります。ですから、このリアルタイムの側面は本当に非常に重要です。しかし、このJupyterウィジェットにいるとき、ただこれと同じことをしただけですが、相互運用可能にしました。例えば、ここでデータの範囲を選択でき、下で選択を取り出して、選択したデータを取得し、下流の分析に使用できます。
その多くは、anywidgetを使用し、Mosaicのセレクションを取り出すことで実現しました。しかし、これは本当に組み合わせ可能であるだけでなく、相互運用可能にしています。なぜなら、今では私がすでに愛用している他のPythonの下流ツールと一緒に使用できるからです。あるいは、他の誰かが作成する可能性のある別のウィジェットと一緒に使用できます。このテーブルのようなものです。おそらく誰かがこのテーブルのより良いバージョンを思いついて、それがこのツールと連携できるでしょう。
8.2 コンポーネントの詳細
Dominic： すでに触れましたが、Embedding Atlasはこれらの異なるコンポーネント、つまり埋め込みビュー、チャート、テーブルで構成されており、この特定の配置で一緒に配置されています。しかし、実際には、これらの各コンポーネントを異なる配置で個別のコンポーネントとして再利用することもできます。
8.3 Jupyterノートブックでのデモ
Dominic： 実際に別のJupyterノートブックでこれをお見せします。ここで行ったのは、データセットを読み込むことです。これはワインに関するデータセットで、Embedding Atlasと呼ばれるこのツールに読み込みました。実際にこれを開きます。ちょっとしたスライドの技で、少し大きく表示します。しかし同じツールです。
ワインに関するこのデータセットがあり、ここの任意の領域に素早くズームしたり、密度を計算したり、特定のワインがどの領域にあるかを確認したりできます。実際には説明文を使用してTF-IDFを行い、これらのラベルを生成しています。
側面にクイックフィルターがあります。米国のものだけを見たり、このデータがある場所でフィルタリングしたりできます。これらすべてがどれだけ素早く更新されるかがわかります。ですから、このリアルタイムの側面は本当に非常に重要です。
しかし、このJupyterウィジェットにいるとき、ただこれと同じことをしただけですが、相互運用可能にしました。例えば、ここでデータの範囲を選択でき、下で選択を取り出して、選択したデータを取得し、下流の分析に使用できます。その多くは、anywidgetを使用し、Mosaicのセレクションを取り出すことで実現しました。
8.4 相互運用性とオープンソース公開
Dominic： しかし、これは本当に組み合わせ可能であるだけでなく、相互運用可能にしています。なぜなら、今では私がすでに愛用している他のPythonの下流ツールと一緒に使用できるからです。あるいは、他の誰かが作成する可能性のある別のウィジェットと一緒に使用できます。このテーブルのようなものです。おそらく誰かがこのテーブルのより良いバージョンを思いついて、それがこのツールと連携できるでしょう。
さて、私が言ったように、Embedding Atlasはこれらの異なるコンポーネントで構成されています。埋め込みビュー、チャート、テーブルがこの特定の配置で一緒に配置されています。しかし、実際には、これらの各コンポーネントを異なる配置で個別のコンポーネントとして再利用することもできます。
そして、すべてGitHub上でオープンソースとして公開されています。ノートブック、Jupyterノートブックへのすべての統合、Streamlitへの統合、そして個別のコンポーネントとしても公開されています。最後にQRコードを用意しますので、すべてのデモ、すべてのリソース、そして参照したすべての論文へのリンクをご覧いただけます。
最後にお見せします。さて、あと約50分ありますね。
9. Texture：テキストデータ分析への特化
9.1 テキストデータの遍在性と課題
Dominic： 次は、Textureについてです。これは、CMUのWill EpersonとAdam Perと一緒に取り組んでいる仕事です。Willは来月卒業します。私たちはテキストに非常に興味を持ってきました。テキストはあらゆるところにあります。
テキストデータは、大規模言語モデルにおける多くの進歩の中核となってきました。私たちは、テキスト探索のための様々なツールを調査しました。そして、これらのツールの多くが特定のフロントエンドを構築しているが、それでもこれらすべてに現れる非常に共通のコンポーネントがあることがわかりました。
ですから、同様に、この分析に戻ると、私が実際に指摘したタスクのうち2つはテキスト分析タスクでした。ここでも再びこれら3つのコンポーネント、つまりテーブル、インスタンスビュー、埋め込みビュー、そしてチャートを使用しています。しかし、今度はテキスト分析に本当に機能させるために、少し異なる配置で示しています。
しかし、一つ欠けている要素がありました。それは、例えばこのテキストアブストラクトコーパスを見ている場合、ここの引用数のような数値列だけではないということです。これはヒストグラムで描画できます。あるいは、会議のようなカテゴリ値で、棒グラフで描画できます。
しかし、これらのテキスト列もあります。これらを伝統的なデータプロファイリングツールに投げ込むだけでは、基本的に、カーディナリティがnに等しいという問題があります。つまり、すべてのインスタンスが異なり、非常に長いため、それらを理解することが困難です。ですから、行わなければならないのは、それらから何らかの追加情報を導出することです。
9.2 テキストデータ特有の問題と解決策
Dominic： 例えば、タイトルやアブストラクトから単語を導出するかもしれません。しかし、今度は各インスタンス、各ドキュメントに対して単一の値ではなく、単語のセットがあります。ですから、今度は本質的に別のテーブルを作成する必要があります。それは元のテーブルと結合され、これに対するフィルタリングをサポートします。
ですから、それがテキストツールやテキストデータセットのデータプロファイリングを機能させるために追加しなければならなかったコンポーネントです。別の例は、導出されたトピックかもしれません。これはおそらくより低いカーディナリティですが、やはりドキュメントごとに複数の値があります。
それを使用して、Textureを作成しました。スクリーンショットがありますが、Textureをお見せしようと思っていました。Embedding Atlasで見たものと類似したコンポーネントを持っています。埋め込みビューがあります。今度ははるかに小さいものです。これらの結合次元を含む、このデータセットの異なる次元を探索するためのチャートがあります。そして、右側にインスタンスビューがあります。
素晴らしいのは、それらすべてがクロスリンクされていることです。ですから、単語の一つをクリックすると、即座にハイライトされます。フィルタリングされ、右側のインスタンスビューで単語がハイライトされます。
ですから、このようなかなり標準的なコンポーネントを一緒に配置することで、論文コーパス探索からトピック分析や政治的ソーシャルメディア、そしてプロンプト比較に至るまで、様々なタスクでテキスト分析における多くの問題を解決できることを示すことができました。
そして、小さなコンポーネントのセットを組み合わせることで、多くの異なる分析を再現でき、特化したツールを必ずしも構築する必要がないことがわかりました。そして、特化したツールを構築する必要がないことには、多くの価値があると思います。特に、これらのツールを使用している人々がまた別のツールを学ぶ必要がないからです。彼らはすでに学んだことを使用して、次のシナリオに適用できます。
9.3 Textureの構成と機能
Dominic： Textureには、スクリーンショットがあります。Textureには、Embedding Atlasで見たものと類似したコンポーネントがあります。埋め込みビューがあります。今度ははるかに小さいものです。これらの結合次元を含む、このデータセットの異なる次元を探索するためのチャートがあります。そして、右側にインスタンスビューがあります。
素晴らしいのは、それらすべてがクロスリンクされていることです。ですから、単語の一つをクリックすると、即座にハイライトされます。フィルタリングされ、右側のインスタンスビューで単語がハイライトされます。
ですから、このようなかなり標準的なコンポーネントを一緒に配置することで、論文コーパス探索からトピック分析や政治的ソーシャルメディア、そしてプロンプト比較に至るまで、様々なタスクでテキスト分析における多くの問題を解決できることを示すことができました。
そして、小さなコンポーネントのセットを組み合わせることで、多くの異なる分析を再現でき、特化したツールを必ずしも構築する必要がないことがわかりました。そして、特化したツールを構築する必要がないことには、多くの価値があると思います。特に、これらのツールを使用している人々がまた別のツールを学ぶ必要がないからです。彼らはすでに学んだことを使用して、次のシナリオに適用できます。
10. Data Navigator：アクセシブルなデータナビゲーション
10.1 開発背景とalt textの限界
Dominic： さて、最後にData Navigatorです。テキストデータ分析とテキスト分析からアクセシビリティへと移ります。
私は、CMUの学生であるFrank ElavskyにこのSlackメッセージを送りました。私は論文に取り組んでいて、かなり複雑な素晴らしい可視化がありました。そして、私はこう言おうとしていました。「これのalt text、つまりスクリーンリーダーを使う人がこれを理解できるようにするための代替テキストをどう書けばいいですか？」
基本的に答えは、できないということでした。これを十分に説明するalt textは、あまりにも長すぎるでしょう。ですから、代わりに必要なのは、スクリーンリーダーを使用する人がこのデータやこの可視化をナビゲートして、興味のある側面を選び出せる何らかの方法です。
ですから、ナビゲートできるようにする必要があります。では、この棒グラフをどのようにナビゲート可能にするのでしょうか？その上に何らかの構造を追加する必要があります。ここでは、その構造を表現したものとして、ある要素から別の要素へナビゲートできるようにする入力と、アクセシブルな出力をレンダリングするための出力が必要です。そして、これらすべてがData Navigatorで一緒になります。
Data Navigatorが行うことは、チャートからダイアグラム、そして将来的にはドキュメントや他のものに至るまで、様々なデータ表現にアクセシブルな構造、入力、レンダリングを追加することです。
10.2 Data Navigatorのアプローチ
Dominic： このアクセシブルな構造とは何かというと、私たちが作成したグラフ構造です。それは単にノードとエッジです。そして、私たちが発見したのは、グラフ構造が、データ表現に存在する多くの異なるナビゲーションパターンを作成するために必要な最も柔軟な構造だということです。
例えば、テーブルを作成できます。あるいは、この2次元構造にあるノードのグラフとしてテーブルを表現できます。リストは単一の1次元のノードのラインとして表現できます。階層は、階層的なデータを表現する方法として、再びグラフとして表現できます。
ノードは事実上何でもあり得ます。ネットワークグラフのノードかもしれませんし、ダイアグラムのノードかもしれませんし、地図表現における州かもしれません。地図があり、各州がノードになるとします。エッジは、州が隣接しているかどうかです。そして今度は、誰かがこのデータセットをどのように探索したいかを表現できます。
これらのエッジは、ナビゲーションがどのように確立されるかです。ですから、それらは関係を促進し、誰かがそれらをどのようにナビゲートするかを促進しています。例えば、ノードから右に行ったり、左に行ったり、凡例に行ったり、軸のどこか他の場所に戻ったりできるかもしれません。ですから、それが必要な最初のコンポーネント、つまり構造です。
次に、どのようにナビゲートするかを定義する必要があります。それが入力の登場です。例えば、キーボードの左矢印を押すのか、他の何らかの入力システムを使用するのか、あるいはユーザーが「左に移動」のように言うのか。ですから、このグラフをナビゲートすることをサポートしたい方法は異なります。そして、適切な入力フォーマットは本当にユーザーに依存します。
誰かはキーボードを使うのに慣れているかもしれません。他の誰かは音声を使いたいかもしれません。しかし、これらは独立しているべきです。ですから、それらを独立させるために、入力を構造から分離したかったのです。
ここに例があります。例えば、グラフ内で、これはスタック棒グラフのようなものです。通常、これらのチャートでナビゲーションがサポートされていた方法は、マウスを使用することでした。おそらくマウスでポイントをナビゲートして、正確なデータを見ることができます。それをサポートすることもできますが、カメラを使用することもサポートできます。
実際にデモがあります。指のジェスチャーを認識するモデルを使用するだけで、そこから左にナビゲートできます。あるいは、「left」という単語を言うかもしれません。あるいは、電極が取り付けられたバナナを使用するかもしれません。バナナをタップすると、グラフをナビゲートできます。ですから、入力は本当に非常に柔軟です。
最後に、分離したかったのはレンダリングです。ですから、任意の種類のグラフィックをサポートしたかったのです。バックエンドにあるグラフィックで、HTMLレイヤーにあるこのオーバーレイの上に配置されます。バックエンドは任意の種類のグラフィックであり得ます。
実際にセマンティック情報を持つSVGであり得ますし、セマンティック情報を全く持たない単なる画像であるかもしれません。その場合でも、このData Navigatorオーバーレイを追加して、このデータのナビゲーションをサポートできます。
10.3 グラフ構造の採用
Dominic： このアクセシブルな構造とは何かというと、私たちが作成したグラフ構造です。それは単にノードとエッジです。そして、私たちが発見したのは、グラフ構造が、データ表現に存在する多くの異なるナビゲーションパターンを作成するために必要な最も柔軟な構造だということです。
例えば、テーブルを作成できます。あるいは、この2次元構造にあるノードのグラフとしてテーブルを表現できます。リストは単一の1次元のノードのラインとして表現できます。階層は、階層的なデータを表現する方法として、再びグラフとして表現できます。
ノードは事実上何でもあり得ます。ネットワークグラフのノードかもしれませんし、ダイアグラムのノードかもしれませんし、地図表現における州かもしれません。地図があるとします。各州がノードになります。エッジは、州が隣接しているかどうかです。そして今度は、誰かがこのデータセットをどのように探索したいかを表現できます。
これらのエッジは、ナビゲーションがどのように確立されるかです。ですから、それらは関係を促進し、誰かがそれらをどのようにナビゲートするかを促進しています。例えば、ノードから右に行ったり、左に行ったり、凡例に行ったり、軸のどこか他の場所に戻ったりできるかもしれません。ですから、それが必要な最初のコンポーネント、つまり構造です。
10.4 入力とレンダリングの分離
Dominic： 次に、どのようにナビゲートするかを定義する必要があります。それが入力の登場です。例えば、キーボードの左矢印を押すのか、他の何らかの入力システムを使用するのか、あるいはユーザーが「左に移動」のように言うのか。ですから、このグラフをナビゲートすることをサポートしたい方法は異なります。そして、適切な入力フォーマットは本当にユーザーに依存します。
誰かはキーボードを使うのに慣れているかもしれません。他の誰かは音声を使いたいかもしれません。しかし、これらは独立しているべきです。ですから、それらを独立させるために、入力を構造から分離したかったのです。
ここに例があります。例えば、グラフ内で、これはスタック棒グラフのようなものです。通常、これらのチャートでナビゲーションがサポートされていた方法は、マウスを使用することでした。おそらくマウスでポイントをナビゲートして、正確なデータを見ることができます。それをサポートすることもできますが、カメラを使用することもサポートできます。
実際にデモがあります。指のジェスチャーを認識するモデルを使用するだけで、そこから左にナビゲートできます。あるいは、「left」という単語を言うかもしれません。あるいは、電極が取り付けられたバナナを使用するかもしれません。バナナをタップすると、グラフをナビゲートできます。ですから、入力は本当に非常に非常に柔軟です。
最後に、分離したかったのはレンダリングです。ですから、任意の種類のグラフィックをサポートしたかったのです。バックエンドにあるグラフィックで、HTMLレイヤーにあるこのオーバーレイの上に配置されます。バックエンドは任意の種類のグラフィックであり得ます。
実際にセマンティック情報を持つSVGであり得ますし、セマンティック情報を全く持たない単なる画像であるかもしれません。その場合でも、このData Navigatorオーバーレイを追加して、このデータのナビゲーションをサポートできます。
11. Data Navigatorのデモと設計議論
11.1 ウェブサイトでのデモ
Dominic： さて、これのデモをお見せします。これはData Navigatorのウェブサイトです。ここに以前見た棒グラフがあります。通常、おそらく伝統的には、マウスカーソルを使用してこれをナビゲートできるだけでしょう。
ここでできることは、このグラフを通過することです。凡例に行ったり、Y軸、X軸に行ったりできます。これらの間を前後に移動することもできます。しかし、中に入ることもできます。異なるキーボードを使用して、これらを示すことができます。
例えば、Enterキーを使うと、中に入ることができます。どこかでフォーカスを失ってしまいました。Enterキーです。凡例から最初のシリーズに入りました。ここでは青色のシリーズです。2番目のシリーズに下に移動できます。あるいは、シリーズの中にも入ることができます。今度は個別のアイテム間をナビゲートできます。
これらすべてをキーボードだけで行っています。それから再び戻ることもできます。しかし、同じ入力、申し訳ありません、同じデータは他の入力を使用してナビゲートすることもできます。このジェスチャーモデルのように、カメラを使用したり、音声テキストモデル、スピーチ・トゥ・テキストモデルを使用したりできます。
ですから、データをナビゲートする異なるコンポーネント、異なる側面を分離することで、つまり構造、入力、レンダリングを分離することで、非常に広範なナビゲーションパターンをサポートでき、実際に様々な異なるナビゲーション構造を再現できます。
11.2 カスタマイズに関する質問と回答
質問者： グラフィックのコンポーネントには、何らかの明示的な順序がありますね。タイトルが見られて、次に凡例、Y軸、X軸という具合です。どのように決めるのですか。あるいは、このグラフ構造はユーザーがその順序を決定できるようにしているのでしょうか？そうでない場合、これをよりカスタマイズ可能にするにはどうしますか？
Dominic： そうですね。カスタマイゼーションについては、実際に論文を提出したばかりです。しかし、ここでは主に開発者に依存していると思います。ですから、Data Navigatorを異なるナビゲーション構造を構築するための低レベルフレームワークとして考えてください。
このチャートでは、凡例から個別のシリーズにナビゲートできるようにしたい、シリーズから個別の棒セグメントにナビゲートできるようにしたい、あるいはシリーズにナビゲートする代わりに、棒にナビゲートして、そこから次の棒へというように言えます。ですから、これらは異なるナビゲーションパスであり、このグラフとして表現されます。そして、異なるキーボードや異なる入力により、異なるタイプのエッジをナビゲートできます。
理想的には、開発者として柔軟なナビゲーションパスを定義し、ユーザーが従いたいパスをたどれるようにします。ですから、十分な数のパスを定義すべきです。使用する入力が分離されているため、うまくいけば、ユーザーが自分でカスタマイズできるものです。
ですから、キーボードユーザーであれば、左エッジタイプはキーボードの左キーでナビゲートすべきだと言えます。他の誰かは、音声を使いたいと言うかもしれません。あるいは他の誰かは、バナナにタッチしたいと言います。ですから、それらは分離されるべきです。しかし、構造はうまくいけば、人ごとにカスタマイズする必要がないほど十分に安定しているものです。
しかし、うまくいけば将来的には、人々がそれさえもカスタマイズできるようにすることができるかもしれません。
11.3 スクリーンリーダーとドキュメントへの応用
質問者： Data Navigatorについても質問があります。これはスクリーンリーダーに適用できるのか、あるいは一般的にドキュメントをスキャンすることに適用できるのか気になっています。UIをタブで移動するのが退屈で難しいことがあるのを今でも覚えていますが、そこにすでに類似したフレームワークがあるのか、それともあなたが開発したこのフレームワークが役立つ可能性があるのでしょうか？
Dominic： 私たちはスクリーンリーダーユーザーのためにこれを構築しました。ですから、スクリーンリーダーと一緒に使用することもできます。そして、実際にスクリーンリーダーにとって非常に効率的です。スクリーンリーダーが通過する要素のみを遅延的に作成するという点で効率的です。大きなグラフがある場合、その瞬間に本当に必要なものだけを作成します。それによって非常に効率的になり、オーバーヘッドを削減します。
ですから、はい、スクリーンリーダー用に設計されました。
質問者： スクリーンリーダー空間で以前に行われていることについても気になります。彼らはこの種のアクセシブルなフレームワークをすでに持っているのか、持っていないのか、あるいは...
Dominic： 本当にアクセシブルなフレームワークはありません。それが私たちがこれを構築した理由です。そして、本当に基盤として、将来的には他の体験を構築できるようにしています。うまくいけば、Data Navigatorのようなものが、Web標準のような標準に統合される可能性があることを願っています。そうすれば、すべてのブラウザがそれを標準でサポートし、HTMLのように組み込まれたものになります。
まだそこには至っていません。それが私たちが今のところライブラリとしてこれを構築した理由です。しかし、すでに様々なコンテキストでの採用を検討しているパートナーと話をしています。
質問者： ほとんどのナビゲーションは、線形または階層的な方法で構築されてきましたが、可視化にはそれでは不十分だということがわかりました。例えば、地図では、単なる下と上、左と右ではありません。それはツリーが表現するものです。しかし、おそらく2方向以上があるかもしれません。州は2つ以上の隣接州を持っています。
Dominic： はい。
質問者： これは何らかの形でサプライズでした。なぜなら、ドキュメントを一般的に読んでいるだけでも、多くの他の方向があるはずですが、常に非常に階層的です。
Dominic： はい、これには絶対的に応用があります。
12. まとめと今後の展望
12.1 発表の総括
Dominic： さて、時間がなくなってきましたので、簡単にまとめたいと思います。お招きいただき、本当にありがとうございました。私は「Build less, design more」についてお話ししました。多くの組み合わせ可能で相互運用可能な可視化システムについてお話ししました。そして、うまくいけば、皆さんがこれらの相互運用可能なソフトウェアを構築する方法について、もっと考えるきっかけになればと思います。
12.2 紹介したシステムとリソース
Dominic： 多くの書籍と論文を参照してきました。ですから、ここにQRコードがあります。これはウェブサイトにリンクしており、これらすべての情報があります。私のウェブサイトか、CMUの私のグループのdii.cmu.eduにアクセスすることもできます。本当にありがとうございました。