Discourse용 경량 데스크톱 앱의 실현 가능성은? 참여도 또는 알림 인지도를 개선할 수 있을까요?

오늘 AMA에서 나온 질문에 대한 후속 글입니다. 데이비드는 이 질문의 맥락을 분명히 이해하고 매우 훌륭하게 답변해 주셨습니다. AMA 영상이 공개되면 이 주제에 링크를 달겠습니다.

초기 질문은 다음과 같았습니다.

MSTeams는 시작 메뉴(타스바)에 알림을 표시하는 독립형 애플리케이션입니다. 이 때문에 우리 회사의 커뮤니케이션을 지배하고 있습니다. 모든 사용자에게 항상 한 번의 클릭 거리에 있으며, 새로운 정보가 있으면 즉시 알림을 주기 때문입니다. Discourse의 독립형 앱을 만들거나, 다른 방식으로 이러한 데스크톱 알림 기능을 제공할 수 있는 방법에 대한 의견이 있을까요?

조금 더 구체적으로 말하자면, '무엇을’이 아니라 '왜’가 중요합니다. 여기에서의 '왜’는 다음과 같습니다.

  • 큰 회사라고 상상해 보세요. 여러 커뮤니케이션 채널이 있습니다: Teams, Outlook, Discourse, Sharepoint 등 몇 가지 더.
  • 바쁜 사람이라고 상상해 보세요. 누군가 또는 어떤 팀에게 무언가에 대해 연락하고 싶습니다.

어떤 선택을 하시겠습니까?

a) 웹 브라우저를 열고 URL을 입력합니다(알고 있다면), 로그인하고, 올바른 카테고리를 찾아, 주제를 만들고, 제목을 붙이고, 질문을 자세히 서술하고, 제출을 누른 후 답변을 인내심 있게 기다립니다.

b) 시작 메뉴의 MSTeams 아이콘을 클릭하고, 도움이 될 수 있는 사람이나 그룹의 이름을 입력하고, 메시지를 입력한 후 전송을 누릅니다. 상대방이 그들의 시작 메뉴에 주황색으로 깜빡이는 알림을 즉시 받게 될 것이라는 것을 알고 있습니다.

저는 주황색 깜빡임 자체를 옹호하지는 않지만, MSTeams로 상당한 양의 콘텐츠가 유출되고 있다는 점을 보고 있습니다. 이것이 제가 해결하고 싶은 실제 문제이며, 알림 시스템이 우리가 열세를 보이는 지점이라고 생각합니다.

필요한 마찰(절차)이 있습니다:

  • 카테고리 선택
  • 주제에 대한 세심한 주의

하지만 데스크톱 앱이 갖지 않는 추가적인 마찰도 있습니다.

  • Discourse를 사용할지 생각하기 - 도움이 될 수 있을까?
  • Discourse를 사용하기로 결정하기 - 그만한 가치가 있을까? 내 주제를 누군가가 볼 때까지 얼마나 걸릴까?
  • 브라우저 열기
  • 웹사이트로 이동
  • 로그인

MSTeams의 경우 '생각’하고 '결정’하는 과정은 일어나지 않습니다. 버튼 하나를 클릭하는 것이 너무 간단해서, 저는 즉시 질문을 시작할 수 있는 위치에 있게 됩니다.

수신자 측에서도 알림이 있는지 알기 어렵습니다. Teams는 시작 메뉴에서 읽지 않은 메시지가 몇 개 있는지 알려주므로, 새로운 것이 있는지 항상 알 수 있습니다. Discourse의 경우 웹사이트에 있거나 탭을 열어두어야 하고, 그 후에야 이를 알아차려야 합니다.

전체 데스크톱 앱이 반드시 필요하지는 않을 것 같습니다. 어쩌면 모바일 앱의 데스크톱 버전과 같은 것, 즉 Discourse 알림을 더 잘 관리하는 데 도움이 되는 것이면 충분할 것입니다.

결국 필요한 것은 Discourse가 모든 사용자에게 항상 한 번의 클릭 거리에 있고, 무엇을 볼 가치가 있는지 알기 위해 클릭이 전혀 필요하지 않은 것입니다.

