概要
課題
Are.naは、つながりを中心にできています。ブロックをチャンネルへ保存し、そのチャンネルを別のチャンネルへつなぎ、また繰り返す。何か月も、何年も。やがて積み上がるものは、フォルダというより思考のしかたに近づきます。
でも、その姿はよく見えません。つながりは確かにあるのに、目には映らない。一ページずつ一直線に辿るしかなく、街の中に立つ代わりに、その街についての本を読んでいるようです。
その形を見てみたかった。
一つの決断
Kaboは、何かをするためではなく、見るための方法です。この一つの制約から、ほかの判断の大半は自然に決まりました。
Kaboではないもの
簡単につくれるのは、ブロック数、接続の深さ、最もリンクされたチャンネルを並べる分析ダッシュボードです。これは早い段階でやめました。
これを欲しがる人は、何かを最適化したいわけではありません。ゆっくり集める研究者やコレクターが、自分のつくってきたものと別の形で出会いたい。指標はただの雑音になります。
だから、統計も、インポートも、エクスポートもありません。すべてのノードはAre.naへ戻ります。Kaboは見方を借りるだけで、データは持ち去りません。そしてグラフは積み重なります。クリックするたび置き換えるのではなく、増えていく。歩き回りながら文脈をつくる。それがモデルのすべてです。
使い方
Kaboはチャンネルを取得し、暗い空間に力学ベースの3Dグラフとして描きます。チャンネルは淡く光る球、画像ブロックは実際の画像を載せた浮遊平面、テキストブロックは小さな色つき立方体。つながりは細く静かな線です。いつもそこにいて、叫びません。
中のブロックが現れ、開いたものにつながり、グラフが外へ育ちます。逆にブロックをクリックすれば、その所属チャンネルを読み込む。ある場所に保存した写真が、まだ訪れていない三つのチャンネルにもあるかもしれません。そんなつながりが自然に浮かび上がります。
チャンネルの球には、小さな括弧——[ ]——がついています。開けることを静かに示す印です。選ぶとサイドバーが現れ、名前、内容、プレビュー、元ページへのリンク、そして歩いてきた道筋を見せます。
技術上の判断
全体で最も重要なパフォーマンス判断です。ノードを動かすときはtransformを更新し、新しい形状は生成しません。リアクティブな実装では間違えやすく、状態が変わるたび、ゼロから再描画したくなります。
テクスチャはブロックIDをキーに、モジュールレベルのMapへ保存します。最初の訪問でGPUへアップロードし、二度目からはキャッシュを返す。これがないと、画像へ戻るたび目に見えて引っかかります。
チャンネルから開くのは最大20個のランダムなブロックと5個のサブチャンネル。ブロックからは最大3チャンネルです。APIの限界ではなく、プロダクトの限界。最初のクリックで200ノードを出したら、この体験の核が壊れます。
Are.naのAPIにはレート制限があるため、独立した取得は同時に走らせ、バックオフはプロキシに任せます。複数の場所から一度に取得しても、展開は軽快です。
次につくりたいもの
今のグラフはセッション内にしか存在しません。展開したチャンネルIDをURLへ直列化できれば、研究プロジェクトの形をそのまま誰かに渡せます。データベースも不要です。
30ノードを超えたあたりから、特定の一つを見つけにくくなります。名前でそっとハイライトできれば便利。ただし、あくまで空間になじませたい。モーダルの検索バーでは、この体験の核である空間感覚を壊してしまいます。
まだ100ノードを超えて試していません。Three.jsは持ちこたえるはずで、先に苦しくなるのは力学レイアウトでしょう。ズームアウト時のクラスタリングが、おそらく答えです。
オービット、ズーム、WASD。どれもスマートフォンには素直に移せません。タッチ版は、おそらく2Dのまったく別のインターフェースにする必要があります。描き始める前に、実際の利用場面を理解したい。
学んだこと
ここで最も難しかったのは技術ではなく、雑音に「ノー」と言うことでした。標準のツールチップも、モーダルも、出番を待つ通知も。静かに考えるための場所は、意識して守らなければ生まれません。