oshyan
(Oshyan Greene)
1
Discourse には、特定のフォーラム内の他のトピックへのリンクをより迅速に作成する方法が必要だと考えます。もちろん、コンポーザーには既存のリンクボタンやショートカットが存在し、非常に優れた方でトピックの正確な URL を知っている場合は、リンクダイアログを使わずにリンクを作成することも可能です。しかし、他のアプリが示しているように、より速く、簡単で優れた方法が存在します。それは、インラインで検索とリンクを行うダイアログを呼び出すことです。
Discourse にはすでに、プロフィール向けの @ リンク/検索機能や、ハッシュタグ向けの # リンク/検索機能という先例があります。したがって、私は単に、トピック向けの検索とリンク機能を追加することを提案します。これは、@ ユーザー検索と同様の非常に最小限のアプローチで、コンポーザー内で入力したテキストに基づいた即座にポップアップするインラインのトピック検索を行うもので、タイトルやその他のコントロールのフィールドは持たないでしょう。これはリンクを除いて @ 検索と全く同じように動作します。リンクの確定にはキーボードを使用し、最初のオプションが自動的にハイライトされます。
これについて最近普及しつつある構文は「ブラケットリンク」、つまり [[link-to-topic]] です。[[ と入力すると、ユーザー検索やハッシュタグ検索と同様にトピックタイトルの検索が開始されます。もう一つの一般的なアプローチはスラッシュメニュー（/）ですが、これは通常、複数の機能に使用されます。呼び出し方は問わずとも、トピック間のリンク作成を非常に高速かつ容易にするものであり、私は個人的に、既存の関連コンテンツへの参照を促進するという点で良いことだと考えています。
この特定の構文における主な課題は、現在サポートされているウィキ構文とは異なるが、同時に類似しているという点です。しかし、ウィキリンク構文は、実際には二重ブラケット [] 構文もサポートしているシステムで使用されていますが、これはカスタムテキストが必要なリンクに特化して使用されます。したがって、一つの選択肢として、同じ区別を採用し、トピックタイトルをリンクテキストとして使用するトピックへのリンクには二重ブラケットを、カスタムタイトルには従来のウィキリンクを使用するという方法があります。別の選択肢としては、リンク構文全体を変更することも考えられますが、それは魅力的ではないでしょう。3 つ目の選択肢として、リンク検索を呼び出す別の文字セットを使用する、つまり他のインラインリンク構文を採用するという方法もあります。
実装方法には特にこだわりませんが、インラインで検索してリンクを貼れるようにしたいのです！これは、すでに優れたコンポーザーと一般的な利便性機能を持つ Discourse にとって、素晴らしい追加機能になると考えます。
とはいえ、既存のコンポーザー機能は非常に優れており、これは単なる利便性機能であり、特定のユーザー層向けの機能であることは理解しています。有用であることに合意があったとしても、これは明らかに優先度が低い機能です。
「いいね！」 6
tmomas
(tmomas)
2
投稿を選択して新しい/既存のトピックに移動する際に、似たような機能は存在します。正直なところ、現在の形では非常に面倒です：
- 検索に時間がかかる
- トピックのタイトルを正確に（大文字小文字などを含め）入力していても、検索で目的のトピックが見つからない
- 検索でトピックが見つかり、選択しても、選択を確認する前に検索が再実行される。選択が失われ、検索結果に選択したトピックがもう表示されなくなる
私の経験では、上記とは全く逆です。
正しいトピックを見つけるのは、標準的な検索機能を使った方が早いです。
「いいね！」 1
Don
3
こんにちは、Oshyanさん 
素晴らしいアイデアだと思いますが、いくつか懸念点があります。
トピックのタイトルは一意ではないため、現在トピックを検索する際には、それをより明確に識別できるようタグやカテゴリなどの追加情報が表示されています。しかし、インライン表示だと情報が詰め込みすぎてしまう可能性があります。また、検索結果に一致するトピックが多すぎる場合、インラインでのフィルタリングが難しくなることもあります。
もう一点：
このパネルを使ってリンクを挿入する際、ボタンクリックで選択を確定する必要がありますが、これは非常に便利だと思います。
インライン表示の場合、正しいトピックを見逃してしまうと、多くのテキストを削除する必要が出てくるかもしれません。その結果、現在よりもリンクの形式が崩れるケースが増える可能性があります。
シンプルで高速な方法があるかもしれません。しかし、現時点ではパネル方式の方が高速で、ユーザーフレンドリーだと考えています。
「いいね！」 1
oshyan
(Oshyan Greene)
4
これらはすべて、インラインリンクそのものの問題というより、UI/UX や検索機能の不備に起因する結果のように思えます。もしまだ行っていないのであれば、ご指摘の体験に基づき、「投稿の移動/結合」の既存動作の改善や修正について議論するトピックを立てることをお勧めします。ただし、もし私が提案しているリンク手法の文脈でそうした問題が発生しないと仮定した場合、それでも有用だとお考えになりますか？
インライン検索がツールバーベースの検索とは異なる動作をするとお考えなのはなぜでしょうか？検索と表示の挙動については、完全に同じように動作するはずであり、正しいトピックを見つける・選択する際の利便性や実用性も同等になるはずです。私の希望としては、既存のリンクダイアログとは一線を画し、スピードと使いやすさに焦点を当てたものにしてほしいと考えています。現在の @ 検索のように、小さなコンテキスト結果リストをポップアップ表示させるようなイメージです。結果リストの見た目はリンクダイアログのものと同じでも構いませんが、トピックタイトル入力欄や「OK/キャンセル」ボタンなどは不要です。すでにそれを呼び出すショートカットキーが存在しますから。
リンクが壊れるケースが増える理由が私にはわかりません。検索結果から選択したトピックを確定するには、依然として Enter キーを押す必要があります。
確かに「高速」とは言えませんね。ユーザーフレンドリーであることはあるかもしれませんが、私の提案は既存のツールバーによるリンク機能を「置き換える」ものではなく、上級者向けにより「高速」なリンク方法を「追加」するものです。
もちろん、Ctrl-K（ショートカット）という優れた代替手段はすでに存在します。私は、@ や # のように、インライン構文を使って便利な機能をトリガーできることが好きです。これらも本来はキーボードショートカットや手動入力だけでアクセス可能ですが、現在の動作にはそれ以上の価値があります。リンク機能についても、このアプローチによって同様の価値が得られると提案しています。
「いいね！」 2
Don
5
ああ、わかりました。説明ありがとうございます！
これは高度な機能となり、元の検索パネルを維持する形になりますね。
私にとっては良いアイデアに思えます。
「いいね！」 1
sam
(Sam Saffron)
8
明確な文脈のために、現在ある機能は以下の通りです：
CTRLALTf
対象を検索
DOWN
a
例：In-line topic search-and-linking, e.g. Roam-like bracket links
問題は、この機能を教えるのが非常に難しいことです。しかし、（議論の余地はありますが）[[ 案よりも広範な機能セットを提供しています。
「いいね！」 5
oshyan
(Oshyan Greene)
9
おお、とても興味深くて参考になります！ただ、インライン構文からのアクションとキーボードコマンドからのアクションには、価値のある違いがあると思います。発見しやすさが一つ、速度がもう一つです。
確かに、一度覚えればそのシーケンスを使うのはそれなりに速くなりますが、試しに何度も試してみたところ、[[ ]] 形式のブラケットリンクをサポートする（増えつつある）アプリでの経験に比べると、明らかに遅く、滑らかではないと感じました。これは、新しいやや不自然なキーボードショートカットに加えて、視線や注意の移動が必要になることが一因かもしれません。後者は時間とともにある程度克服できるかもしれませんが（基本的な手の形状から考えると、そこには限界があるように思えます）、メッセージ作成中に注意を移すことには常にコストがかかります。
実は、あなたも高速なリンクを強く望んで、このやや特殊なキーボードショートカットシーケンスを作成されたこと自体が興味深いです（多くの人が使っていたため、もちろんのことですが）。これは、インラインリンクというアイデア自体に一定の価値を見出している可能性を示唆しています…ただ、現時点では私の提案にあまり支持がないという印象も受けます。それでも、明確な障壁があるかどうかは気になります。例えば「ブラケットは別の用途に使っている」「もう一つのインラインハンドラを追加すると、すべてのデータベースクエリが30%遅くなる」「などなど」のような理由があるかどうかです。
とにかく、これが誰かの興味を引くきっかけになれば幸いです。私はまだこの機能をぜひ利用したいと思っていますし、他のユーザーも一度試せば、きっと気に入ってくれると思います（ここにRoamユーザーやObsidian、Logseqユーザーはいますか？）。少なくとも、インライン検索とリンクというアイデアに興味を持っていただけたなら、将来的に何かが形になるかもしれません。
「いいね！」 1
sam
(Sam Saffron)
10
私は、[[ マジック検索が現在のテーマコンポーネントで実用的だと考えています。
唯一の注意点として、補完機能は [[ を削除してリンクに置き換えることになります。これが他にどう機能するかわかりませんが、これでは ]] はほぼ無意味になってしまいます。
また、スペースの境界を超えて自動補完を維持し続けることは、やや混乱を招く可能性がある点にご留意ください。
「いいね！」 2
oshyan
(Oshyan Greene)
11
それは素晴らしいですね！プログラミングを専門としない者として、テーマコンポーネントでどれほどのことが可能なのかは正直よくわかりません（どうやら非常に多いようですが、それが私がDiscourseを愛する理由の一つです）。それはとてもクールですね。
他のソフトウェアでは、[[はリンクが追加された後も保持され、ある程度の価値を保っています。正確に言えば、[[検索は従来のリンクを自動入力するのではなく、専用の内部参照を生成します。複数のアプリケーションがこの参照形式をサポートしているため、Markdownの変種としてポータブルであり、非常に便利です。
とにかく、Discourseにおける[[は、単に慣れ親しんだインラインショートカットであり、幸いにも誤ってトリガーされることはほとんどありません。同様の条件を満たす他のテキストベースのインライン検索呼び出し方法であれば喜んで使いますが、DiscourseとRoamなどの他のアプリとの動作の違い notwithstanding、少なくとも構文を統一することには価値があると感じています。前述の通り、これは事実上の標準となりつつあるものです。
もう一つ思い浮かんだのは、Discourseにはすでに特殊な形式でレンダリングされる内部リンクの同等機能があるということです。それは引用の仕組みです！つまり「post:10, topic:200454」と入力すれば、もちろん私の返信へのリンクになります。このリンク機能は内部トピックへの参照を目的としているため、レンダリング時に自動的にトピックへのリンクとして表示されるようにすることも可能です。これがDiscourseのやり方に合っているのか、それとも合っていないのか、私には判断がつきません…
一方で、すでにこのようなリンク方法があり、これはリンクの検索と選択を呼び出す別の方法に過ぎず、前述の通り既存の@や#検索と非常に似ています。他方では、Ctrl+K、ツールバー、その他のショートカットで呼び出される既存のリンク動作から逸脱することになります。しかし、「post:10」型のリンクは、他のアプリで使われる[[リンクの概念とより似ていると感じるため、もし私の意見が少しでも反映されるなら、そちらに少し傾きます。
もちろん、これはもともとテーマコンポーネントの領域なので、もしかしたら私の意見が反映されるかもしれません！ポップアップ検索から「post:10」スタイルのリンクをテーマコンポーネントで実装できるかどうか、あなたの見解をお聞かせください。
sam
(Sam Saffron)
12
Roam のコンテキストを試してみました。
@codinghorror は過去に何度か、コンポーザーを使用する際、インライン検索が非常に非効率であることに懸念を表明していますが、ドキュメントや特定の範囲に限定されたカテゴリといった文脈では有用かもしれません。
以前、#784 のような構文の導入について議論したことがあり、これは今回の議論と非常に似ています。
Roam の動作は以下の通りです：
[[ と入力します。- 自動的に
]] が補完され、カーソルがその中に配置されます。
[[ ]] の内側に入力すると、自動補完検索が実行されます。例：
-
最終的にリンクを選択すると、完全なタイトルが使用されます（例：[[August 13th, 2021]]）。
-
元のドキュメントの名前変更が自動的に処理され、リンク元のドキュメント内のマークアップも更新されます。
このような動作を実装するには、トピックの名前変更、Markdown エンジンなどに関連する箇所をフックする、Discourse 向けのかなり大規模なプラグインが必要になります。これは複雑な作業が数週間かかるレベルだと考えられます。
現在、以下の機能があります：
「いいね！」 4
justin
(Justin DiRose)
13
興味深い実装として、https://obsidian.md をお勧めします。彼らは Markdown ファイルでこの構文を使用しており、@sam が説明した仕様に似ているようです。
「いいね！」 1
oshyan
(Oshyan Greene)
14
はい、ここから「Roam を例に挙げる」という話が、文字通り受け取ると破綻し始める部分です。 実は私はかなり前に Roam の使用を中止しました。その理由の一つは、インライン検索が全く使い物にならないからです。Obsidian の方がよい例で、現在はフルタイムで使っていますが、試用するにはダウンロードが必要であり、Roam（や Logseq）は不要です。
先に進む前に、このアイデアにこれほど深く関わってくれた @sam さんに感謝申し上げます。この提案が少し突拍子もないものかもしれないことは理解しています。特に、ご自身で想定される作業量のおおよその見込みを教えてくださったことに、心から感謝しています。
その上で強調しておきたいのは、私の提案は Roam や同様の構文を使うアプリから「着想を得た」ものですが、それらの動作をすべて完全に再現しようとしているわけではないということです。
- 結果として得られる Markdown に括弧が残らないため（Roam や Obsidian では括弧が残ります）、括弧の自動補完は不要です。
- Discourse の検索（Ctrl-K リンク検索や Ctrl-Alt-F がその例）は Roam より優れており、これがインラインで実装されれば、比較的短い時間で興味のあるトピックを見つけることができるでしょう（つまり、検索が「何らかの形で」有用だとお考えであれば、現状のままでもここで述べられたニーズを満たします）。
- リンクは、そのフォーラム内のメッセージに Discourse のトピックへのリンクをコピー＆ペーストした場合と同様に、完全なタイトルを使用します。
- リンクの名前変更は、Discourse が内部リンクに対して現在行っている方法で処理されます。
まとめますと、Roam は概念とユーザー体験の一部を示すための例に過ぎません。私が本当に提案しているのは以下の点です：
- インラインのトピック検索をトリガーする、あまり使われないが素早く入力できる一連の文字
- Enter キーで最初の結果を自動的に選択するインラインのトピック検索
- その他の点では通常の Discourse のリンク処理
- Discourse のアプローチに最も合致する方法での実装
それ以降の私の発言は、何が最も理にかなっているか、あるいは問題へのアプローチ方法についての単なる考察に過ぎません。
以上の点を踏まえて、必要な作業の見積もりは変わるでしょうか？もし変わらない場合、この機能リクエストのどの部分が、例えば「Ctrl-Alt-F + A」よりもこれほど複雑にしているのでしょうか？もし可能であれば、コストを妥当な範囲に抑えるためにリクエストの範囲を狭められるか、あるいはそれに見合う価値がないのかを理解する助けになるからです。
改めてありがとうございます！
「いいね！」 4
j127
15
私にとって、Discourse が標準的な Markdown との互換性が低ければ低いほど、Discourse と他の Markdown を使用するツール間でコンテンツを移動させるなどの他の作業が難しくなります。（私のサイトやドキュメントは一般的に Markdown または MDX を使用しています。）
もしこのような機能が追加される場合、実装の別のアイデアとして、Confluence や Notion に似たシステムを採用し、/（スラッシュ）文字でメニューを開く方法があります。
以下は Confluence の例です：
以下は Notion の例です：
もし Discourse に同様の機能があれば、スラッシュでメニューを開き、「リンク」をオプションとして含めることができます。「リンク」が選択された場合、ユーザーは他の投稿を検索でき、エディタに通常の Markdown リンクが挿入されます。
私はこの機能を求めているわけではありませんが、raw コンテンツが標準的な Markdown からさらに乖離しないような実装の代替案として提案したまでです。
「いいね！」 3
sam
(Sam Saffron)
16
既存の構造内で機能を収めるのであれば、テーマコンポーネントでも問題なく機能し、必要な作業量も莫大ではありません。[[ は実際、実装上非常に便利で、自動補完の終了位置を示す明確なアンカーとなります。
完全なワークフローの例は以下の通りです：
- ユーザーが
[[ と入力
- エディタが
]] を補完し、カーソルは括弧の間にある
- ユーザーが検索語を入力（例：
[[in-line topic]]）
- 入力中に検索が実行され、
@メンション のような形式で結果が自動補完として表示される
- 上/下キーまたは Enter キーを押して選択
- 選択すると
[[in-line topic]] が https://meta.discourse.org/t/in-line-topic-search-and-linking-e-g-roam-like-bracket-links/200454 に置換される
- ユーザーが
]] を超えてカーソルを移動すると自動補完が閉じ、[[in-line topic]] がそのまま Markdown として残る
全体として、このような機能の構築はテーマコンポーネント内で完全に実現可能であり、サーバーサイドの変更を必要とせず、比較的 straightforward に実装できます。専門家であれば 1〜2 日で、中級者でもおそらく 1 週間程度で完成させられるでしょう。
「いいね！」 5
oshyan
(Oshyan Greene)
17
はい、スラッシュメニューは確かに興味深く、素晴らしいアプローチで、私も多くのアプリで気に入って使っています。今回のケースで私が望んでいた実装方法として思いつかなかったのは、そのアプローチが呼び出す機能のセット全体を意味するからです。つまり、スラッシュメニューに慣れている人にとって、リンク検索のみを呼び出すのは奇妙で、予想外に感じられるでしょう。また、/ メニューに多くの他の機能を備えることは確かに賛成ですが、それは私にとっては明らかに大規模な機能リクエストのように聞こえます。
素晴らしいです。この点をよく考えていただき、複雑さや開発期間の目安を教えていただきありがとうございます。それは非常に役立ちました。他の、おそらくより重要なリクエストの開発資金を確保する必要があるため、自分のお金を一部投入できるかどうか考えなければなりません。また、キーボードショートカットについてより詳しく知った今、これは必須というよりは利便性のためのものだと感じています。
「いいね！」 2
thoka
(Thomas Kalka)
18
選択したテキストにリンクを追加する際に「名前付きリンクを作成」できれば、さらに面白くなるでしょう。このアクションの結果として [選択したテキスト](リンク) が生成されると嬉しいです。
残念ながら、これは元に戻すバッファに自動的に追加されないようです。
「いいね！」 2
インスピレーションを得ることができる、その他の優れた「/」や「[[ ]]」の入力（操作）フローの例としては、以下が挙げられます。
および
「いいね！」 3
seong
(Seong-Young Her)
20
この個人知識管理システム＋フォーラムのコンセプトは、非常に先進的で、潜在的に非常に強力です。「新しい」ものではありません（例：「Bliki」（2003年）を参照）が、そうである必要はありません。文脈が新しいため、アイデアも新しいのです。PKM市場は、皆さんが説明しているようなものを求めているものの、それが存在しないため、急速に成長しています。とはいえ、ウィキリンクが正しい解決策だとは思いません。Discourseに組み込まれている「ハイライトをリンク」機能（現在の引用機能の改善/バリアントとして）がそうなるでしょう。「投稿内でテキストをハイライトすると表示される「共有」ボタンは、URLだけでなく、引用を使用してフォーラム内に新しいトピックを作成するオプションも提供すべきです（後者の機能は3クリック離れた場所にあり、うまく機能しません）。しかし、まだ存在しないトピックへのウィキリンクを作成できることは便利であり、誰かがクリックして作成すると、それがウィキポストになる可能性があります。
皆さんのGardenは素晴らしい概念実証だと思いますが、Discourseからハッキングされたものであるという点で大きく制限されています（ウィキ、ツェッテルカステン、またはCircle/Notionインスタンスとして機能する方が良いと思いますか？）。投稿の質が厳密に管理されないと、共有PKMは簡単に崩壊する可能性があります。深いが役に立たないコンテンツは、クリックする前にコンテンツの質を判断する方法がないまま定着する可能性があります。フォーラムは、従来のPKMよりも、オープンエンドな共同知識生成をはるかにうまく処理します。ここに興味深い中間例があります：LessWrongには「コミュニティブログ」システムがあり、これは実際にはRedditのフォークであり、彼らの目的には驚くほどうまく機能します。これにより、貢献者全員が最初から自分の仕事に長けていることを要求するという課題をなくすことができます。ユーザーの貢献（投稿や投稿のプレイリストのようなコレクション）は標準的ではありません（ウィキでは通常、トピックごとに1つの記事しかないことと比較してください）。
「いいね！」 3
oshyan
(Oshyan Greene)
21
いくつかのことはより良くなるでしょうが、いくつかのことは著しく悪くなるでしょう。私の目的のために、私は確かにDiscourseによっていくつかの重要な点で制限されていますが、主なものの一つは単にナビゲーションであり、意欲とそれゆえの開発リソースがあれば、半ば簡単に解決できるようです。私はすぐに（いくらかの資金とともに）提案するアイデアを持っており、それが役立つことを願っています。
特に知識生成の文脈において、モデレーターの概念を「キュレーター」により近いものに拡張することについても価値があると思います。個人の知識生成は、ジェネレーターとキュレーターの役割/活動を組み合わせます。しかし、集合的な知識生成はおそらく、他者が生成したコンテンツ、アイデアなどを引用、宣伝、整理、洗練、およびその他サーフェス化し、それから利益を得られる人々にとってよりアクセスしやすくする役割またはその一部に焦点を当てた信頼できる人々を必要とするか、少なくとも著しく利益を得るでしょう。理論的には、Discourseのウィキ機能はここで解決策の一部になり得ますが、いくつかの調整が必要になります。
集合的な知識生成、「デジタルガーデニング」などに関して、興味深いこともたくさんあります。最終的な目標は、集合的な視点と理解を表す単一のドキュメントを作成することですか？それとも複数の視点を同時に表すことですか？それともその両方の組み合わせですか？これらの質問やその他の質問に対処するための多くの可能なアプローチを見ることができます。
最終的な課題は、CDCKはおそらくDiscourseのこれらの用途にそれほど関心がないこと（理解できます、それらの有用性、したがって収益の可能性は現時点でははるかに未熟で不明瞭です）です。そしてその間、知識生成に焦点を当てている他のプラットフォーム（例：Wikipedia/MediaWiki）はほとんど、または全くないかもしれませんが、会話的で議論的な側面を十分に、特にその両者の間の相互作用をうまく処理していません。完璧な世界では、長期間にわたる質の高い議論は、帰属を維持しながら、蒸留された知識、アイデア、視点のアウトプットに、簡単かつ流動的に、そして実際に読むのが楽しいフォーマットされた一貫した「ドキュメント」/アーティファクトのアウトプットを、段階的に追加することができます。Wikipediaは、機能する現在のモデルの良い例ですが、それは非常に不完全であり、単に知識を文書化するだけでなく、実際に洞察を生成し、新しいアイデアを探求するなど、それを超えるためには新しいツールと方法が必要です。
Discourseは現在、これらの目的のために使用できます。いくつかの方法では他の方法よりも簡単ですが、それは可能です。ほとんど必要なものは揃っています…
「いいね！」 4