이미 좋은 대안이 될 수 있는 것이 존재할까요?

5개의 좋아요

여기서도 기꺼이 논의하겠습니다 :slight_smile:

Discourse(특히 채팅 부분)를 위한 Electron 앱에 대한 몇 가지 실험이 있었습니다. 따라서 그런 것을 구현하는 것은 기술적으로 가능하지만, 넓은 사용자 기반을 위해 그런 것을 유지보수하는 것이 무엇을 의미하는지를 완전히 고려한 시도는 아직 이루어지지 않았습니다.

알림에 대한 직감이 좋다고 생각합니다만, 이것이 정말로 여기의 핵심 문제인지는 확신하지 못하겠습니다.

이 시나리오에서, 저는 사람들이 채팅을 사용할 가능성이 높다고 생각합니다. 우리는 Discourse에서도 같은 목적으로 채팅을 사용합니다. 바쁘고, 다른 일 사이에서, 질문이 있어 빠른 답변이 필요할 때, "많은 사람이 입력 중"이라는 것을 보고 답변할 준비가 된 사람들이 있는 공간에서, 당신을 기다리는 입력창에 타이핑하는 것이 훨씬 쉽습니다.

대신 다른 시나리오에 초점을 맞출 수도 있습니다. 당신은 이 혼합물에 다른 도구들을 언급했습니다:

Outlook 문제입니다. 누군가 이메일을 보냅니다. 한 사람을 CC로 빠뜨렸고, 누군가가 그 사람을 추가하려고 답장을 보냅니다. 그런 일이 몇 번 더 반복됩니다. 아, 이 스레드에 너무 많은 사람이 있네요. 누군가가 답장을 보내며 CC 목록의 절반을 삭제합니다. 다음 사람이 답장을 보낼 때 더 이상 모든 사람이 수신하지 못하고 있다는 것을 깨닫지 못합니다.

아, 그냥 이걸 Teams로 옮기자.

“야, 그 이메일 스레드에서…”
“어떤 이메일 스레드?”
“X에 관한 그거”
“내가 그 스레드에 있는 건지 모르겠네”
“제목에 'the thing about x’라고 검색해 봐”
“아, 그거 보이네”
“그래서, 소와 소에게 보낸 메시지에서는…”
“흠… 그 시점에 스레드에서 제외되었어야겠네”
“그냥 너한테 전달해 줄게”

번개처럼, 토론의 또 다른 갈라짐이 생겼습니다.

채팅에서 그 토론에 대한 _링크_만 던질 수 있다면 어떨까요?

저는 이것이 핵심 포인트라고 생각합니다. 토론을 이메일에서 Discourse로 옮기세요. 그러면 MS Teams는 더욱 좋습니다. 왜냐하면 그 모든 잡음 없이 쉽게 그 대화들에 링크할 수 있기 때문입니다.


채팅에서 Discourse에서 하는 것이 더 나은 대화들도 분명히 있습니다. 하지만 당신이 설명하듯이, 그건 더 어려운 문제입니다. 하지만 다른 도구들에서도 이미 그런 것을 보셨을 거라고 확신합니다.

“야, 이 스레드가 좀 길어지고 있네. 일단 문서로 요약할 수 있을까?”

좋아요, 좋은 단계입니다. 필요할 때 비동기(Async)로 전환할 의향이 있다는 신호입니다.

그럼 다음에 무슨 일이 벌어지나요?

공유되는 문서들의 그 댓글 스레드들은 얼마나 길까요? 올바른 것을 어떻게 찾나요?

좋아요, 네, 그 문서들 중 일부는 Discourse에서 토론하는 것이 더 나을 수도 있습니다. 하지만 제 경험상 그건 더 어려운 이동입니다. 도움이 되는 한 가지는 문서에서 Discourse로의 복사/붙여넣기가 꽤 잘 작동한다는 점입니다. 사람들이 문서에서 초안을 작성하게 하되, 그 문서가 _토론_되어야 한다는 기대가 있다면, 그것을 Discourse로 복사/붙여넣고 거기에 있는 스냅샷을 토론하게 하세요.


