ブラウザの「ページ内検索」キーボードショートカットの上書き

こんにちは、Discourse のファンです。vBulletin5 から移行を検討している小規模コミュニティに所属しています。ある人が「Ctrl+f の乗っ取りは悪だ」と反対したため、その理由を確認したところ、私も同意せざるを得ませんでした。現在 Discourse が Ctrl+f をどのように処理しているかには、深刻な使いやすさの問題があります。Ctrl+f はブラウザ内のテキスト検索のショートカットです。

問題点

  • 場合によっては、Ctrl+f が正常に機能し、Discourse がブラウザの組み込み検索機能を使用して、入力した瞬間にページが最初のヒットにスクロールします。Ctrl+G で次のヒットに移動できます。
    • 快適です。
  • 場合によっては、Ctrl+f が機能せず、代わりにデータベース検索の結果リストが表示されます。
    • ユーザーが入力しても、ページが最初のヒットにスクロールしません。
    • 検索語句がすでに画面内にある場合のみ、ハイライトされます。
    • 「UX」のように短すぎる用語の検索を受け付けません。
    • 次のヒットを表示するために Ctrl+g を受け付けません。
    • ページ内に用語が見つからない場合でも、Ctrl+f が表示しないはずの無関係なトピックの結果を表示してしまいます。
  • なぜ機能が壊れるのかはユーザーには全く見えませんが、非常にイライラします。ページ内検索の機能が説明もなく奪われたと感じるのです。
  • 「Ctrl+f をもう一度押せばブラウザ検索になる」と伝えても、実際に存在する投稿が見つからないため、助けにはなりません。

根本原因

これは単なる見た目の問題ではなく、Discourse が根本的に修正しなければならない基本的な使いやすさの問題です。つまり、会話全体がブラウザの DOM 内にあるという錯覚ですが、実際には動的に読み込まれているという点です。

トピックに 20 件以上の投稿がある場合、Discourse は必要に応じて投稿をブラウザに送信します。1000 件以上の返信があるスレッドを表示しても、DOM の大部分が空のスタブであるため、サーバーへの負荷はほとんどかかりません。これは素晴らしいアイデアですが、Ctrl+f が不思議と機能しなくなる原因でもあります。

私はこの錯覚をなくすことを提案しているわけではありません。それは価値があると思います。Discourse が、40 件程度の投稿で任意に分割された会話という古い方式を捨てたのは正しい判断でした。

Discourse は、この錯覚をシームレスにするために、より良い対応をする必要があります。

解決策

正直なところ、最適な解決策はわかりませんが、役立つかもしれない考えをいくつか提示します。

意図的に錯覚を破る

まず、Discourse がデータベース検索に切り替えることで錯覚を破る場合の、妥当な簡単なアイデアをいくつか挙げます。

  1. ユーザーに状況を知らせる。ブラウザの検索ボックスが通常表示される場所に、お詫びと説明の小さなメモを表示します。
    • 「申し訳ありませんが、このトピックには 1002 件の投稿がありますが、ブラウザには 7 件しか読み込まれていません。そのため、『ページ内検索』は機能しない可能性があります。それでも試したい場合は、もう一度 Ctrl+f を押してください。」
  2. ユーザーに多少の制御権を与える。ユーザーが Ctrl+f を押したときにボタンを表示し、ユーザーがトピックの全投稿のテキストを DOM に手動で読み込めるようにします。
    • ブラウザに一度にキャッシュできる投稿が 100 件という制限のため、それが不可能と判断される場合は、トピックの表示方法を従来のページ分割方式に戻すボタンを表示します。
    • 「Ctrl+f と併用できる方法でこのトピックを表示するにはここをクリックしてください:[Page 1] [2] [3] [4] [5] [6] [7] [8] [9] […] [>>]」
  3. デフォルトの切り替えポイントを 20 件から 100 件に引き上げる。Discourse はすでにその数の投稿を DOM にキャッシュできるため、変更はそれほど難しくないかもしれません。

