두 가지가 이해가 되지 않습니다:
- 칸반 보드 설정에서 드롭다운으로 카테고리를 선택할 수 없는 이유는 무엇인가요? 이름을 수동으로 입력해야 합니다.
- 설정을 완료하면 카테고리 페이지에 보드 탭이 한 번만 표시되고, 이후에는 사라집니다. 그러면 처음부터 다시 설정해야 하는데요(드롭다운에서 선택된 카테고리를 삭제하고 다시 입력해야 함을 의미합니다).
혹시 다른 분들도 이 문제를 경험해 보셨나요?
4개의 좋아요
가능은 하지만, 단순한 드롭다운으로 대체하기보다 복잡한 특수한 경우가 있습니다. 카테고리 선택기는 기존 카테고리를 추가하는 것만 허용하지만… 현재 우리는 최상위 “모든 카테고리” 뷰에 구성 요소를 적용하기 위해 사용자 지정 @ 항목을 추가할 수 있도록 허용하고 있습니다.
카테고리 드롭다운을 사용할 수 있도록 이 기능을 별도의 설정으로 분리하고 기존 설정을 마이그레이션해야 합니다.
이 탭 말씀이시죠?
문제를 재현할 수 없으며, 이미 수정되었을 수 있습니다 — 이 문제가 여전히 발생한다면 알려주시기 바랍니다.
3개의 좋아요
죄송합니다. 저는 이후 Discourse를 떠나 커뮤니티를 다시 Discord로 이전했습니다.
6개의 좋아요
정말 이해하기 어렵습니다. "@"가 무엇을 의미하는지, 어떻게 사용하는지 설명해 주실 수 있을까요? 칸반 설정 UI에서 확인했지만, 이것이 어떤 역할을 하는지 도무지 알 수 없었습니다.
또한, 왜 커스텀 “@” 항목이 있으면 드롭다운을 사용할 수 없게 되는 건가요? 그냥 드롭다운에 “@” 항목을 추가하면 되지 않나요? 더 나아가, 왜 "@"라고 이름 붙였는지 궁금합니다. 그 드롭다운에 "모든 카테고리"라고 표시하고, 백엔드에서는 "@"를 사용하면 되지 않을까요? 소프트웨어 개발자이자 디스코스를 출시 초기부터 사용해 온 저조차도 너무 난해해서 이해할 수 없었습니다.
2개의 좋아요
이것은 분명히 주제에서 벗어난 이야기이지만, 제 의견을 두어 마디 덧붙이고 싶습니다. Discourse UI에 대한 지속적인 불만은 제 파트너들과 프로젝트 이해관계자들을 Discourse로 유치하려는 제 시도를 완전히 실패로 이끌고 있습니다. 그들은 모두 UI를 싫어합니다. 모든 면에서 혼란스럽기 때문에 아예 사용할 수조차 없습니다. 또한 Kanban을 유용한 도구로 설정할 수 없다는 점은, Discourse를 프로젝트 관리 도구로 사용하도록 설득하려는 저의 파트너들의 불만만 더 키우고 있습니다. 이 주제에서 논의되고 있는 실제 문제로 돌아가자면, 설정 패널을 열어 Kanban 목록을 자기 마음에 맞게 구성하기만 하는 매니저에게 “@” 기호를 도대체 어떻게 설명해야 할까요? Discourse 공간에 진입하는 순간 사람들이 완전히 혼란에 빠지게 만드는 것은 바로 이런 사소한 것들이 쌓여서 그렇습니다. 그들은 즉시 떠나기를 시도하고, 이 플랫폼에서 더 이상 소통하지 말라고 저에게 말합니다. 왜냐하면 그들의 시간을 낭비하기 때문입니다. 저는 사람들이 Discourse에 대해 열정적으로 느끼게 만드는 데 무력합니다. 더 나쁜 것은, 어떤 이유에서인지 Discourse 팀이 UI의 일부 측면을 개선하기보다는 오히려 악화시키고 있다는 점입니다. 여기 최근 업데이트와 제 비판을 참고하세요: Now that the topic title is editable by click, I can't simply copy it without entering the edit mode
참고로, 제가 @MyCategory를 입력하면(이것이 @가 무엇을 하는지 이해하려다 직관적으로 입력한 것입니다), 검증 오류를 알려주지 않습니다. 프로그래머의 관점에서 명백하고 “저장 중…” 업데이트된 설정 값을 저장할 때 쉽게 감지할 수 있는 상황에서, 제가 잘못하고 있다는 것을 알려주지 않는 것이 어떻게 괜찮은 것으로 간주되는지 궁금합니다.
특히 누군가가 Discourse를 떠나 Discord로 돌아갔다는 것을 보고 나서야 모든 것을 말해야 했다는 점이 죄송합니다. 이는 제 UI에 대한 우려와 불만을 더욱 확인시켜 주었습니다.
4개의 좋아요
나는 정말 열심히 노력했지만, 복잡성이 너무 많습니다. 마치 예전 안드로이드 대 아이폰 전쟁 때처럼요.
안드로이드는 원하는 것을 마음대로 커스터마이즈할 수 있었죠.
아이폰은 기능이 매우 제한적이었지만… 그냥 잘 작동했습니다.
지금 디스코스의 상황도 마찬가지입니다. 저는 우리가 앙투안 드 생텍쥐페리의 길을 더 따를 필요가 있다고 생각합니다: “완벽함은 더 이상 추가할 것이 없을 때가 아니라, 더 이상 뺄 것이 없을 때 달성된다.”
혼란이 너무 많습니다(예를 들어, 첫 번째로 떠오르는 것만 해도 DM과 개인 채팅의 차이 같은 것들이 있죠). 그래서 사람들이 이 플랫폼을 자유롭게 사용하도록 설득하기가 정말 어렵습니다. 디스코드에서는 마찰이 훨씬 적습니다. Skool도 마찬가지입니다. 저는 우리가 더 많은 기능을 추가하는 것이 아니라, 이 방향으로 나아가야 한다고 생각합니다.
2개의 좋아요
최근에 한 고객이 정확히 말씀하신 이유, 즉 과도한 복잡성 때문에 Discourse를 떠났습니다.
솔직히 말해서, 몇몇 Discord 서버를 살펴봤는데, 그다지 단순하다고 말하기는 어렵지 않나요? 요즘 Discord 서버에는 봇을 포함해 추가할 수 있는 기능이 정말 많습니다.
Discord나 다른 맞춤형 폐쇄형 앱으로 전환하는 가장 큰 단점 중 하나는 SEO를 잃게 된다는 점입니다. 물론, 그 부분은 귀하에게는 영향을 주지 않을 수도 있겠지요.
1개의 좋아요
구현한 사람이 카테고리나 태그로 필터링되지 않은 상태의 최상위 토픽 목록을 나타내는 고유 기호로 @를 선택했습니다. 이는 forum.example.com/latest 또는 forum.example.com/top과 유사합니다. 따라서 보드를 해당 위치에 적용하려면 @를 별도의 항목으로 입력해야 합니다.
이것이 혼란스럽다는 데 동의하지만, 전역 카나반 보드를 원하지 않는 한 무시해도 되는 부분입니다.
그렇지 않습니다. 이미 이렇게 설정을 사용하고 있는 사이트들의 설정이 되돌아가지 않도록 마이그레이션도 생성해야 하므로, 카테고리 드롭다운으로 이동하는 과정이 복잡해질 뿐입니다.
테마 설정은 코어 API에 의해 결정되므로, 카테고리 목록 유형을 사용할 때 테마 자체에서 추가 옵션으로 확장할 수 없습니다.
Discourse는 거대한 회사가 아니므로, 가장 많이 사용되는 기능과 컴포넌트 리팩토링(참고로 무료입니다)에 집중할 수 있는 시간이 제한적입니다. 누군가가 카나반 설정 개선에 스폰서를 제공하는 경우, 이를 더 높은 우선순위로 다룰 수 있습니다.
Discord에 카나반 보드 기능이 있나요? 찾아보았지만, 외부 카나반 서비스와 통합되는 봇 외에는 거의 찾지 못했습니다.
일定的한 통제력도 잃게 됩니다. 사용자는 Discord의 사용자가 되고, 그들이 게시하는 콘텐츠도 Discord의 콘텐츠가 됩니다. 누군가가 Discord에 비용을 지불할 때, 그 이익은 Discord의 것입니다. 모든 플랫폼에는 트레이드오프와 비용이 따릅니다.
8개의 좋아요
네, 현재로서는 언제 카나반 기능에 주의를 기울일 수 있을지 불분명합니다.
어느 시점에 다시 살펴보고 싶은 부분입니다. 테마 컴포넌트의 채택이 이런 종류의 기능이 더 필요하다는 욕구가 존재한다는 증거를 제공했다고 생각합니다.
테마 컴포넌트로 구현한 것에는 장점이 있습니다. 어떤 관리자든 쉽게 찾아서 설치할 수 있기 때문이죠. 하지만 예상했던 방식으로 디자인하기 어렵게 만드는 상당한 제약 사항도 있습니다.
만약 우리가 다시 살펴본다면, 두 가지 가능한 경로가 있다고 생각합니다. 카나반 보드에 필요한 기능 세트를 테마 컴포넌트에서 사용할 수 있는 API를 개선하는 근거로 삼거나, 이를 핵심 기능이나 플러그인으로 전환하여 목적에 맞는 서버 API를 추가하기 위해 더 많은 접근 권한을 확보하는 것입니다.
그때까지는 특정 문제에 대한 조정만 이루어질 가능성이 높다고 생각합니다.
7개의 좋아요
맞습니다. 하지만 그 부담은 사용자들에게 있는 것이 아니라, 서버 소유주인 우리에게 있습니다. 사용자들은 가장 단순한 방식으로만 이를 경험합니다:
채널 선택 → 메시지 전송 이면 끝이니까요!
칸반 보드는 없습니다. Watching과 Tracking의 차이를 이해해야 할 필요도 없습니다. 디스코드가 이 기능도 할 수 있다면 얼마나 멋질 텐데라는 식의 수많은 부가 기능도 없습니다.
이 모든 기능은 기술에 밝은 사람들, 즉 소유주/관리자들에게는 정말 멋진 것입니다.
하지만 일반 사용자들에게는 커뮤니티의 소속감이 중요합니다. 그들은 자유롭게 자신을 표현할 수 있고, 수백 가지(정말 많은 것 같습니다) 다른 옵션, 용어, 기타 설정들을 하나하나 파악해야 하는 부담 없이 활동하기를 원합니다.
5개의 좋아요
이것이 바로 이해관계자들로부터 받는 피드백입니다. 채팅과 개인 토픽을 구별하지 못해 혼란스러워합니다.
현재 진행 중인 프로젝트에서, 프로젝트 오너는 Discourse를 시도해본 후 단순히 사용법을 익히기 어렵다고 말하며 Basecamp를 탐색하고 있습니다. 저는 Discourse의 뛰어난 기능과 역량을 잘 알고 있기 때문에 이를 옹호하고 있지만, 저조한 사용성, UI와 용어 체계의 혼란이 항상 기능성을 압도하기 때문에 제가 할 수 있는 일이 많지 않습니다. 게다가 일반 비기술적 사용자들이 싫어하는 마크다운을 사용해야 하며, 이것이 왜 처음부터 WYSIWYG(본인이 보는 그대로)가 아닌지 설명하기도 어렵습니다. 다행히도 Discourse 팀이 마침내 적절한 편집기를 개발하고 있습니다. 대부분의 사용자는 몇 가지 기능(서식 설정, 표, 색상, 이미지, 코드 스니펫)만 갖춘 단순한 워드와 같은 텍스트 편집기를 원합니다. 일반 사용자에게 마크다운 형태로 이러한 기능을 요구할 이유는 전혀 없습니다. AI와 같은 더 정교한 기능은 최종 사용자가 왜 자신의 게시물 텍스트 편집기가 세로로 두 열로 나뉘어 있는지 이해하지 못할 때 무용지물이 됩니다. 그들이 고민하는 것은 AI가 아니라 바로 그 문제이기 때문입니다.
6개의 좋아요
그들은 모든 데이터를 가지고 있습니다. 그것이 거래의 핵심이며, 초기의 좌절감은 이해합니다. 하지만 지난 몇 달간 Discourse에서 많은 개선점을 보고 있습니다.
관리자는 채팅과/또는 개인 메시지 사용을 중단하고 시스템을 단순화할 수 있습니다. 시간도 걸리고, 누구나 이해하듯 학습 곡선도 있습니다. 모든 것에는 장단점이 있듯이요.
팀에 행운을 빕니다. 또한 우리는 자연스러운 진화 과정에 기여하고 시간을 투자해야 한다고 생각합니다.
3개의 좋아요
단기적으로는 괜찮은 동작이지만, 정보를 조직화하는 측면에서는 아주 좋은 역학 관계라고 보기 어렵지 않나요?
임의로 글을 올리는 사용자 <> 잘 정리된 웹사이트.
그래서 Discourse는 모더레이션과 정보를 정리하기 위한 도구에 중점을 두는 것인가요?
1개의 좋아요
우리 커뮤니티 구성원들이 콘텐츠를 소비하는 방식이 어떻게 변하고 있는지, 그 변화의 흐름에 우리가 따라가지 못하고 있는 바로 그 사례입니다.
저도 똑같은 결정에 직면했었습니다. 견고하고 잘 정리되어 있으며 SEO가 뛰어나고, 우리가 만드는 콘텐츠의 성격상 *유산(legacy)*을 남길 수 있는 무언가를 만들어야 하는지 말이죠.
하지만 오늘날의 사람들(물론 이건 일반화입니다)은 예를 들어 Slack이 최근 90일간의 기록만 유지함으로써 무언가를 빼앗아 간다고 느끼지 않습니다.
제 커뮤니티 회원 중 한 명(30대 초반에 막 들어선, 매우 성공적인 기업가)은 오늘날 정보의 나이가 3개월 이상이면 읽지 않는다고 말했습니다. 모든 것이 너무 빨리 변하기 때문에 구식 자료를 뒤지는 것은 그저 시간 낭비일 뿐이라고요. 비즈니스든, 과학이든, 아니면… 글쎄요, 삶이든 마찬가지입니다.
물론 우리가 여기서 다루고 있는 것처럼, 몇 달 후에나 업데이트될 수 있는 플러그인에 대한 스레드와 같은 경우라면 그건 타당한 사례입니다. 하지만 그 외의 경우에는, "커뮤니티 구축"이라는 측면에서 "소속감"을 느끼고 마찰을 거의 없이 이 커뮤니티와 상호작용할 수 있는 것이 우리를 압도하는 모든 옵션을 파악해 내는 것보다 더 중요합니다.
저는 이전 스레드들에서 이 문제에 대해 이야기한 적이 있습니다. 그때 저는 디스코urs(Discourse)와 비교했을 때 스쿨(Skool)의 성공 요인에 대해 질문했었죠.
5개의 좋아요
완전히 공감합니다. 좋은 통찰 감사합니다.
3개의 좋아요
정확히 말씀드리면, 저는 Discourse에 놀라운 가능성을 보고 있습니다. 그리고 커뮤니티 구축에 대한 제 경험을 살려 팀에 도움이 될 수 있다면 기꺼이 돕겠습니다.
3개의 좋아요