이것이 제가 이 문제에 접근하고 싶은 방식입니다. 사람들이 더 많은 가치를 볼 수 있는 시나리오를 찾고, 그것들을 중심으로 일종의 "플레이북"을 개발해 보세요.


저는 Discourse에서 일하는 것을 좋아합니다. 과거에 여러 도구의 조합을 사용했던 것을 이제 거의 모든 것을 Discourse로 처리하니까요. 하지만 기존 기업들은 백슬레이트(빈 캔버스)가 아니며, 이미 사용하는 도구들은 쉽게 대체되지 않습니다. 새로운 도구는 기존 도구들과 함께 공존할 수 있어야 합니다.

언제 어떤 도구를 사용할지에 대한 몇 가지 지침을 정의하는 것이 필요할 가능성이 높습니다.

과거에 사람들이 이런 종류의 것을 공개적으로 매핑하려는 시도를 했던 몇 가지 예를 소개합니다. (이 둘 다 Discourse를 포함하지 않지만, 아이디어는 여전히 꽤 잘 적용된다고 생각합니다)

이 제목을 '왜’에 관한 것으로만 바꾸고 #community-building으로 이동하고 싶지만, 먼저 그 아이디어를 좀 더 고민해 보시길 바랍니다.

5개의 좋아요

과거에, 특히 Electron을 사용하여 조사되었다는 점이 흥미롭습니다. 다만 이를 적절하게 제작하고 유지보수하려면 상당한 노력이 필요할 것이라고 상상합니다.

사실이긴 하지만, 불행히도 우리는 MSTeams를 사용해야 합니다. 그리고 디스코어 채팅을 사용할 수 있다고 생각하지 않습니다. 우리는 디스코어에서 고객 프로젝트 간 정보 공유를 장려하고 있지만, 이는 엄격하게 관리되어야 합니다. 고객 A가 고객 B의 비공개 정보를 알게 되거나 그 반대의 상황이 발생해서는 안 되니까요. 채팅을 사용하면 디스코어에서의 이러한 행동 기대치가 흐려지고, 플랫폼의 공유/공개 부분의 좋은 정보가 완전히 비공개 대화로 유출됩니다. “채팅에서 토론으로 이동” 기능조차도 여기서는 도움이 되지 않을 수 있습니다. 업무 환경에서는 사람들이 바로 다음 일로 넘어가며, 이 기능을 사용할 줄 아는 사람은 많지 않을 것입니다.

이것은 완전히 사실이며, 다행히 많은 설득 없이 이루어졌습니다.

그렇다면 반대 방향의 정보 흐름은 어떻게 해결합니까? MSTeams에서 제기된 질문들은 링크로 이어지지 않고, 브로드캐스트되지 않으며, Microsoft의 무한정인 공간(Ether)에서 사라집니다. 사용자는 수신자가 즉시 알림을 받을 것이라고 압니다. 디스코어에서는 그렇지 않습니다. 이메일 알림이 있더라도, 그것들은 다른 메시지와 섞여 있으며, 일반적으로 폴더로 필터링됩니다. 이러한 즉각성은 질문들이 디스코어가 아닌 MSTeams에서 제기되는 주요 이유입니다.

이것이 좋은 프로세스라고 보증할 수 있습니다. 특히 GitLab과 같은 동일한 마크다운 형식을 사용하는 다른 플랫폼에서 해당 주제를 동기화할 수 있을 때 상당한 성공을 거두었습니다.

참고로 이 가이드라인을 제공해 주셔서 감사합니다. 우리의 내부 프로세스는 엉망이었고 여전히 정의되지 않았습니다. 플랫폼이 너무 많고, 의사결정자(주방장)도 너무 많습니다. 이것들을 좋은 사례로 거론하겠습니다.

