ブックマークバー vs. サイドバー vs. スタートページダッシュボード：Chromeの仕組みに実際に合うのはどれか

このプロダクトを作り始めたとき、3つのUIパラダイムすべてが選択肢としてありました。そして私は、一番地味なものを選びました。この記事では、機能比較表ではなく実際の操作コストの計算をもとに、その理由を説明します。「地味」というのは想像力の欠如ではなく、実際のトレードオフ分析を経て意図的に導き出された結論だからです。

市場にあるブックマークツールは——例外なく——3つの形状のいずれかにコミットしています。ページの上に乗る「行」。ページの横に住む「サイドバー」。新しいタブページを置き換え、あなたが訪れるのを待つ「ダッシュボード」。これらを組み合わせているツールはありません。形状は、そのツールの使い心地のほぼすべてを決定づける根本的な決断だからです。なので、これを見た目の選択として扱うのではなく、どの形状がどの仕事に合うのか、実際にきちんと考える価値があります。

3つのパラダイム

行（常に表示、コンテキストスイッチなし）。 これはChrome標準のブックマークバーそのものであり、2つ目の行もこれにあたります。今見ているページの上に、使っているかどうかに関わらず常に固定の縦幅を占有して存在します。

サイドバー（常設パネル、ページの形を変える）。 コンテンツの横に住む縦長のパネルです——ブラウジングの隣にピン留めされたブックマークマネージャをイメージしてください。行と同じくいつでも使えますが、縦ではなく横の空間を占有するため、下にあるページ自体が短くなるのではなく、狭くなります。

ダッシュボード（訪れる先）。 保存済みリンクやフォルダ、セッションを表示するスタートページ、あるいは新しいタブの乗っ取りです。他の2つと違い、ブラウジング中に常に存在するわけではありません。そこへ移動して、使い、また離れていきます。

このカテゴリの比較記事のほとんどは、検索・タグ・フォルダ・同期といったチェックマーク付きの機能比較表にいきなり飛びます。まるでツールの形状が中立的な入れ物で、機能こそがすべてであるかのように。しかし実際はそうではありません。形状こそが、そのツールがいつ邪魔になり、いつ見えなくなり、ツールのことなど考えていない99回の取り出し——ただページに戻りたいだけの瞬間——にどれだけのコストを課すかを決めます。それこそが実際に検討する価値のある部分です。

操作コストの分析

これらを正直に比較する方法は機能一覧ではなく、それぞれが3つの異なる瞬間——何かを保存するとき、何かを取り出すとき、まったく使っていないとき——にどれだけのコストを課すかです。

保存のコスト。 行とサイドバーはどちらもすでに画面上にあるため、保存はどこにも移動せずドラッグまたはクリックだけで完了します。ダッシュボードでは、新しいタブを開く（現在のタブを失う、複製しない限り）か、裏でダッシュボードのデータストアに書き込む別の保存の仕組みを使う必要があります——アクションと着地点の間に余分な層が挟まります。

取り出しのコスト。 ここでパラダイムの差が最も顕著になります。行：見上げてクリック、それで終わり——移動ゼロです。サイドバー：同様ですが、すでに画面幅を占有しているため、すでに見えているか、ワントグルで開くかのどちらかです。ダッシュボード：新しいタブを開き、レンダリングを待ち、目的のものを見つけ、そこで開く（今のタブのコンテキストを失う）かリンクをコピーして戻るかのどちらかです。ダッシュボードでの取り出しは、そのたびに小さな往復が発生します。

使っていないときのコスト。 これは多くの人が過小評価している点です。行は、見ているかどうかに関わらず常に一定の縦幅を占有しますが、そのコストは小さく予測可能で、ページ自体のレイアウトと争いません。サイドバーは常に実際の横幅を継続的に占有します。ワイドなデスクトップモニターより狭い環境では、読んでいるページの実際のコンテンツが目に見えて圧迫され、フルビューポート幅を前提にしたレスポンシブレイアウトを視覚的に壊してしまうことがあります。ダッシュボードは使っていないときのコストがゼロです——単純にそこにいないからです。これはダッシュボードにとって本物の優位性であり、構造的に勝る唯一の場面です。

なぜChrome自身が「行」を選んだのか

これは偶然ではありません。行はブラウザのChrome自体がすでに持っている作りの流儀に合っています——Chrome標準のブックマークバーも行、タブストリップも行、アドレスバーも行です。この流れに2つ目の行を重ねるのは加算的な変更にすぎず、サイドバーのようにブラウザの既存の視覚言語と争いません。サイドバーは「どちら側に、どれくらいの幅で、開いたときページ自体のレイアウトはどうなるのか」を答える必要がありますが、行はそうした問いを一切必要としません。

正直に作られたサイドバーは、ページから実際の幅を確保しなければなりません。フルワイドのデスクトップモニターではそれは軽微な負担です。しかしノートPC、特に13〜14インチ台に近いものや、小さめのディスプレイで最大化したブラウザウィンドウでは、常設サイドバーが固定ピクセル数を占有することで、Webアプリ自体のレスポンシブブレークポイントが、サイトの作者が想定していなかった窮屈な状態に押し込まれることがあります——ボタンが不自然に折り返され、カラムが早々に崩れ、想定より狭い空間しか与えられなかったレイアウトになるのです。

