Discourseは初めからEmberアプリでした。
構造の一部を変更し、Ember Componentsに標準化しているだけです。
説明させてください：
「いいね！」 5
思いついたのですが、まだ粗削りですが、他の人の意見を聞かずに発展させすぎる前に、皆さんに共有しておきたいと思いました。
Discourseに、返信が一定のしきい値に達するまでスレッド形式のディスカッションを可能にし、その後、返信をリンクされたトピックに強制するか、強く推奨するようにすることはできないでしょうか？
私にとって、これはDiscourseが何になりたいのかという問題になります。もし純粋に長文で集中した会話をしたいのであれば、現在のモードはうまく機能するように思えます。しかし、イベントやユーザーディレクトリがあり、人々がお互いに交流するコミュニティプラットフォームになりたいのであれば、短文で、ほとんど雑談のようなやり取りを追加することから利益を得られるのではないかと思います。
例
私はポッドキャストのエピソードを自動的にDiscourseに投稿しています（会社がそれを好むかどうかわからないので、意図的に小文字にしています、笑）。エピソードによっては5〜10分ですが、3時間以上のものもあります。
3時間のポッドキャストの場合、人々がそれに集中したディスカッションをすることはほぼ不可能だと思います。なぜなら、ある人は00:06:00についてコメントしたいかもしれませんが、他の人は01:34:24について、さらに他の人は02:33:50についてコメントしたいかもしれません。多くのコメントは、「この部分を引用して『へえ、そう考えたことはなかった』」とか、「この部分を引用して『これには強く反対する』」とか、単に異なる部分を「いいね」したり「100%」したりするだけかもしれません。
これらの短いコメントは、コミュニティに多くの価値をもたらすことができると信じています。それは、人々が貢献しやすくするだけでなく、ディスカッションの種をまくことにもつながります。おそらく、「これには強く反対する」というコメントを見て、さらに続けたいと思うかもしれません。もし続けたいと思えば、少し感情的になって、もっと深く掘り下げたいと思うかもしれません。そして、相手もさらに深く返信します。その時点で、スレッドが扱いにくくなると思います。
しかし、その時点でソフトウェアが「ねえ、もっと深く掘り下げるためにリンクされたトピックを開始してください」と言ったらどうでしょうか？
雑談 vs 長文
スレッド形式のディスカッションは雑談に適しており、線形形式のディスカッションは長文に適していると思います。そして、FB、IG、HN、Redditなどのスレッド形式の世界が線形形式のディスカッションを作成するのは非常に難しいかもしれませんが、Discourseのような線形形式のものが、最初のスレッドを追加し、長くなりすぎたら線形形式に分割するのは比較的簡単かもしれません。実際、Facebookには最大ネストレベルがあり、それ以降は会話が線形形式になると思います。
わかりませんが、Slackがこれを試して失敗したのかもしれません（笑）。
何か考えはありますか？
「いいね！」 1
それはDiscourseの仕組みではありませんか？ちょっとしたおしゃべりはチャットでスレッド化でき、長文のディスカッションはトピックで行うことができます。
チャットで始まる場合はそうですが、ブログ記事のようにネストされたコメントがあるものから始まる場合はそうではありません。
私が提案している出発点は、Facebookの投稿やInstagramの投稿、あるいはRedditの投稿のようなものに似ていますが、あなたが提案しているものは、グループ名や非常に高レベルのトピック領域を中心に、会話が絶え間なく続くWhatsAppグループやその他のグループチャットのようなものに似ていると思います。
したがって、Slackは高レベルのトピック領域を持つグループチャットに似ているため、私が提案しているものはSlackよりも似ていないかもしれません。ただし、Slackは投稿ほど具体的なトピックではありません。
「いいね！」 1
投稿ごとに返信アイコンの隣に（戻る？）返信としてのリンク付きトピックボタンを追加するだけで、スレッディングの要望の一部が満たされるのではないかと思います。スレッド（新しいトピック）は、会話の中で一部の人だけがフォローしたいと思うような興味深いことを言いたい場合にのみ役立ちます。
もう1つの点は、スレッド/新しいトピックが発生したことを示すリンクまたはヒントを残すことかもしれません。現在それがありますが、新しいトピックが分岐した場所にはありません。
したがって、投稿に応答してリンクされたトピックがあった場合、OPの下にあるものだけでなく、返信アイコンツールバーの下にちょうどそれのようなリンクがあるでしょう。
「いいね！」 5
スレッド内でも述べましたが、活発な議論を追っている場合、スレッディングは悪夢です。全体を見たのか、それとも重要なものを見落としているのか、決してわかりません。スレッディングは、完了したアーカイブ済みの議論にのみ使用できます。UIには、直接上の投稿に返信している場合でも、「投稿への返信」はすべて表示される必要があると思います（最後に確認したとき、これは設定で「オフ」がデフォルトになっていました）。
「いいね！」 2
私はRedditや他のコミュニティでスレッド形式のディスカッションを使用しましたが、うまくいきました。議論を読み続けるために別のページを読み込む必要があったこと、そしてそれが数レベル後に発生するものがいくつかあったことが好きではありませんでした。また、深くなりすぎたときに水平スクロールしなければならなかったこと、そしてレベルが多すぎると小さくなりすぎたことが好きではありませんでした。しかし、それらを解決するオプションはあります。私たちは今、より多くの経験を持っています。
しかし、月に20億人がRedditを使用しており、そのうち14億人がコメントシステムを使用しています。彼らがそれについて不平を言っているのを見たことがありません。
私はDiscourseをテクニカルサポートに使用しましたが、それはうまくいきました！しかし、ディスカッションフォーラムが欲しいのです。そして、他のコミュニティが持っているスレッド形式のディスカッションが本当に好きなのはそこで、Discourseでもそのオプションが欲しいのです。以前にも述べたように、可能な限り協力します。
「いいね！」 2
それは、Discourse をコメントシステムとして使用するという私の計画の一部です。コメント全体への返信（記事全体への返信とは対照的に）への返信が新しいディスカッションを発生させたという兆候がある場合、関係者はディスカッションをフォーラムの新しいトピックに移動するように促されます。新しいディスカッションが開始されたことを示すロジックは非常に基本的なものでも構いません。たとえば、投稿への直接の返信が 2 回あった後、次に誰かが投稿の「返信」ボタンをクリックしたときに、投稿エディターの上にリンクが表示され、新しいトピックを簡単に開始できるようになります。 「スレッド」の他の参加者は新しいトピックに招待されます。
この場合、コメントは通常のコメントシステムのようにウェブサイトで生成されます。関連するディスカッションは Discourse 上でのみ発生しますが、ウェブサイトのコメントからリンクされます。
「いいね！」 3
そして、これらすべてが、私にとってスレッディングを非常に困難にするものです。たくさんの小さな問題の積み重ねです。
主な問題の解決策は何ですか？スレッドモデルでは、何かを見逃していないことを確認するために、定期的に議論全体をスクロールし直す必要がありますか？
私は小規模なFOSSコミュニティ（私を含めて一貫して3人のユーザー、さらに時々参加する約6人、そして時折の通りすがり）を管理/モデレートしており、スレッドプラットフォームで運営されています。1ページ未満の議論で何かを見逃した回数が、このすべてに対して私をうんざりさせています。
Redditは、その巨大な勢いと参入障壁の低さで生き残っています。その読書体験はインターネットの脇の下です。
「いいね！」 2
それはあなたの意見であり、それで構いません。私はスレッド表示が好きです。そして、ユーザーが嫌うことに対処できると信じています。
プラグインAPIがスレッド表示をサポートしていれば、プラグインに追加して無料で提供します（必要に応じて事前の資金援助があれば）または、財政的支援が必要な場合は販売します。現時点ではAPIについてはわかりません。以前にオープンソースや無料製品を開発したことがありますが、構築や維持にはコストがかかる場合があります。
それは公平です。「このスレッドの更新を通知する」オプションを設けることができます。創造的な解決策は存在します。ソフトウェア開発者として、私はテーブルの片側からそのようなことをよく聞き、反対側のテーブルで解決策を見つけなければなりません。しかし、ユーザーエクスペリエンスが悪いからといって、アプリ全体を捨てたりはしません。そのエクスペリエンスを向上させる方法を見つけます。おそらく、スレッド表示が答えではなく、別の答えがあるのかもしれませんが、私自身の謙虚な意見では、Discourseの単一トピックデザインは、Redditのようなコミュニティで見られる複数の回答と複数のコメントの議論ほど常にうまく機能するわけではありません。
新しいチャットスレッドはそれに対処しようとしているようですが、YouTubeのようにフラットな議論であり、保存されないと聞きました。YouTubeでは、数回のチャットスレッドコメントの後では、フォローするのが簡単ではありません。したがって、それらは私にとって答えではありません。
Redditなどでは、トピックが提示され、複数の議論が形成されます。それらの議論を個別のページ読み込み投稿に送信するのは、私の意見では読みやすくありません（ページを読み込み、読み、戻って過去のページを再読み込み - 場所を失う、新しいスレッド投稿を読み込み、読み、戻って繰り返す）。
「いいね！」 1
スレッドの各返信に対して個別の通知が必要ということですか？問題は新しい投稿があることを知らないことではなく、それがどこにあるかを知らないことです。複数ある場合、1つしか表示されないか、一番下にあるものしか表示されません。
スレッド形式のコンテンツは、良い議論を促進するためにどこでも使われているわけではありません。それは、議論を、レコメンデーションアルゴリズムの気まぐれで並べ替えたり隠したりできるモジュール式の部分に変換するからです。そしてそれは、単一の人間ユーザーが大量のコンテンツを持つプラットフォームと対話することを可能にするために必要な要件です。
一度だけコンテンツの一部を表示することを期待し、好きなだけ深く掘り下げることができる場合には機能します。しかし、Discourseのような設定で、何度も同じトピックを開き直して追いつく場合、議論の網を解きほぐすのは複雑です。
「いいね！」 2
@piffy、私にはそうではありません。スレッド形式の議論とのやり取りが、その逆よりも難しいと感じたことは一度もありません。一方、フラットな議論とのやり取りは、会話のトピックが異なったり、2人以上の人が参加したりすると、私にとって認知的に困難になります。
「いいね！」 2
私のポイントは、同じ議論を再訪することについてでした。新しい返信が12件あると仮定します。フラットな議論では、立ち返るべき単一のポイントがあり、その12件すべてを読むことができます。スレッド形式の議論では、返信を伴う12のユニークな会話スレッドが存在する可能性があり、新しい返信を読む前に各コンテキストを再確立する必要があります。
いずれにしても、目標は認知的な単純さではなく、良好な議論を最適化することであるべきです。結局のところ、最も認知的に簡単な選択肢は、議論をまったく読まないことです。
「いいね！」 2
私はそちらの方が簡単だと感じます。インデントがあるだけで、読みにくくなるのではなく、むしろ読みやすくなる理由がわかりません。例えば、私は文書のすべての見出しをインデントしています。https://stackoverflow.com/revisions/46690751/2#:~:text=Run%20code%20snippet-,expand%20snippet,-answered%20Oct%2011 のように。
それはLogical extreme - Wikipedia. であり、単純に無関係です。認知的な困難さは、ここで議論されている他の属性と同様に、無視できないBenefit–cost ratio - Wikipedia を持っているため、他の属性と同様に真剣に考慮されるべきです。なぜあなたがそれを言及したのか理解できません。
「いいね！」 2
インデントの問題ではありません。返信の1つが8ページあるディスカッションの2ページ目にあるという事実です。そこに戻る必要があることをどのように知ることができますか？また、その場所にページ/スクロールする時間をどのように確保できますか？
「いいね！」 1
単純な概念をWikipediaからリンクするなら、論理的極端がなぜ有用なレトリックデバイスであるかを説明しているページを自分で読むべきです。要点は、良い議論にはある程度の認知負荷が必要であり、最適化すべき主要な変数ではないということです。また、個人的にはネストされた議論の方が単一の線形な議論よりもフォローするのがはるかに難しいと感じるので、非常に主観的です。
主な疑問は、フラットな形式とスレッド形式のどちらが良い議論を生み出すかということです。答えはわかりませんが、スレッド形式の議論は通常、トピックの狭くて操作されたビューを提供し、再訪するのが難しいため、議論全体の質に影響を与えると私は感じています。しかし、それは大規模なプラットフォームがしなければならない必要なトレードオフであり、それがいたるところで見られる理由です。
それは有用な論理的デバイスではないため、説明への参照があります。また、その後、それがなぜ有用ではなかったのかを説明したので、なぜ説明を求めているのですか？
以前にそれを明確にしていれば、私はそれに言及しなかったでしょう。同意しますが、誰も異議を唱えなかったので、その関連性はまだ理解できません。
それは解決すべき主な問題ではないと思います。なぜなら、ユーザーがスレッドをフラットまたはスレッド表示で表示するかどうかを選択できるため、各ユーザーは個人の好みに基づいて選択するからです。すべての応答はGUIの下にスレッド表示されているため（応答だけでなく、スレッドの下部にも同様の青い応答機能がある理由です）、それは単にユーザーにそれを公開する問題です。
どの8ページの議論について言及していますか？もしあなたが仮想的なスレッド表示とページ分割された議論を説明しているなら、その問題を解決する方法は、単にスレッドをページ分割しないことです。
インデントについて何が言えないのですか？
「いいね！」 1
記録のために言っておくと、スレッド化を行うプラグインや利用可能なオプションを拡張するプラグインを作成することに反対しているわけではありません。実際、コミュニティのDiscourseプラグインの数は、本来あるべきよりもはるかに少ないと考えています。
私がやっていることは、OPで参照されている投稿に原則として同意することであり、また、スレッド化されたディスカッションがDiscourseのコアチームが時間を投資すべき中核的なアイデアであるべきだとは考えていないことです。
これは私が気に入っている点の一部です。文章の先頭にはアウトラインがあります。
- トピック
- ヘッダー
- サブ項目
- ヘッダー
- サブ項目
- ヘッダー
- サブ項目
- ヘッダー
整理されていて、全体像を把握し、探しているものを簡単に見つけることができます。
私にとって、スレッドディスカッションの既存の欠点はユーザビリティ/UXの問題です。
- ページの再読み込み
- 場所を失う
- 新しいコメントを見つける、または通知される
- ディープスレッド（読むスペースが少ない）
これらは修正が難しくありません。
- 再読み込みせず、ダイアログウィンドウを開くか、データを取得する
- 再読み込みしなければ、場所を失うことはない
- 新しいコメントを動的に読み込むか、視覚的なインジケーター（太字の行）を使用する
- 深さが増すにつれてインデントを減らすか、最大深度を設定する
まったくその通りです。既存の素晴らしいコミュニティ体験の代替ではなく、ユーザーが切り替えられる（またはオプションで有効にできる）補完的な追加機能になるでしょう。
「いいね！」 1