특정 포럼에서 다른 주제(topic)로 링크를 생성하는 더 빠른 방법이 Discourse에 도입될 때가 되었다고 생각합니다. 물론 현재 작성기(composer)에는 링크 버튼과 단축키가 이미 존재하며, 주제의 정확한 URL을 정확히 알고 있다면 링크 대화상자 없이도 링크를 만들 수 있습니다. 하지만 다른 앱들이 보여 주듯, 인라인(inline)으로 검색 및 링크 대화상자를 호출하는 더 빠르고 쉬운 방법이 있을 수 있습니다.
Discourse에는 이미 이 방식의 선례가 있습니다. 프로필에 대한 @ 링크/검색 동작과 해시태그에 대한 # 링크/검색 동작이 그것입니다. 따라서 저는 단순히 주제에 대한 검색 및 링크 기능을 추가하는 것을 제안합니다. 이는 @ 사용자 검색과 매우 유사한 최소한의 접근 방식을 취할 것입니다. 작성기 내에서 입력하는 텍스트를 기반으로 빠른 인라인 주제 검색 팝업이 표시되며, 제목이나 기타 컨트롤 필드는 없을 것입니다. @ 검색과 정확히 동일하게 작동하되, 링크 생성을 위한 것입니다. 키보드를 사용하여 링크를 확인하고, 첫 번째 옵션이 자동으로 강조 표시됩니다.
최근에 인기를 얻은 이 기능의 구문 중 하나는 “브래킷 링크”(bracket links), 즉 [[link-to-topic]]입니다. [[를 입력하면 사용자나 해시태그 검색과 마찬가지로 주제 제목에 대한 검색이 호출됩니다. 또 다른 일반적인 방법은 / 슬래시 메뉴를 사용하는 것이지만, 이는 보통 여러 기능을 위해 사용됩니다. 어떻게 호출되든, 이는 주제 간 링크 생성을 매우 빠르고 쉽게 만들어 줄 것이며, 저는 이것이 좋은 일이라고 생각합니다. 왜냐하면 이는 다른 기존 및 관련 콘텐츠에 대한 참조를 장려하기 때문입니다.
이 특정 구문에 대해 제가 보는 주요 문제는 현재 지원되는 위키 문법과 다르지만, 동시에 유사하다는 점입니다. 그러나 위키 링크 문법은 실제로 이중 브래킷 [] 문법도 지원하는 시스템에서 사용되지만, 구체적으로 사용자 정의 텍스트가 필요한 링크를 위해 사용됩니다. 따라서 하나의 옵션은 동일한 구분을 사용하는 것입니다. 즉, 이중 브래킷은 주제 제목을 링크 텍스트로 사용하는 주제 링크에 사용하고, 전통적인 위키 링크는 사용자 정의 제목에 사용하는 것입니다. 또 다른 옵션은 링크 문법을 전반적으로 변경하는 것이지만, 이것이 매력적일 것이라고는 생각하지 않습니다. 세 번째 옵션은 링크 검색을 호출하는 다른 문자 세트를 선택하는 등, 다른 인라인 링크 문법을 사용하는 것입니다.
구체적으로 어떻게 구현되는지는 크게 신경 쓰지 않습니다. 그저 인라인으로 검색 및 링크를 만들 수 있으면 됩니다. 이는 이미 훌륭한 Discourse의 작성기와 전반적인 편의 기능에 훌륭한 추가가 될 것이라고 생각합니다.
그러나 말하자면, 기존 작성기 기능이 꽤 좋으며 이것이 단지 편의 기능일 뿐이라고 인식하고 있습니다. 논쟁의 여지가 있지만, 특정 사용자 집단을 위한 기능일 수 있습니다. 유용하다는 데 합의가 있어도 확실히 우선순위는 낮을 것입니다.
이 모든 것은 아이디어 자체의 문제가 아니라 UI/UX 또는 검색 기능의 실패로 인한 결과처럼 들립니다. 아직 하지 않으셨다면, 여러분이 설명하신 경험에 비추어 기존 “게시물 이동/병합” 동작에 대한 개선/수정을 논의하기 위해 주제를 여시는 것을 제안드립니다. 그러나 제가 제안한 링크 방식의 맥락에서 그러한 종류의 문제가 발생하지 않는다고 가정할 때, 그때 유용하다고 보시겠습니까?
왜 인라인 검색이 툴바 기반 검색과 다르게 작동한다고 가정하시나요? 검색 및 표시 동작에 관해서는 완전히 동일하게 작동해야 하므로, 올바른 주제를 찾고 선택하는 데 있어 동일한 수준의 용이성과 유용성을 갖게 됩니다. 제 선호도는 기존 링크 대화상자와 차별화하여 속도와 사용 편의성에 초점을 맞추는 것이며, 기존에 팝업으로 작은 컨텍스트 결과 목록을 표시하는 @ 검색과 매우 유사하게 작동하는 것입니다. 결과 목록은 링크 대화상자의 것과 완전히 같은 모양일 수 있지만, 주제 제목 필드, 확인/취소 버튼 등은 원하지 않습니다. 이미 이를 호출하는 단축키가 존재합니다.
왜 더 많은 깨진 링크가 생기는지 정말 모르겠습니다. 검색에서 선택한 주제를 확인하려면 여전히 Enter 키를 눌러야 합니다.
음, 분명히 "더 빠르다"고 할 수는 없습니다. 사용자 친화적일 수는 있겠지만, 제 제안은 기존 툴바 링크 기능을 대체하는 것이 아니라, 더 경험이 많은 사용자를 위해 더 빠른 링크 방식을 추가하는 것입니다.
물론 Ctrl-K(단축키)도 훌륭한 대안이며 이미 존재합니다. 저는 인라인 구문을 사용하여 유용한 기능을 트리거할 수 있는 능력을 좋아합니다. 이는 Discourse가 @와#으로이미 수용하고 있는 것입니다. 이 두 가지도 검색 없이 키보드 단축키나 수동 입력으로 접근할 수 있지만, 물론 현재 작동 방식에는 추가적인 가치가 있습니다. 저는 이 접근 방식을 통해 링크 기능도 유사한 가치를 얻을 수 있을 것이라고 제안합니다.
오, 정말 흥미롭고 알 가치가 있는 정보네요! 하지만 저는 인라인 구문으로 실행하는 동작(action)과 키보드 명령으로 실행하는 동작 사이에 가치 있는 차이가 있다고 생각합니다. 하나는 발견 가능성(Discoverability)이고, 다른 하나는 속도입니다.
배우면 그 시퀀스를 꽤 빠르게 사용할 수 있다는 점은 사실입니다. 하지만 테스트를 위해 여러 번 직접 해본 결과, [] 괄호 링크를 지원하는 (점점 늘고 있는) 앱들에서의 경험보다는 확실히 느리고 매끄럽지 않게 느껴졌습니다. 아마도 새로운 그리고 약간 어색한 키보드 단축키 외에도 주의력/시선의 전환이 필요하기 때문일 수 있습니다. 후자(단축키)는 시간이 지나면 부분적으로 극복할 수 있을지 모르지만(제 기본 손가락 구조상 그 잠재력에 한계가 있다고 보지만), 전자(주의력 전환)는 메시지를 작성하는 동안 항상 비용이 따를 것입니다.
사실 많은 다른 단축키가 이미 사용되고 있음에도 불구하고, 빠른 링크 생성에 대한 충분한 욕구를 가지고 이 다소 특이한 키보드 단축키 시퀀스를 만든 점이 저에게는 흥미롭습니다. 이는 인라인 링크 아이디어 자체에 대해 어느 정도 가치를 보고 계실 수 있음을 시사하는 것 같습니다… 하지만 현재 제 제안에 대한 지원이 많지 않다는 인상을 받습니다. 그럼에도 불구하고, 예를 들어 "우리는 괄호를 다른 용도로 사용한다"거나 “인라인 핸들러를 하나 더 추가하면 모든 데이터베이스 쿼리가 30% 느려진다” 등 명확한 장애물이 있는지, 아니면 아예 없는지 궁금합니다.
어쨌든, 이 글이 적어도 누군가의 관심을 불러일으켰기를 바랍니다. 이 기능이 사용 가능해지기를 여전히 원하며, 다른 사용자들도 한번 사용해볼 기회가 있다면 그들도 좋아할 것이라고 생각합니다(여기서 Roam 사용자 계신 분? Obsidian? Logseq?). 하지만 최소한 인라인 검색 및 링크 아이디어에 대한 관심을 불러일으켰기를 바라며, 미래에 이 주위를 중심으로 무언가 구체화되기를 기대합니다.
좋은 정보네요! 프로그래밍을 하지 않는 입장에서 테마 컴포넌트에서 얼마나 많은 것이 가능한지 정확히 알지 못했지만 (아주 많은 것이 가능한 것 같고, 이것이 Discourse를 좋아하는 많은 이유 중 하나입니다). 그래서 꽤 멋진 기능이라고 생각합니다.
다른 소프트웨어에서는 [[가 유지되며 링크가 추가된 후에도 여전히 가치를 유지합니다. 또는 [[ 검색이 전통적인 링크를 자동으로 채워 넣는 것이 아니라, 전문적인 내부 참조를 생성한다고 말하는 것이 더 정확할 것입니다. 여러 애플리케이션이 이 참조 형식을 지원하므로 Markdown의 변형으로 휴대성이 있어 꽤 편리합니다.
하지만 어쨌든 Discourse의 경우 [[는 단순히 익숙한 인라인 단축키일 뿐이며, 우연히 트리거될 가능성이 낮은 것이 행운입니다. Discourse와 예를 들어 Roam처럼 작동 방식에 차이가 있더라도, 적어도 문법이 동일하다는 점에는 가치를 인정합니다. 앞서 말했듯이, 이는 일종의 사실상 표준으로 자리 잡아가고 있습니다.
또 하나 떠오르는 것은 Discourse가 이미 특수한 방식으로 렌더링되는 자체 내부 링크의 동등한 기능을 가지고 있다는 점입니다. 바로 인용(quoting)이 작동하는 방식입니다! 따라서 "post:10, topic:200454"는 당연히 여기에서 제게 답글을 남긴 링크로 연결됩니다. 이 링크 기능이 특정 내부 토픽을 위한 것이므로, 렌더링 시점에 자동으로 해당 토픽으로의 링크로 표시하도록 할 수 있을 것입니다. 이것이 Discourse의 기존 방식에 더 부합하는지, 아니면 덜 부합하는지 판단이 서지 않습니다…
한편으로는 이미 이러한 링크 방식이 존재하므로, 이는 단순히 링크 검색 및 선택을 호출하는 또 다른 방식일 뿐이며, 언급했듯이 기존 @ 및 # 검색과 매우 유사합니다. 다른 한편으로는 Ctrl+K, 툴바 및 기타 단축키로 호출되는 기존 링크 동작과는 다릅니다. 하지만 “post:10” 형태의 링크는 다른 앱에서 사용되는 [[ 링크 개념과 더 유사하다고 생각하므로, 만약 제가 이 문제에 대해 영향력을 가진다면 약간 그쪽으로 기울 것입니다… 물론 이것이 결국 테마 컴포넌트 영역에 더 가깝다는 것은 알고 있습니다. 그래서 아마도 영향력이 있을지도 모릅니다. 테마 컴포넌트에서 팝업 검색을 통해 “post:10” 스타일의 링크를 만들 수 있는지 의견을 주실 수 있을까요?
자, 여기서부터는 Roam을 예시로 든 것이 너무 직역하면 성립하지 않는 부분이 있습니다. 사실 저는 꽤 오래전에 Roam 사용을 중단했습니다. 부분적으로는 그 인라인 검색 기능이 정말 최악이었기 때문이죠. Obsidian이 더 좋은 예시이며, 현재 제가 전업으로 사용하는 도구이기도 합니다. 다만 Obsidian은 시도를 위해 다운로드가 필요한 반면, Roam(또는 Logseq)은 그렇지 않습니다.
더 이어서 말씀드리기 전에, 이 아이디어에 이렇게 깊이 관여해 주신 @sam님께 감사드립니다. 이 아이디어가 다소 엉뚱하게 느껴질 수 있다는 점은 잘 알고 있습니다. 특히, 당신이 설명하신 작동 방식에 기반하여 이를 구현하는 데 얼마나 많은 작업이 필요할지 대략적인 범위를 알려주신 점에 대해 특히 감사드립니다.
그럼에도 불구하고, 제 제안은 Roam과 이 구문을 사용하는 유사한 앱에서 영감을 받아 나온 것이지만, 그 작동 방식을 완전히 재현하는 데에는 관심이 없습니다.
괄호를 자동 완성할 필요가 없습니다. 최종 마크다운 결과물에 괄호가 유지되지 않기 때문이죠. (Roam과 Obsidian에서는 괄호가 유지됩니다.)
Ctrl-K 링크 검색이나 Ctrl-Alt-F와 같은 Discourse 검색은 Roam보다 우수하며, 인라인으로 구현된다면 관심 있는 주제를 합리적인 시간 내에 찾을 수 있을 것입니다. (즉, 검색이 아무 의미라도 있다면, 현재 상태 그대로 여기서 설명한 요구 사항을 충족할 수 있습니다.)
링크는 제목 전체를 사용해야 합니다. 이는 같은 포럼의 메시지에 Discourse 주제 링크를 복사/붙여넣기한 것과 동일한 방식입니다.
이름 변경은 Discourse가 이미 내부 링크에 대해 처리하는 방식대로 처리되면 됩니다.
즉, 요약하자면 Roam은 개념과 사용자 경험의 일부를 시연하기 위한 예시에 불과합니다. 제가 실제로 제안하는 것은 다음과 같습니다:
드물지만 빠르게 입력할 수 있는 특정 문자 집합을 사용하여 인라인 주제 검색을 트리거하는 것
Enter 키를 눌러 첫 번째 결과를 자동으로 선택하는 인라인 주제 검색
기타 모든 측면에서 일반 Discourse 링크 처리 방식 유지
Discourse의 철학과 가장 부합하는 방식으로 구현
제가 언급한 나머지는 이 문제에 대해 가장 합리적인 방법이나 가능한 접근 방식에 대한 단순한 추측일 뿐입니다.
이 모든 점을 고려할 때, 필요한 작업량의 추정치가 달라질까요? 만약 그렇지 않다면, 이 기능 요청의 정확히 어떤 부분이 예를 들어 Ctrl-Alt-F + A보다 훨씬 더 복잡하게 만드는 것일까요? 요청 범위를 좁혀 비용을 합리적으로 만들 수 있는지, 아니면 필요한 시간이 아깝기 때문에 시도할 가치가 없는지 이해하는 데 도움이 될 것 같아서 묻습니다.
네, 슬래시 메뉴는 확실히 흥미롭고 멋진 접근 방식이라서 제가 많은 앱에서 선호하고 사용하는 방식입니다. 이 경우 제가 원하는 것을 구현하는 방법으로 이 방식이 떠올리지 못한 이유는, 이 접근법이 호출될 기능 세트 전체를 암시하기 때문이라고 생각합니다. 다시 말해, 슬래시 메뉴에 익숙한 사용자들에게 해당 메뉴가 링크 검색만 호출하도록 하는 것은 이상하거나 예상 밖의 행동일 것입니다. 그리고 / 메뉴에 다른 많은 기능을 포함하는 것은 제가 분명히 찬성하는 사항이지만, 제게는 상당히 큰 기능 요청으로 들립니다.
정말 감사합니다. 이 문제를 깊이 생각해 주시고 복잡도와 개발 시간대에 대한 아이디어를 주셔서요. 정말 큰 도움이 됩니다. 개발을 위해 자금을 지원해야 할 다른, 아마도 더 중요한 요청 사항들이 몇 가지 있으므로, 제가 직접 일부 비용을 부담할 수 있을지 고민해 봐야겠습니다. 그리고 이제 키보드 단축키에 대해 더 알게 되었기 때문에, 이 기능은 결국 필수보다는 편의성에 가깝다고 생각합니다.
이 개인 지식 관리(PKM) 시스템 + 포럼 개념은 정말 선구적이며 잠재적으로 매우 강력해 보입니다. 이 개념이 ‘새로운’ 것은 아닙니다(예: 2003년에 나온 “Bliki”) 하지만 그럴 필요도 없습니다. 맥락이 새로워졌기 때문에 아이디어 역시 새로운 것입니다. PKM 시장은 당신이 설명하는 것과 유사한 것을 원하지만 현재는 존재하지 않는 것이 많아 매우 빠르게 성장하고 있습니다. 다만, 위키링크가 올바른 해결책이라고 생각하지는 않습니다. 대신, 현재 인용(Quote) 기능의 개선/변형으로 Discourse에 내장되는 ‘하이라이트 링크’ 기능이 적합할 것입니다. 게시글 내에서 텍스트를 하이라이트할 때 나타나는 ‘공유’ 버튼은 URL을 제공함과 동시에, 해당 인용을 사용하여 포럼 내에서 새 주제를 생성하는 옵션도 제공해야 합니다(현재 이 후자는 3클릭 거리에 숨겨져 있고 제대로 작동하지도 않습니다). 하지만 아직 존재하지 않는 주제에 위키링크를 생성했다가, 누군가가 클릭하여 생성하는 시점에 위키 게시글로 전환되는 방식이 유용할 수 있다는 점은 이해합니다.
당신의 Garden은 훌륭한 개념 증명(PoC)이라고 생각합니다. 다만 Discourse를 기반으로 급조된 데에서 오는 한계가 대부분인 것 같습니다(위키, 제텔카스텐, 또는 Circle/Notion 인스턴스로 구현하는 것이 더 잘 작동할 거라고 생각하시나요?). 게시물의 품질이 엄격히 통제되지 않으면 공유 PKM은 쉽게 무너질 수 있습니다: 깊지만 쓸모없는 콘텐츠는 클릭하기 전에 콘텐츠의 품질을 가릴 방법이 없다면 고착화될 수 있습니다. 포럼은 일반적인 PKM보다 개방형 협력적 지식 생산을 훨씬 잘 처리합니다. 흥미로운 중간 사례를 하나 소개하면: LessWrong에는 ‘커뮤니티 블로그’ 시스템이 있는데, 실제로는 Reddit 포크이며 그들의 목적에 완벽하게 작동합니다. 이는 기여자들이 처음부터 자신의 분야에서 모두 능숙해야 한다는 부담을 덜어줍니다. 사용자 기여물(게시물과 플레이리스트 형태의 게시글 모음)은 *정본(canonical)*이 아닙니다(위키에서는 보통 주제당 한 개의 기사만 존재하는 것과 대비됩니다).
몇 가지 측면에서는 더 나아지겠지만, 몇 가지 측면에서는 눈에 띄게 나빠질 것입니다. 제 목적을 위해 디스코urses가 몇 가지 중요한 면에서 분명히 제약을 주고 있지만, 그중에서도 가장 주요한 문제는 단순한 내비게이션이라고 생각합니다. 만약 의지와 개발 리소스가 있다면 이를 해결하는 것은 반쯤 쉬운 일일 것입니다. 곧 제안할 아이디어(일부 자금 지원과 함께)가 이를 도울 수 있기를 바랍니다.
또한, 특히 지식 생성 컨텍스트에서 ‘모더레이터’ 개념을 확장하여 '큐레이터’에 더 가까운 무언가로 발전시키는 것이 가치 있다고 생각합니다. 솔로 지식 생성은 생성자와 큐레이터의 역할/활동을 결합합니다. 그러나 집단적 지식 생성은 아마도 - 또는 적어도 상당한 이점을 얻기 위해 - 다른 사람들이 생성한 콘텐츠, 아이디어 등을 인용하고, 홍보하고, 조직화하고, 다듬으며, 표출하여 그로부터 혜택을 받을 수 있는 사람들에게 더 접근 가능하게 만드는 것이 역할이나 초점의 일부인 신뢰할 수 있는 사람들을 필요로 하거나, 적어도 그들에게서 큰 이점을 얻게 될 것입니다. 이론적으로 디스코urses의 위키 기능이 이 해결책의 일부가 될 수 있지만, 몇 가지 조정이 필요합니다.
협업적 지식 생성, ‘디지털 가드닝’ 등에서도 고려할 흥미로운 사항들이 많습니다. 목표는 집단적 관점과 이해를 대표하는 단일 문서에 도달하는 것인가요? 아니면 여러 관점을 동시에 대표하는 것인가요? 아니면 이 두 가지의 조합인가요? 이러한 문제와 다른 문제들을 처리하는 다양한 접근 방식을 상상할 수 있습니다.
결국 도전 과제는 CDCK가 디스코urses의 이러한 용도에 그다지 관심이 없을 가능성이 높다는 점입니다(이해할 수 있습니다. 이 용도의 유용성과 따라서 수익 창출 잠재력은 현재로서는 훨씬 더 초기 단계이고 불확실하기 때문입니다). 한편, 지식 생성에 집중하는 다른 플랫폼들, 예를 들어 Wikipedia/MediaWiki 등은 대화적, 토론적 측면을, 특히 두 측면 간의 상호작용을 충분히 잘 다루지 못하고 있습니다. 이상적인 세상에서는 장기간에 걸친 고품질 토론이 지식, 아이디어, 관점의 정제된 산출물에 점진적으로 기여할 수 있으며, 이는 쉽게 그리고 유창하게 이루어져야 합니다. 동시에 귀속을 유지하면서도 잘 포맷되고 일관된 ‘문서’/산출물을 만들어 내어 실제로 읽는 즐거움을 제공해야 합니다. Wikipedia는 현재 작동하는 모델의 좋은 예이지만, 매우 불완전하며, 단순히 지식을 문서화하는 것을 넘어 실제로 통찰력을 생성하고, 새로운 아이디어를 탐색하는 등 더 나아가기 위해서는 새로운 도구와 방법이 필요합니다.
디스코urses는 현재 이러한 용도로 사용할 수 있으며, 어떤 측면에서는 다른 측면보다 더 쉽게 사용할 수 있습니다. 하지만 할 수 있으며, 필요한 것의 대부분을 갖추고 있습니다…
물론 이것이 결국 테마 컴포넌트 영역에 더 가깝다는 것은 알고 있습니다. 그래서 아마도 영향력이 있을지도 모릅니다. 테마 컴포넌트에서 팝업 검색을 통해 “post:10” 스타일의 링크를 만들 수 있는지 의견을 주실 수 있을까요?