私は日常的に使う同じWebアプリ群に対してサイドバー型の拡張機能を試す中で、これを実際に目撃してきました。プロジェクト管理ボードがビューポートが縮んだと判断して自分のサイドバーをアイコンのみモードに折りたたむ、チャットアプリが想定外の形で作成バーを積み上げる、ドキュメントエディタがモバイル幅のツールバーに切り替わる。これらはサイドバー拡張機能自体のせいというわけではありません——実際、広告した通りの幅を正当に占有しているだけです——それでも、行というパラダイムが決して生み出さない、現実に目に見えるコストです。行はページが通常余らせている縦の高さを取るのであり、ページ自体のレイアウトロジックが積極的に判断している横幅を取るわけではないからです。

それぞれのパラダイムが正直に勝る場面

これは行が普遍的に正しいという話ではありません。行が特定の仕事において正しく、他の2つはそれぞれ別の仕事において正しい、という話です。

• セッションやプロジェクトの引き継ぎではダッシュボードが勝ちます。 整理しているのが「金曜時点でのプロジェクトXの状態」——1つのまとまりとして見返す、あるいはチームメイトに渡すために厳選されたタブ群——であれば、ダッシュボードの目的地型モデルが合います。1つのリンクを1日に50回取り出すのではなく、1つのコレクションを1回開くのです。Tobyはこのパターンを中心に完全に構築された最もよく知られたツールです——このモデルが有効な場面とそうでない場面については、Tobyとの正直な比較を参照してください。
• 参照資料の多いシングルモニター作業ではサイドバーが勝ちます。 1つのドキュメントを十数個の開いたタブと継続的に突き合わせているなら、コンテキストを切り替えずにリストを横に表示しておく価値は、それが占有する幅を上回ることがあります——特にその幅が希少ではない、十分に広いモニターの場合です。
• 高頻度の取り出しでは行が勝ちます。 実際のパターンが、サポートキュー、CRM、ドキュメントサイト、デザインツールといった同じ30箇所へ1日に何十回もアクセスするというものなら、行のほぼゼロに近い取り出しコストが積み重なって効いてきます。1日50回の取り出しをほぼゼロのコストで行うほうが、サイドバーの常設幅コストやダッシュボードの往復コストをそのたびに払うより優れています。

Second Bookmark Barが「行」をどう実装しているか

そうした理由から、行は意図的に選んだものであり、デフォルトだったわけではありません。Second Bookmark Bar は、独立したiframeレンダラーと、メニューやポップアップ用の親オーバーレイ層を使って、ページの上にコンパクトな2つ目の行を追加します。そして、現代的なアプリシェルレイアウト上でも自身のスペースを慎重に確保するため、チャットアプリの送信ボタンやダッシュボード自体の下部ツールバーがバーの下に押しやられて画面外に消えるようなことはありません。この「上に浮かせるだけでなく、スペースを確保する」という点は、見た目以上に重要です。素朴なオーバーレイは、サイドバーがすでに苦労しているのと同じ種類のアプリシェルレイアウトと衝突してしまいます。

もっとも、そのスペース確保はレンダリングのコストを解決しているだけで、取り出しのコストを解決しているわけではありません。固定された行には、上の操作コストの計算が捉えていない残留コストが1つあります——今いるサイトに対して間違ったフォルダを表示してしまうことで、本来ワンクリックだった取り出しがフォルダ切り替え＋取り出しになってしまうというものです。この行のコストを表の「1クリック」という数字より下げるために、2つの仕組みが働きます。自動切り替え（Auto-Switch） は、現在のサイトに対応付けたフォルダへバーを切り替えます——発火するとスロットスイッチャーに星マークが表示され、いつでも手動で上書きできます——ので、見上げる前に正しいフォルダがすでに表示されていることが多くなります。そして「たしかどこかにあるはず」という取りこぼしのケースには、フォルダとドメインでラベル付けされた結果を返すバー内検索パネルがあります。今いるページの上でそのまま開けるため、上の表でダッシュボードのコストとして挙げた、一番望んでいないタイミングで払うことになるブックマークマネージャへの往復は発生しません。

正直な限界も一つ、隠さずに述べておきます。Chrome拡張機能は、chrome:// ページやChrome ウェブストア自体には、行であれサイドバーであれ何のUIも注入できません。これはこの拡張機能固有のギャップではなく、Chromeプラットフォーム自体の制約であり、この比較に登場するすべてのブックマークツールに等しく当てはまります。これらのページでは、Chrome標準の単一バーに戻ることになります。

あなたのブックマーク習慣が「同じ30箇所を毎日ずっと」に近いなら、行が実際の計算で勝ちます。単なる感覚の話ではありません。「プロジェクトをまとめて引き継ぐ」に近いなら、ダッシュボードが別の問いに対して正しい仕事をしています。同じ枠組みの中でRaindropのようなライブラリツールがどこにフィットするのかや、この2つ目のバー自身の除外サイトやクイック非表示コントロールがどのように「バーを見せたくない瞬間」向けの行モデルを補完しているのかも確認する価値があります。そして、行を検討する前にChromeがすでに用意しているあらゆるネイティブな方法についても同じクリック数と移動の正直さで見たいなら、こちらの内訳をどうぞ。

同じ議論を、Raindrop、Toby、Chrome標準、その他のツール名を挙げて1つずつ表にしたものは、並べて比較するページ群を参照してください。