ズーム可能なタイムラインで400万件のWikipediaイベントを可視化する

Lortexは、WikipediaとWikidataから取得した400万件のイベントを可視化する、ズーム可能なタイムラインインターフェースを作成しました。このプロジェクトは、Kotlin Multiplatformに基づいた高性能な技術スタックを利用し、ジャーナルアプリケーション向けに設計されたカスタムタイムラインUIのデモンストレーションとして機能します。

技術アーキテクチャとスタック

このアプリケーションは、クロスプラットフォームの互換性とパフォーマンスを確保するために、モダンなKotlin中心のスタックを使用して構築されています。コアコンポーネントは以下の通りです：

• Frontend UI: Compose Multiplatform を使用してユーザーインターフェースを構築し、歴史的イベントのズーム可能な空間的レイアウトを可能にしています。
• Cross-Platform Logic: プロジェクト全体で Kotlin Multiplatform (KMP) が広く使用されており、異なるターゲット間でロジックを共有しています。
• Communication: フロントエンドは Kotlinx-RPC を介してバックエンドと通信します。
• Backend and Infrastructure: システムは、Hetznerのサーバー上でホストされている Postgres データベースによって駆動されています。

膨大なデータセットを精査するために、開発者は PageRank を使用してイベントにスコアを付け、Wikipedia/Wikidataからのインポートにおいて最も重要なイベントが可視化において優先されるようにしました。

ユーザーエクスペリエンスとパフォーマンスの観察

このプロジェクトは、その空間的レイアウトに対して肯定的なフィードバックを受けていますが、ユーザーからは異なる環境において様々なパフォーマンス結果が報告されています：

• スムーズなパフォーマンス: 一部のユーザーは、Linux Gnome上のFirefoxでスムーズな体験を報告しています。
• 安定性の問題: 他のユーザーは、Firefoxでの即時のフリーズや、Android版Chromeでの機能不全を経験しています。
• 読み込み状態: ユーザーは、初期読み込み中の視覚的なフィードバックの欠如を指摘しており、一部では最大30秒間画面が空白のままになることが報告されています。

データ精度とUIの制約

コミュニティのフィードバックにより、データのパースと時間的精度に関する特定の課題が浮き彫りになりました：

• データエラー: データの誤りの例として、場所の郵便番号が誤って年として解釈されたケース（例：760251年に発生したイベントとして表示される）が挙げられました。
• 時間的精度: 年が約1ピクセル程度のサイズに縮小されると、UIが崩れることが観察されました。これは、極めて高い時間的精度を持つタイムスタンプ（例：ビッグバン直後の秒単位のイベント）を扱う際の制限を示唆しており、より高ビットのタイムスタンプ保存が必要になる可能性があります。
• 時制の一貫性: 未来に予定されているイベントが、現在は過去形でラベル付けされていることが指摘されました。これは、予測されたイベントにとって誤解を招く可能性があります。

コミュニティの視点

ユーザーは、システムログやメトリクスの分析など、他の技術的なドメインに同様のズーム可能なタイムラインインターフェースを適用することに関心を示しています。また、他のユーザーは、このプロジェクトを、Wikipediaからのバルクインポートではなく、手動で精査されたアプローチを採用している「deep-timeline.org」の宇宙のログスケール・タイムラインのような既存のツールと比較しています。