그 방향으로 더 적합하다고 느끼시면 옮기셔도 좋습니다. 우리에게 핵심 문제는 훌륭한 장기적인 대화가 MSTeams로 유실되는 것입니다. 대신 디스코어에서 그 질문들을 하라고 계속 주장할 수는 있지만, *왜(why)*의 한 부분은 MSTeams의 즉각성입니다. 디스코어가 현재 지고 있는 지점이며, 이는 큰 아쉽다고 생각합니다. 우리는 MSTeams를 디스코어 채팅으로 대체할 것이라고 보지 않으므로, 기술적 수준에서 경쟁할 다른 방식이 필요하다고 느낍니다.

*무엇(what)*에 관해서는, 데스크톱 앱이 하나의 방향이 될 수 있지만, 상당한 노력이 필요할 것이며, 정말 그 노력이 가치가 있는지 모르겠습니다. 아마도 그렇지 않을 것입니다.

반면, 제 검색 결과 몇 가지 알림 멀티플렉서/센터가 있었습니다. 이러한 프로젝트를 향후 통합을 위해 모니터링하는 것이 가치가 있을까요? 이상적인 솔루션은 디스코어 허브(Discourse Hub)가 사용자의 디스코어 알림을 중앙화하는 방식과 유사하게, 이러한 모든 알림을 중앙화하는 단일 플랫폼일 것이라고 추측합니다.

다음 옵션들을 3~4분 정도 살펴보았습니다. 통합 제공 측면에서 이것들을 살펴본 적이 있는지 모르겠습니다. 이런 것이 의미가 있을까요?

https://novu.co/ - 유망해 보이지만, 지원 플랫폼 목록을 찾을 수 없었습니다.
Pushover: Applications and Plugins - 엔터프라이즈가 이걸 쓸지 모르겠습니다.
GitHub - notifo-io/notifo: Multi channel notification service for collaboration tools, e-commerce, news service and more. · GitHub - 꽤 좋아 보이고, 웹 인터페이스가 꽤 세련되고 쉬워 보였습니다.

1개의 좋아요

Windows에서 Discourse 웹 앱을 PWA로 설치해 보셨나요? 작업 표시줄 아이콘에 알림 숫자 배지가 표시됩니다. 이는 기본적으로 지원됩니다.

3개의 좋아요

정말 좋은 제안입니다. 몇 주간 시도해 보고 어떻게 되는지 지켜볼 생각입니다. 단점 중 하나는 크롬에서는 단일 탭으로만 작동한다는 점입니다. 하지만 알림 모니터링이라는 이 용도에서는 여전히 좋은 개선 사항입니다.

이 방법을 시도해 보고자 하는 분들을 위해, 크롬에서는 URL 바의 북마크 별 아이콘 옆의 데스크톱 아이콘을 클릭하면 됩니다.

image

1개의 좋아요

네, 특정 카테고리의 첫 게시물을 구독하는 것과 함께 사용하면 관심 있는 미확인 새 주제에 대한 알림을 받을 수 있을 겁니다.

2개의 좋아요

image

이미 마음에 들어요! 좋은 제안이네요 :heart:

5개의 좋아요

여기서 제 쿼리를 확인하세요: Implement Badging API - #10 by merefield

3개의 좋아요

일주일 동안 사용했는데 여전히 좋습니다. 회사 내에 이 기능을 적극적으로 권장하고 있으며, 응답 시간 측면에서 매우 긍정적인 영향을 미칠 것으로 기대합니다.

참고로, 이 기능은 다음 브라우저에서 작동합니다:

Edge에서 이 기능을 설정하는 방법을 보여주는 짧은 영상을 첨부합니다. 편의를 위해 시작 시 실행되도록 설정했습니다.
참고: 제가 처음으로 클릭하는 곳은 주소창입니다. 이는 영상 압축으로 인해 영상에서 명확하게 보이지 않습니다.

이미지와 함께 포함된 Chrome 사용 가이드도 여기에 있습니다: Implement Badging API - #11 by Tris20

1개의 좋아요

트리스탄, 안녕하세요. 이렇게 시간이 지난 후에 도움이 될지 모르겠지만, 저는 디스코urs 커뮤니티용 데스크톱 클라이언트를 개발하고 있습니다. 아직 매우 새로운 앱이라, 한번 살펴봐 주시고 의견을 주시면 정말 감사하겠습니다.

4개의 좋아요