Discourse が気に入っています。私の会社では、あなた方のチームのおかげで、Discourse がコミュニティへと素晴らしい変容を遂げました。
検索ボックスはもうライブ検索機能がないのでしょうか？今日から検索が以下のようになっています：
今回の変更に関連する機能リクエストのトピックを探してみましたが、何も見つかりませんでした。以前の検索機能に戻していただけないでしょうか。
フィードバックをありがとうございます！検索の変更は本当に気に入っていますが、追加のクリックは以前よりも少し手間が増えたように感じます。
もし可能なら、クリックなしで結果を表示しつつ、関連する場合は上部の「すべてのトピックと投稿内」に対してのみこの追加のクリックを維持することはできないでしょうか。
このスタイルは、以前のチェックボックスよりもはるかに気に入っています。
そもそもモバイルビューではライブではなかったのでは？ 
トピック内の「/」を表示している場合に限ります。でも、これも以前からそうだったはずです。
おっしゃる通りです。その件は以前議論されました。残念ながら、私は Discourse をモバイルで 2〜3 回利用しました。
申し訳ありません。私が言いたかったのは、「現在のトピック内で検索する」オプションが新しく追加された（そして多くの場合不要で、おそらく非常に長いトピックでのみ有用だろう）ということです。しかも、それが最上位に配置されています。従来の検索は問題なく機能していました。しかし現在、私はそれを理解できなくなっています。投稿作成中にトピックを検索して追加するためのホットキーが使えなくなっています。
返信ありがとうございます。ライブ検索は素晴らしい機能です。視覚的なスタイルの向上を理由に避ける必要はありません。検索はまずシンプルで高速であるべきです。迅速な検索結果を得るには、素早くアクセスできる検索ボックスが必要です。現在のバージョンの方が優れているとは賛成できません。ライブ検索がなく、クリックが多すぎます。
これに賛成です。今ではトピックを検索し、そのトピック内でさらに検索するのに永遠にかかってしまいます。これは1日に何度も行う作業です。
これは大きな問題だとは思いません。なぜなら、\u003ckbd\u003eENTER\u003c/kbd\u003e キーを押して検索するのは非常に一般的な方法であり、この 2 段階の検索により、より明確な表示が可能になるからです。
第一段階：ユーザー、カテゴリ、グループ、タグ
第二段階：トピック、投稿
いいえ、これは新しいものではありません。以前から機能として実装されており、トピック、カテゴリ、タグ、または自分の PM（プライベートメッセージ）内にいる場合、その特定のコンテキスト内で検索するためのチェックボックスが表示されていました。新しくなったのは、そのチェックボックスが「このトピック内のキーワード」という行に置き換えられた点です。
これは正当なご指摘です。私はこの検索機能の変更に取り組んでおり、この点が課題として挙げられることを強く予期していました。ちょうど上記で @Don が指摘している通り、Enter キーを押すことで全トピックを検索できます。また、上下矢印キーを使って検索結果を移動することも可能です。したがって、現在のトピック内で検索する場合、↓ キー + Enter キーを押す必要があります。
既存の検索の重鎮ユーザーにとって、この調整が容易ではないことは十分理解しています。変更への慣れが難しく、以前よりも遅く感じられるためです。しかし、私たちはこの変更を以下の理由で行いました。
したがって、短い慣らし期間を経て検索機能が快適に感じられることを願っています。それが私たちの目標ですが、変更を行う際、少なからず摩擦が生じることは避けられないこともあります。
検索結果をトピックに追加するための a ショートカットが機能していないという意味でしょうか？私の環境では動作しますが、一時的な不具合（regression）があり、近日修正予定です：以前は絶対 URL が投稿されていましたが、現在は相対 URL が投稿されてしまいます。
このアドバイスのおかげで、「新しい検索機能が大嫌い」から「まあいいや、パフォーマンスへの影響が少ないのは称賛に値する」と考えが変わりました。現在「検索」としか表示されていないプレースホルダーに、このアドバイスが表示されるなら素晴らしいと思います。
おそらくこの点には慣れると思いますが、一つだけ小さなことがあります。
単語を検索します。
すべてのトピックと投稿をクリックします。
唯一の結果をクリックすると、そのトピック内で検索したいのですが、クリック後に「このトピックを検索」が表示されません。
ハンバーガーメニューを押すと「詳細検索」に移動しますが、検索語の後にスペースを入れるしかない方法で、このトピックを検索するプロンプトが表示されます。
もしかしたら私の記憶違いかもしれませんが、トピックをクリックすると、検索語を変更せずにそのトピック内で検索するプロンプトが表示されたように思います。
表示されない理由は、検索パネルが前の画面からのキャッシュされた結果を表示しているためです。入力フィールドに新しい文字列を入力すると、「このトピックを検索」オプションが表示されるはずです。
なるほど、このアップデートの意図は理解できますが、私はまだ判断がつかないところです。
私の想定される動作は以下の通りです：
どちらの場合も、以前と同様に、2 回クリックせずにその範囲の結果を即座に表示してほしいです。1 クリックで範囲を変更するのは問題ありません。
「Enter キーを押す」というハックは確かに機能するかもしれませんが、UX デザインにおいて「見せることで伝える（show, don’t tell）」や「考えさせない（don’t make me think）」という原則と競合してしまいます。
以前の検索は、より素早く、レスポンシブで、直感的に感じられました。今は自分の行動について考えさせられるようになりました。
わかりました。スペースを入力する追加の手順が必要ですね。ご返信ありがとうございます。
その通りです。
この「ハック」は、ほぼすべてのウェブサイトで採用されていると思います。Google、YouTube、Facebook などです……これらは検索にいくつかの提案を追加しているだけで、処理自体は Discourse の検索と同じです。Discourse としては異例かもしれませんが、それは単なる習慣です。新しい検索の使い勝手については、コミュニティから非常に好意的なフィードバックをいただいています。これによりパフォーマンス面でも良い効果が得られると考えています。
返信ありがとうございます。
うっとうしいヒントやタグ、ユーザー一覧は、検索機能が（追加のユーザー操作が行われるまで）機能しなくなっているという事実から注意をそらすためにのみ表示されているように思えます。
はい、Enter キーをもう一度押すのは難しくはありません。しかし、なぜ特別な検索項目が画面に表示されるのでしょうか？一般的なユーザーがそれらを使うことは通常あるでしょうか？私はそうは思いません。現在、ポップアップするタグや未知のユーザー名が大量に降り注ぐ様は、押し付けがましいマクドナルドのキオスクのようです。私はフライドポテトを求めていないのに、クリックするたびにそれを勧められます。
正直に言えば、Discourse がパフォーマンスの問題によりライブ検索を無効にせざるを得ないことを事前に告知するピン留めトピックがあれば、同情できたでしょう。ホスティングを所有している人々は、当面は現在の設定のままのバージョンを使用する選択肢があります。
しかし今では、beta6 や beta5 へのロールバックは不可能です。再構築がクラッシュしてしまいます。
Ctrl+Enter は何をするのでしょうか？それが 3 回目に現れたときにクリックしました。検索ボックスにはまだ何も入力されていなかったため、エラーメッセージが表示された空白の画面にリダイレクトされました。
私は本日、クロスリファレンスリンクのバグについてバグレポートを送信しました。おっしゃる通り、そのような問題が存在します。私はホットキーについて書きましたが、追加のクリックが必要になり、キーボードの矢印キーが正しいオプションを選択していることを確認するために画面から注意を逸らさなければならないため、現在はあまり効果的ではありません。以前は、現在のトピック内でのデフォルトの検索が無効になっており、それを有効にしてアクセスするのは簡単ではなかったため、ユーザーは気にしていなかったのです。
ああ、なるほど。Discourse の検索機能そのもので、ほとんどのサーバーが既に問題を抱えていたのでしょうか？
私たちは、サーバーが実施した検索作業の大部分が無意味なものであったことを確認しました。サーバーは膨大な量の検索作業を行っており、一部のサイトでは、総コストの観点から2番目または3番目に高額なルートとなっていました。
私たちのサーバーは非常に高速であり、この負担の多くを吸収できます。一方で、セルフホスティングユーザーにとっては、そのコストがあまりにも高すぎました。
これは私たちの計画には含まれていません。確かに、デザインを微調整・改善し、ヒントをより豊かにするなどを行う可能性はありますが、この船を港に戻すつもりはありません。
Cheeseの位置は変更されました。この状況に14日間慣れ、さらなる改善のために微調整についてフィードバックをいただくことを強くお勧めします。
Cheeseが元の位置に戻ることはありません。
ご清説ありがとうございます。問題は技術的なものではありません。SaaS オーナーとして、Discourse の有料プランは、ライブ検索中の無意味な検索に対しては高すぎます。ユーザーの動き一つ一つにコストがかかります。Discourse はオープンソースであるため、メンテナーのコスト負担を減らすべきだというご意見には同意します。コミュニティメンバーとして、開発チームを支援する義務があります。
いずれにせよ、以前の検索バージョンでは設定が可能でした。現在では、タグ別やユーザー別などの一部のオプションが、以前はデフォルトで無効だったものが有効になっています。
私は、このフォーラムに参加していないユーザーの気持ちを代弁しています。ここでの活発なユーザーの多くは、セルフホスト環境から来ている管理者、開発者、デザイナーだと推測されますので、私のフィードバックが役立つことを願っています。
直感的には、検索ボタンは検索ボックスの右隣にあるべきです。しかし、実際には「検索リセット」ボタンが配置されています。私は今になって、そのボタンの存在に気づきました。
驚いたことに、Google も同様の状況です。Google にも、私がこれまで存在に気づかなかった奇妙な「検索リセット」ボタンがあります。ただし、Google の場合は少なくとも、検索ボタンと検索結果を明確に区別しています。
Discourse は UX の観点から多くの点を正しく設計していると思います。しかし、いくつか奇妙な点もあります。変更が改善になることもあれば、単なる変更で終わることもあります。
この根本原因は、明確に定義されたガイドラインに基づいたデザインシステムが存在せず、場当たり的に変更が行われていることだと考えます。これは、創設者たちが長年培ってきた直感的な知識から成長してきたものです。UI 決定の背後にあるパラダイムは明確に言語化されておらず、ほぼ独裁的な形で決定されています。
デザインシステムは完全に独裁的なのではないでしょうか？特にこの変更に関して、デザインシステムがどのようなガイダンスを提供できたでしょうか？
具体例はありますか？もし今後そのようなことがあれば、Meta で質問してください。私の知る限り、すべての変更には何らかの理由があります。ただし、変更の理由をコミットメッセージ以外の形ですべて発表しているわけではないのは事実です。
最終的な判断を誰かが行わなければならないため、Discourse に何を組み込むかについては「準独裁的」な側面がありますが、多くの要素が考慮されています。パフォーマンスについてはすでに言及されましたが、顧客からのフィードバックも大きな役割を果たしています。Discourse は彼らがいなければ存在しなかったからです。また、自己ホスト型のコミュニティ全体からこのようなフィードバックを集めるために Meta を運営しており、大規模なサイト（特に他プラットフォームからの大規模な移行先）の #site-feedback カテゴリを潜りながら、一般ユーザーの状況を把握しています。
