의미 있는 대화가 이루어지려면 방 안의 모든 사람이 서로의 생각을 들어야 합니다. Discourse에서 이를 가능하게 하는 가장 좋은 방법은 언제나 평탄하고 선형적인 타임라인이었습니다. 하지만 평탄한 구조가 모든 커뮤니티에 적합하지는 않습니다. 크고 빠르게 움직이는 포럼에서는 단일 타임라인에 수천 개의 답변이 쌓여 아무도 따라가기 어렵습니다. 그래서 올해 우리는 완전히 중첩된 답변 뷰를 신중하게 실험해 왔으며, 평탄한 형식을 벗어난 커뮤니티에 매우 적합하다고 생각합니다.
실험용 플러그인으로 시작해 지금은 Discourse에 직접 포함되어 출시되는 프로젝트로 발전했습니다. 현재 중첩된 토픽이 어떻게 보이는지 미리 살펴볼 수 있습니다:
활성화 시 카테고리 내 과거 토픽을 변환하지 않기로 한 큰 이유는 사용자가 다르게 상호작용할 가능성이 높기 때문입니다. 평면 모드에서는 다양한 답글 버튼이 그렇게 중요하지 않습니다. 게시글은 토픽 하단에 배치되므로, 사용자가 중첩 보기로 변환되는 "맞는 버튼"을 항상 의도적으로 누르는지 확신할 수 없습니다.
결국 관리자가 과거 토픽에 이 기능을 활성화하면 갑자기 대화가 읽을 수 없게 될까 봐 걱정됩니다. 계속 고민해 보겠습니다. 제가 떠올릴 수 있는 가장 쉬운 변경 사항은 카테고리 설정을 토글할 때 "기존 토픽에 이 설정을 적용하시겠습니까?"라는 모달 팝업을 표시하는 것입니다.
저는 항상 “답글” 레이블이 더 구체적이면 좋겠다고 생각했습니다. 그래서 얼마 전 커스텀 CSS를 사용해 컨텍스트를 추가했습니다:
스크린샷
CSS
/* 원본 게시물(즉, 토픽)의 답글 버튼에 텍스트 추가 */
#post_1 nav.post-controls {
.actions {
button.reply {
span.d-button-label:after {
// 답글 뒤에 이 콘텐츠 추가
content: " 이 토픽에";
}
}
}
}
/* 이후 모든 게시물의 답글 버튼에 텍스트 추가(이것들을 댓글이라고 부름) */
nav.post-controls {
.actions {
button.reply {
span.d-button-label:after {
// 답글 뒤에 이 콘텐츠 추가
content: " 이 댓글에";
}
}
}
}
/* 페이지 하단에 표시되는 파란색 답글(토픽에) 버튼에 텍스트 추가 */
#topic-footer-buttons {
.topic-footer-main-buttons {
button.btn-primary.create {
span.d-button-label:after {
// 답글 뒤에 이 콘텐츠 추가
content: " 메인 토픽에";
}
}
}
}
제가 운영 중인 커뮤니티라면 먼저 격리된 상태로 테스트할 것입니다. 반면, 여러분이 전체 커뮤니티에서 활성화하면 더 가치 있는 피드백을 더 빨리 얻을 수 있을 것입니다 장난 aside, 격리된 상태로 테스트하는 것이 현명할 것 같지만, 여기에는 파괴적인 데이터 마이그레이션이 없습니다. 안전하게 활성화하고 비활성화할 수 있습니다. 여기서 내리는 결정은 어느 쪽으로든 여러분을 묶어두지 않습니다.
아마도 이 부분은 제가 우연히 답해버린 것 같습니다! 중첩(nesting)을 활성화하면 DB의 각 주제에 대해 nested_topic 레코드를 생성하고, 계보 트리의 답장 수를 계산하기 위한 작업을 시작합니다. 중첩을 비활성화하면 해당 nested_topic 레코드가 삭제되고 평탄한 구조로 돌아가며, 아무런 문제가 없습니다.
이것이 사용자의 결정이나 선호에 따라 달라지는 것은 원치 않습니다. 사이트가 어떻게 기능해야 하는지는 관리자(Administer)가 결정할 문제입니다. 두 패러다임은 매우 다르며, 동일한 콘텐츠에 대해 사용자가 이렇게 다른 방식으로 상호작용해서는 안 됩니다. 적어도 현재 우리의 생각은 그렇습니다.
좋은 기능입니다! 다만 중첩 레이아웃 자체보다는 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 파라미터만 지원해도 “하이라이트” 뷰를 구현하는 데 충분할 것입니다.
장난 aside, 격리된 상태로 테스트하는 것이 현명할 것 같지만, 여기에는 파괴적인 데이터 마이그레이션이 없습니다. 안전하게 활성화하고 비활성화할 수 있습니다. 여기서 내리는 결정은 어느 쪽으로든 여러분을 묶어두지 않습니다.