錯覚の修復

もちろん、上記のアイデアは不恰好であり、応急処置的なものと捉えています。最終的に最適な解決策は、Discourse が人々が期待する動作で Ctrl+f を実装することです。ブラウザが行うインタラクティブな検索を Discourse で再現することは非常に価値がありますが、難しいことだと思います。

ただし、(比較的)シンプルな解決策があるかもしれません。

DOM からテキストを削除しない

Discourse にとっての最善の解決策は、投稿からメディアオブジェクトのみを削除し、テキストは削除しないことです。そうすれば、Ctrl+f を「乗っ取って」データベース検索に置き換える必要はなくなります。

ページ内検索はテキストのみを検索するため、ブラウザが検索するために DOM 全体をロードする必要はありません。テキストは送信しても非常に軽量です。特に HTTP サーバーで gzip 圧縮が有効になっている場合です。また、テキストは Web ブラウザのメモリをあまり消費しません。

皆さんの方がよくご存知かと思いますが、いくつか推測します。

  • 投稿の平均サイズ:5 KiB のテキスト
  • トピックの平均長さ:50 件の返信
  • 転送するテキストの平均量:250 KiB。これは妥当な範囲と思われます。

もちろん、応答性のためにはすべてのバイトが重要です。私の見積もりが外れていてテキストのサイズが問題になる場合は、ページの重要な部分が送信された後に、DOM にテキストを埋め込むことをバックグラウンドプロセスとして行うことができます。ユーザーが Ctrl+f を押した時点で DOM が完全にテキストで埋められていない場合、メーターが表示され、ユーザーに待機を促し、テキストが流入するにつれて進捗状況を表示します。

感謝

Ctrl+f が Discourse が作り出した錯覚を壊すという深刻な問題ではありますが、Discourse の開発者が最初にその錯覚を作り上げた素晴らしい仕事には感銘を受けました。彼らがこの問題に対する適切な修正策を見出すと確信しています。

私の提案を検討してくださり、ありがとうございます。

敬具

Mx. F.N.

「いいね!」 3

UX がここでフラストレーションを感じさせ、意外に思われるという点に、私も同感です。30 トピックほどのシンプルなスレッドで上下にスクロールしようとするときのぎこちなさも、私にとっては同様です。これは Discourse について私が恥ずかしく思う点の一つです。

小〜中規模のスレッドでの優れた UX と、大規模スレッドでの破綻を防ぐことのバランスが本当に適切なのかどうか、疑問に思います。私のプロジェクトでは、非常に大きなスレッドがそれほど問題になることはまずないため、それらのニーズによって UX が損なわれているのはフラストレーションが溜まります。

現在のアプローチを制約している真の問題は、Android でのレンダリング時間にあると以前読んだ記憶があります。もしそうだとすれば、一部のデバイスの制限に基づいてすべてのデバイスを制限してしまうのは残念です。

開発者が以下をカスタマイズすることが妥当に可能かどうか、ぜひ知りたいです:
(1) 1 チャンクあたりのトピック数(例:デバイスごとに可変)
(2) すでにレンダリングされたトピックを非表示にせず、表示し続けること(現在のトピックのアンロードにより、トップへ戻るスクロールがぎこちなくなっています)

この分野は非常に複雑で、多くの労力がすでに注がれているにもかかわらず、完璧な解決策が存在しないことを理解しています。

「いいね!」 1

このスレッドでは多くの良いアイデアが出ていますが、現在の(まだ)実装はひどいものです。
それをしないでください。強力なショートカットを上書きしないでください。古い掲示板のアプローチで複数の検索ボタンを使用する方が、まだアクセスしやすいです。トピックを検索する良い方法を見つけるか、関連コンテンツをすべてDOMにロードするようにユーザーに任せる(これもひどい)かのどちらかにしてください。共同創設者の1人が最良のアドバイスをしました。「2回押す」ということです。私たちはもっと賢いようです…