ネストされた返信の紹介

意味のある対話は、部屋にいる全員が互いの考えを聞き届けたときに実現します。Discourse において、フラットで直線的なタイムラインはそれを可能にする最良の方法でした。しかし、フラットな形式がすべてのコミュニティに適しているわけではありません。大規模で動きの速いフォーラムでは、単一のタイムラインに数千件の返信が並ぶため、誰一人として追いつくことができません。そのため、今年は慎重に完全にネストされた返信ビューの実験を行ってきました。この形式は、フラット形式では収まりきらなくなったコミュニティに非常に適していると考えています。

もともと実験的なプラグインとして始まったこの機能は、Discourse に直接組み込まれるプロジェクトへと発展しました。以下は、現在の実装例です。

特定の投稿へのリンク(共有リンクや通知から)がクリックされた場合、単一のスレッドビューが表示されます。

サイトで有効にする

この機能を有効にするサイト設定は、管理画面で利用可能です。「ネストされた返信」セクションに移動し、機能の有効化、デフォルトのソートモード、最大ネスト深度などを制御できます。

ロードマップ

現時点では、ネストされた返信は初期段階にあります。ロードマップはまだ完全に具体化されていませんが、今後実施予定の事項は以下の通りです。

  • モバイル環境での体験の改善

  • ネスト表示時のトピックタイムラインの再設計。現在、ネストされた返信モードではトピックにタイムラインが表示されません

  • トピックリストの「Hot」に似た、投稿の経年劣化を考慮した少なくとも新しい並べ替えモードの追加

制限事項

  • カテゴリでネストが有効化されても、既存のトピックはフラットモードのままです。各トピックは管理画面のレンチアイコンから個別に切り替え可能ですが、現在、既存のカテゴリ全体をネストモードに変換する方法はありません。

フィードバックをお待ちしています

この機能の開発を進めるため、皆様のご意見や実際の利用体験が必要です。もしこの機能があなたのコミュニティに合いそうであれば、ぜひ試してみてください。あなたやユーザーの感想を聞かせてください!

「いいね!」 36

OMG、最高!タイミングも完璧ですね。今夜、フォーラムを新しいサーバー(2 コンテナ構成)へ移行する予定で、数週間後にレギュラーシーズンやスポーツプールが始まるのを待ちきれません。これも良いテストケースになるでしょう。フラット形式と埋め込み形式の両方のディスカッションオプションが使えるなんて、とてもワクワクします。@markvanlan さん、そしてチームの皆様、ありがとうございます。

何かが壊れる様子を見るのも楽しそうですね :laughing:

「いいね!」 13

補足ですが、ツリーの複数の分岐で新しい返信がある場合、スレッド表示では一度に一つしか表示されていないようです。未読数が1ずつ減るたびに、何度か確認し直す必要がありました。

Discourse のアップデートを行っても、この機能を有効にするオプションが見つかりません。

セルフホスト環境なので、それが原因かもしれません :sweat_smile:

Discourse インスタンスを更新し、すべてのサイト設定に移動して「nested」を検索してください。

新しいトピックを作成する際、トピック管理レンチでオン/オフを切り替えることができます。

カテゴリ設定タブで有効にすれば、カテゴリのデフォルトとして設定することも可能です。

私もセルフホスティングを行っていますが、完全に動作しています。

「いいね!」 10

あなたの効率性に感謝します :+1:

「いいね!」 1

既存のトピックを「投稿の選択 > 一括操作」オプションで一括変更・更新することはできますか?

あるいは、Rails コンソールで既存のトピックすべてを一括更新するオプションはありますか?

「いいね!」 2

はい、一括操作で切り替えが可能です :slight_smile:

「いいね!」 3

了解しました。数万のトピックを持つカテゴリで一括切り替えが実現可能かどうかは確信がありません。Rails のバッチ処理やバッチ変換ジョブが選択肢になるでしょうか?:thinking:

また、これは元に戻せるのでしょうか?スレッド化されたトピックをフラットなトピックに戻すことは可能でしょうか?

「いいね!」 3

はい、その意見に同意します。これは現時点での「制限」であり、今後も引き続き検討していく事項です。

カテゴリが有効化されている際に、過去のトピックを変換しないことにした大きな理由は、ユーザーの行動パターンが異なる可能性が高いからです。フラットモードでは、さまざまな 返信 ボタンはそれほど重要ではありません。投稿はトピックの最後に追加されます。ユーザーが、ネストされたビューに対応する「正しいボタン」を意識的に押しているとは限りません。

基本的には、管理者が過去のトピックに対してこの機能を有効にしたところ、会話内容が読めなくなってしまうことを懸念しています。引き続き検討していきます。私が思いつく最も簡単な変更は、カテゴリ設定を切り替えた際に、「既存のトピックにも適用しますか?」というモーダルポップアップを表示することです。

「いいね!」 7

すごい!これを見れて本当に嬉しいです!:clap:

「いいね!」 2

