Discourse는 처음부터 Ember 애플리케이션이었습니다.
단순히 일부 구조를 변경하고 Ember Components를 표준화하는 것입니다.
설명해 드리겠습니다:
5개의 좋아요
갑자기 아이디어가 떠올랐습니다. 아직 조악한 단계이지만, 남들의 피드백 없이 너무 깊이 파고들지 않도록 먼저 공유해 보려고 합니다.
만약 Discourse가 일정 수의 답글이 쌓일 때까지 스레드형 토론을 허용하고, 그 임계점을 넘으면 관련 링크를 달아 새 주제(topic)로 답글을 쓰도록 강제하거나 강력히 권장하는 기능이 있다면 어떨까요?
저에게는 이것이 Discourse가 어떤 방향으로 가고 싶은지에 대한 질문으로 이어집니다. 만약 순수한 롱폼(long-form)에 집중된 대화 플랫폼을 지향한다면, 현재 방식이 잘 작동한다고 생각합니다. 하지만 이벤트와 사용자 디렉터리, 그리고 사람들 간의 상호작용을 포함하는 커뮤니티 플랫폼을 지향한다면, 짧은 형식의, 거의 잡담에 가까운 상호작용을 추가하는 것이 이점이 될 수 있다고 봅니다.
예시
저는 제 팟캐스트 에피소드를 자동으로 Discourse에 게시합니다(의도적으로 소문자를 사용하여 일반화했습니다. 회사 측에서 싫어할지 모르겠네요, 하하). 일부 에피소드는 5~10분인 반면, 어떤 것은 3시간을 넘기도 합니다.
3시간짜리 팟캐스트의 경우, 사람들이 집중된 토론을 나눈다는 것은 거의 불가능할 것 같습니다. 어떤 사람은 00:06:00 부분을, 다른 사람은 01:34:24 부분을, 또 다른 사람은 02:33:50 부분을 논평하고 싶어할 테니까요. 많은 댓글은 짧을 수 있습니다. 예를 들어 자막의 한 부분을 인용하며 "와, 그런 생각을 해본 적이 없었네"라고 하거나, 다른 부분을 인용하며 "이것에는 강력히 동의하지 않는다"라고 하거나, 단순히 다른 부분들에 하트를 누르거나 100% 다른 반응을 보이고 싶은 것일 수도 있습니다.
이러한 짧은 댓글들이 커뮤니티에 많은 가치를 가져다줄 수 있다고 생각합니다. 사람들이 기여하기 쉽게 만들어 줄 뿐만 아니라, 토론의 씨앗을 뿌리는 역할도 하니까요. 예를 들어 "이것에는 강력히 동의하지 않는다"는 댓글을 보고 제가 이어가고 싶을 수 있습니다. 그리고 이어가려다 보니 약간 감정이 격해져 더 깊이 들어가고 싶어질 수 있습니다. 그러면 상대방도 더 깊이 답합니다. 이때 스레드가 다루기 힘들어지기 시작한다고 생각합니다.
하지만 그 시점에서 소프트웨어가 "더 깊이 다루려면 관련 링크를 달아 새 주제를 시작하세요"라고 말해 준다면 어떨까요?
잡담 vs 롱폼
스레드형 토론은 잡담을 잘 처리한다고 생각하며, 선형(linear) 토론은 롱폼을 잘 처리한다고 생각합니다. 스레드형 세계의 FB, IG, HN, Reddit 등은 선형 토론을 만드는 것이 매우 어려울 수 있고, Discourse 같은 선형 기반 플랫폼이 초기에는 스레딩을 추가했다가 너무 길어지면 선형으로 분리하는 것이 더 쉬울 수 있다고 생각합니다. 실제로 Facebook도 최대 중첩 수준을 설정하고, 그 이상은 대화의 선형화를 강제하는 것 같습니다.
잘 모르겠습니다. 아마 Slack이 이런 시도를 해봤다가 실패했을 수도 있겠네요, 하하.
이 부분에 대해 어떤 생각들이 있으신가요?
2개의 좋아요
Discourse가 바로 그렇게 작동하지 않나요? 가벼운 대화는 채팅에서 스레드 형태로, 긴 글 형식의 논의는 토픽에서 이루어질 수 있습니다.
누군가가 채팅으로 시작하는 경우는 그렇지만, 중첩된 댓글이 있는 블로그 게시물처럼 시작하는 경우는 아닙니다.
제가 제안하는 시작점은 페이스북 게시물이나 인스타그램 게시물, 혹은 아마도 레딧의 게시물과 유사할 것입니다. 반면, 당신이 제안하는 방식은 왓츠앱 그룹이나 다른 그룹 채팅처럼, 그룹 이름이나 아주 높은 수준의 주제 영역을 중심으로 대화가 끊임없이 이어지는 형태에 더 가까울 것 같습니다.
따라서 제가 제안하는 방식은 슬랙보다는 덜 비슷할 것입니다. 슬랙은 그룹 채팅에 더 가깝지만, 게시물처럼 구체적인 주제보다는 더 높은 수준의 주제 영역을 다루기 때문입니다.
1개의 좋아요
각 게시물 아래 답변 버튼 옆에 ‘답변을 링크된 토픽으로 만들기’ 버튼(다시?)을 추가하는 것이 스레딩에 대한 이러한 욕구를 어느 정도 해소하는 데 도움이 될 것 같습니다. 스레드(새 토픽)는 대화 중 일부 사용자만 관심을 가질 만한 내용을 공유하고, 그 내용만 추종하려는 경우에만 유용합니다.
또 다른 부분은 스레드/새 토픽이 생성되었음을 나타내는 링크나 힌트를 남겨두는 것입니다. 현재에는 이러한 기능이 있지만, 새 토픽이 분기된 위치에 있지 않습니다.
따라서 특정 게시물에 대한 응답으로 링크된 토픽이 생성되면, OP(최초 게시물) 아래에만 있는 것이 아니라 해당 게시물 바로 아래, 답변 아이콘 툴바 바로 아래에 링크가 표시되어야 합니다. 정확히 그런 방식이어야 합니다.
5개의 좋아요
아마도 이 스레드 위에서 이미 말한 것 같습니다. 활발한 토론을 따라가려 한다면 스레딩은 악몽과도 같습니다. 전체 내용을 모두 확인했는지, 아니면 중요한 부분을 놓치고 있는 것인지 절대 알 수 없습니다. 스레딩은 완료되고 아카이브된 토론에만 사용할 수 있습니다. 저는 모든 "게시글에 답글"이 UI에 표시되어야 한다고 생각합니다. 바로 위에 있는 게시글에 답글을 달고 있는 경우에도 마찬가지입니다. (마지막으로 확인했을 때, 이는 설정에서 옵션으로 제공되며 기본값은 "꺼짐"이었습니다.)
2개의 좋아요
레딧과 다른 스레딩 토론 기능이 있는 커뮤니티를 사용해 봤는데, 저에게는 문제없이 잘 작동했습니다. 다만 토론을 계속 읽으려면 또 다른 페이지를 불러와야 하는 점이 마음에 들지 않았고, 일부 사이트에서는 몇 단계 내려가면 그렇게 되더군요. 그리고 스레드가 너무 깊어지면 가로 스크롤을 해야 하는 것도 싫었고, 단계가 너무 많아지면 글자가 너무 작아지는 것도 마음에 들지 않았습니다. 하지만 이를 해결할 옵션들이 있습니다. 이제 우리는 더 많은 경험을 쌓았으니까요.
하지만 매월 20억 명의 사람들이 레딧을 사용하며, 그중 14억 명이 댓글 시스템을 이용하고 있습니다. 그들이 이에 대해 불평하는 모습을 보지 못합니다.
저는 기술 지원을 위해 디스코스를 사용해 왔고, 정말 잘 작동했습니다! 하지만 토론 포럼을 원하는데, 다른 커뮤니티들이 가진 스레딩 토론을 정말 좋아합니다. 그리고 디스코스에서도 그런 옵션이 있으면 좋겠습니다. 전에 말했듯이, 가능한 한 도울 준비가 되어 있습니다.
2개의 좋아요
이것은 Discourse를 활용해 댓글 시스템을 구축하려는 제 계획의 일부입니다. 댓글에 대한 답글(기사 전체에 대한 답글이 아닌)이 새로운 토론을 촉발했다는 징후가 있으면, 해당 토론에 참여하는 사용자는 토론을 포럼의 새로운 주제로 이동하도록 안내받게 됩니다. 새로운 토론이 시작되었음을 나타내는 로직은 매우 단순할 수 있습니다. 예를 들어, 한 게시물에 대한 직접적인 답글이 두 번 이루어진 후, 누군가 해당 게시물의 “답글” 버튼을 클릭할 때 게시물 편집기 위에 새 주제를 쉽게 시작할 수 있는 링크가 표시되는 방식입니다. "스레드"의 다른 참여자들은 새 주제에 초대됩니다.
이 경우, 댓글은 일반적인 댓글 시스템과 마찬가지로 웹사이트에서 생성됩니다. 관련 토론은 Discourse에서만 이루어지지만, 웹사이트 댓글에서 링크로 연결됩니다.
3개의 좋아요
이 모든 것들이 저에게 스레딩을 매우 어렵게 만드는 요소들이에요. 여기서 천 개의 작은 상처가 쌓여 죽음을 맞는 것과 같은 상황이죠.
가장 주요한 문제의 해결책은 무엇인가요? 스레드 모델에서는 아무것도 놓치지 않았는지 확인하기 위해 토론 전체를 주기적으로 다시 스크롤해야 하는 상황이 발생해요?
저는 스레드 기반 플랫폼을 사용하는 소규모 FOSS 커뮤니티(저를 포함해 꾸준히 활동하는 3명과 가끔 참여하는 약 6명, 그리고 가끔씩 지나가듯 참여하는 사람들)의 관리자/모더레이터예요. 전체 페이지 길이보다 짧은 토론에서조차 제가 무언가를 놓치는 횟수가 너무 많아서 이 시스템 전체에 대한 흥미를 잃게 되었어요.
리디트는 거대한 모멘텀과 낮은 진입 장벽 덕분에 살아남고 있어요. 그 읽기 경험은 인터넷의 겨드랑이 같은 존재라고 할 수 있죠.
2개의 좋아요
그건 당신의 의견이고, 그건 괜찮습니다. 저는 스레딩(스레드형 토론)을 좋아합니다. 그리고 사용자가 싫어하는 부분들을 해결할 수 있다고 생각합니다.
플러그인 API에 스레딩을 지원하는 기능이 있다면, 플러그인에 이를 추가하는 작업을 진행할 것입니다. 그리고 플러그인을 무료로 제공하거나(필요하다면 사전 자금 지원이 있다면) 재정적 지원이 필요할 경우 유료로 판매할 것입니다. 현재 저는 API에 대해 잘 모릅니다. 이전에 오픈소스와 무료 제품을 개발해 본 적이 있는데, 구축하거나 유지보수하는 데 비용이 드는 경우도 있습니다.
그건 이해할 수 있는 의견입니다. "이 스레드에 업데이트가 있으면 알려주세요"라는 옵션을 넣을 수 있습니다. 이미 존재하는 창의적인 해결책들이 있습니다. 소프트웨어 개발자로서 저는 테이블 한쪽에서 그런 불만들을 자주 듣고, 다른 쪽에서 해결책을 찾아내야 합니다. 하지만 일부 부분의 사용자 경험이 나쁘다고 해서 앱을 통째로 버리지는 않습니다. 그 경험을 업그레이드하는 방법을 찾습니다. 어쩌면 스레드가 정답이 아닐 수도 있고, 다른 답안이 있을 수도 있지만, 제 겸손한 의견으로는 디스코스의 단일 주제 디자인은 레딧과 같은 커뮤니티에서 볼 수 있는 다중 답변, 다중 댓글 토론에서 제가 원하는 만큼 잘 작동하지는 않습니다.
새로운 채팅 스레드들은 이를 해결하려는 것처럼 보이지만, 유튜브처럼 평탄한(flat) 토론 형식이고, 저장되지 않는다고 들었습니다. 유튜브에서는 채팅 스레드 댓글이 몇 개 쌓이면 따라가기 어렵습니다. 그래서 저에게는 답이 되지 못합니다.
레딧이나 특정 주제가 제시되고 그 주위를 둘러싸여 여러 토론이 형성되는 곳에서는, 그런 토론들을 별도의 페이지 로딩 게시물로 나누는 것이 제 의견으로는 읽기 편하지 않습니다(페이지 로드, 읽기, 돌아가서 이전 페이지 재로드 - 위치 상실, 새로운 스레드 게시물 로드, 읽기, 돌아가서 반복)."
1개의 좋아요
스레드에 대한 각 답변별로 별도의 알림을 말씀하시는 건가요? 새로운 게시물이 있다는 사실을 모르는 게 문제가 아니라, 그 게시물이 어디에 있는지 모르는 겁니다. 게시물이 하나 이상이면, 그중 하나만, 또는 가장 아래에 있는 게시물 하나만 볼 수 있습니다.
스레드형 콘텐츠는 토론을 촉진하기 때문에 모든 곳에서 사용되지 않습니다. 추천 알고리즘의 취향에 따라 정렬하고 숨길 수 있는 모듈화된 부분으로 토론을 전환하기 때문에 사용되며, 이는 방대한 양의 콘텐츠를 가진 플랫폼에서 단일 인간 사용자가 상호작용할 수 있도록 하는 필수 요구 사항입니다.
이 방식은 콘텐츠를 한 번만 볼 것으로 예상할 때 작동하며, 원하는 만큼 깊이 파고들 수 있게 해줍니다. 그러나 Discourse와 같은 환경에서처럼 동일한 주제를 반복적으로 다시 열어서 내용을 따라가야 할 경우, 토론의 그물을 풀기에는 복잡합니다.
2개의 좋아요
@piffy, 제 경우에는 그렇지 않습니다. 저는 스레드형 토론보다 반대 방식(평탄한 구조)이 더 어렵다고 느껴본 적이 없는데, 반대로 평탄한 토론은 대화 주제가 달라지거나 2명 이상의 사람이 상호작용하는 순간 인지적으로 어렵게 느껴집니다.
3개의 좋아요
제가 말하고 싶은 것은 같은 논의를 다시 돌아보는 문제에 더 가깝습니다. 새로운 답글이 12개 있다고 가정해 보겠습니다. 평탄한 구조의 토론이라면 돌아와야 할 지점이 단 하나뿐이므로 12개의 답글을 모두 읽을 수 있습니다. 반면, 스레드형 토론의 경우 답글이 포함된 12개의 독립적인 대화 스레드가 존재할 수 있으며, 각 새로운 답글을 읽기 전에 해당 스레드의 맥락을 다시 파악해야 합니다.
어떤 방식이든 목표는 인지적 단순함이 아니라 좋은 토론을 최적화하는 데 있어야 합니다. 결국 인지적으로 가장 쉬운 선택지는 아예 토론을 읽지 않는 것이니까요.
2개의 좋아요
저는 그 방식이 더 쉽다고 생각합니다. 단순한 들여쓰기(indentation)가 읽기를 덜 어렵게 만드는 대신 왜 더 어렵게 만드는지 이해할 수 없습니다. 예를 들어 저는 문서의 모든 제목을 들여쓰기하여 작성하는데, https://stackoverflow.com/revisions/46690751/2#:~:text=Run%20code%20snippet-,expand%20snippet,-answered%20Oct%2011 에 보이는 것처럼요.
그것은 Logical extreme - Wikipedia. 의 논리적 극단(Logical extreme)입니다. 즉, 논리적 극단이란 논의 중인 명제와 일관된 극단적이거나 터무니없는 입장을 나타내는 관련 진술을 의미합니다. 이는 이 맥락에서는 관련이 없습니다. 인지적 난이도는 여기서 논의되는 다른 속성들과 마찬가지로 무시할 수 없는 Benefit–cost ratio - Wikipedia (수익-비용 비율)이 있으므로, 다른 속성들과 마찬가지로 진지하게 고려되어야 합니다. 왜 그런 언급을 하셨는지 이해할 수 없습니다.
3개의 좋아요
문제는 들여쓰기가 아닙니다. 8페이지에 달하는 토론 중 해당 답글이 2페이지에 있다는 사실입니다. 어떻게 그 위치로 다시 돌아가야 한다는 걸 알 수 있으며, 그 위치까지 페이지를 넘기거나 스크롤하는 데 걸리는 시간을 감당할 수 있을까요?
1개의 좋아요
위키백과에서 단순한 개념을 링크할 거라면, 적어도 페이지를 직접 읽어보는 것이 좋습니다. 그 페이지에는 논리적 극단이 왜 유용한 수사적 기법인지 설명되어 있으니까요. 핵심은 좋은 토론은 어느 정도의 인지 부하(cognitive load)가 수반되어야 하므로, 이를 최우선적으로 최적화할 변수로 삼아서는 안 된다는 것입니다. 또한 이것은 매우 주관적인 문제이기도 합니다. 저는 개인적으로 중첩된 토론(nested discussions)보다 선형적인 단일 토론을 훨씬 더 따라가기 쉽다고 느낍니다.
가장 중요한 질문은 평탄한 형식(flat format)인지, 스레드 형식(threaded format)인지 중 어떤 것이 더 나은 토론을 이끌어내느냐는 것입니다. 저는 답을 알지 못하지만, 제 인상으로는 스레드형 토론은 주제에 대해 좁고 인위적으로 설계된 관점을 제공하며 다시 돌아가기 어렵기 때문에 전반적으로 토론의 질에 영향을 미친다고 생각합니다. 하지만 이것은 대형 플랫폼들이 반드시 감수해야 하는 불가피한 트레이드오프(trade-off)이며, 그래서 어디서나 이런 방식을 볼 수 있는 것입니다.
논리적으로 유용한 장치가 아니기 때문에 설명에 대한 참조를 한 것입니다. 또한 이후에 왜 유용하지 않은지 설명했으므로, 왜 설명을 요구하는지 모르겠습니다.
이전에 그 점을 명확히 했더라면 언급하지 않았을 것입니다. 동의합니다. 다만 아무도 반대 주장을 하지 않았으므로, 여전히 그 관련성을 이해하지 못하겠습니다.
해결해야 할 주요 문제가 이것이라고 생각하지 않습니다. 사용자가 스레드를 평탄하게 볼지 스레드 형태로 볼지 선택할 수 있기 때문에 중요하지 않다고 보기 때문입니다 - 각 사용자는 개인의 선호도에 따라 선택합니다. 모든 응답은 GUI 하위에 스레드화되어 있습니다(그래서 스레드 하단의 중복되는 파란색 버튼 외에도 응답 자체에 “답글” 기능이 있는 것입니다) 따라서 이는 단순히 이를 사용자에게 노출시키는 문제일 뿐입니다.
어떤 8페이지 토론을 말씀하시는 건가요? 가상의 스레드형 그리고 페이지네이션이 적용된 토론을 설명하고 있다면, 그 문제를 해결하는 방법은 단순히 스레드에 페이지네이션을 적용하지 않는 것입니다.
들어쓰기에 관한 것이 아닌 것은 무엇인가요?
1개의 좋아요
기록을 위해 말하자면, 스레딩을 하거나 사용 가능한 옵션을 확장하기 위해 플러그인을 만드는 데 반대하는 것은 아닙니다. 오히려 커뮤니티에서 만든 Discourse 플러그인의 수가 현재보다 훨씬 많아야 한다고 생각합니다.
제가 하고 있는 것은 OP에서 언급된 게시물의 원칙에 동의하는 것이며, 또한 스레드형 토론이 메인 Discourse 팀이 시간을 투자해야 할 핵심 아이디어가 되어서는 안 된다고 생각합니다.
이것이 제가 부분적으로 좋아하는 이유입니다. 글자 앞에는 개요가 있습니다:
- 주제
- 헤더
- 하위 항목
- 헤더
- 하위 항목
- 헤더
- 하위 항목
- 헤더
정리되어 있습니다. 전체적인 개요를 파악하고 찾고 있는 것을 쉽게 찾을 수 있습니다.
제 생각에, 스레드형 토론의 기존 결함은 사용성/UX 문제입니다.
- 페이지 새로고침
- 위치를 잃어버리는 것
- 새 댓글을 찾거나 알림을 받는 것
- 깊은 스레드 (읽을 공간이 적음)
이것들은 해결하기 어렵지 않습니다:
- 새로고침하지 말고 다이얼로그 창을 열거나 데이터를 가져오세요
- 새로고침하지 않으면 위치를 잃지 않습니다
- 새 댓글을 동적으로 로드하거나 시각적 표시기(굵은 행)를 사용하세요
- 깊이가 증가함에 따라 들여쓰기를 줄이거나 최대 깊이를 설정하세요
그렇습니다. 이미 훌륭한 커뮤니티 경험을 대체하는 것이 아니라, 사용자가 전환할 수 있는(또는 선택적으로 활성화할 수 있는) 보완적인 추가 기능이 될 것입니다.
1개의 좋아요