私は以前から「返信」のラベルをより具体的にするべきだと感じていました。そのため、少し前 にカスタム CSS を使用して文脈を追加しました。

スクリーンショット

CSS
/* オリジナルの投稿(トピック)の「返信」ボタンにテキストを追加 */
#post_1 nav.post-controls {
  .actions {
    button.reply {
      span.d-button-label:after {
        // 「返信」の後にこの内容を追加
        content: " to this Topic";
      }
    }
  }
}

/* 2 番目以降のすべての投稿(コメントと呼んでいます)の「返信」ボタンにテキストを追加 */
nav.post-controls {
  .actions {
    button.reply {
      span.d-button-label:after {
        // 「返信」の後にこの内容を追加
        content: " to this comment";
      }
    }
  }
}

/* ページの末尾に表示される青色の「返信(トピックへ)」ボタンにテキストを追加 */
#topic-footer-buttons {
  .topic-footer-main-buttons {
    button.btn-primary.create {
      span.d-button-label:after {
        // 「返信」の後にこの内容を追加
        content: " to main Topic";
      }
    }
  }
}
「いいね!」 2

このソリューションの問題点は、ユーザー設定で英語以外の言語を選択しているメンバーの UX では翻訳されないことです

「いいね!」 2

興味深いですね…

これは、すべての既存トピックを変換する前に、まずコミュニティで個別にテストすべきだという示唆でしょうか?:thinking:

数万のトピックに対応できれば、それは機能するでしょう。

ただし、一度実行すると元に戻せないことが非常に明確に示される必要がありますね😅


この機能は、まずメタ(meta)で実装されるのでしょうか、それとも https://try.discourse.org で実装され、本番環境外でテストできるようになるのでしょうか?

「いいね!」 2

もし私がそのコミュニティの運営者なら、まず個別にテストすると思います。一方で、コミュニティ全体で有効にすれば、より早く価値のあるフィードバックが得られるかもしれません :wink: 。冗談はさておき、個別にテストするのは賢明だと思いますが、ここでは破壊的なデータ移行は発生しません。安全に有効化・無効化が可能です。ここで下す決断によって、どちらの方向にもロックされることはありません。

この部分については、たぶん偶然にもすでに答えちゃいましたね!ネスト機能を有効にすると、データベース内の各トピックに対して nested_topic レコードが作成され、祖先ツリーに沿って返信数を計算するジョブが開始されます。ネスト機能を無効にすると、その nested_topic レコードが削除され、フラットな状態に戻ります。問題はありません。

このカテゴリで自由に試してみてください:

「いいね!」 3

これはなぜ一般ユーザーではなくスタッフのみで切り替えられるのでしょうか?Meta に実装されると聞いたときは、投稿タイプのメニューに追加されるものだと思っていましたが、この切り替えはスタッフのレンチアイコンの奥に隠されています。

具体的なユースケースがあるかどうかはわかりませんが、投稿の投票機能と同じように実装されるものだと思っていました。

「いいね!」 2

これはユーザーの判断や好みに委ねるべきではありません。サイトの運用方針は管理者が決定するものです。2 つのパラダイムは非常に異なり、同じコンテンツに対してユーザーがこれほど異なる方法で相互作用すべきではありません。少なくとも、それが私たちの現在の考えです。

「いいね!」 9

広告ブロックはこの構造では正しく機能せず、トピックの変換時にバグが発生し、画面のアイテムが消失してタイトルのみ編集できる状態になる傾向があります。

素晴らしい機能ですね!ただし :thinking: 、ネストされたレイアウトそのものよりも、Top / New / Old によるソート機能に興味があります。私は以前、モバイルアプリ(Discourse クライアント)で同様のソート制御を実装したことがあり、現在の手法でも機能はしているのですが、できればこれをネイティブでサポートしたいと考えています。以下にその方法を示します。

ソースを確認したところ、GET /n/{slug}/{topic_id}.json?sort={top|new|old}&page={n} を呼び出すと、選択されたソート順でネスト表示されたトピックが返ってくるようです。質問ですが、既存の /t/{slug}/{topic_id}.json エンドポイント(例:?sort=top)を通じて、ソート機能のみを公開するご意向はございますでしょうか?そうすれば、フラット表示のクライアントも恩恵を受けられます。

ソート機能がフラット表示でも利用可能であれば、サードパーティ製のクライアントはネスト表示のレンダリングモデルを採用しなくても、オプションで利用できるようになります。

ネスト表示のデータ構造(ルート投稿+遅延読み込みの子投稿)こそがサーバーサイドでのソートを可能にしていること、そしてフラット表示はページネーションの仕組みが異なることは理解しています。パフォーマンス上の理由から完全なフラットソートが現実的でない場合でも、?sort=top&limit=N のようなオプションがあれば、「ハイライト」表示を実現するのに十分です。

「いいね!」 1

クリス・プラットの驚いた笑顔の反応

「いいね!」 1