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개의 좋아요

Interesting to hear it’s been investigated in the past, particularly with electron, though I imagine it would be quite a sizeable effort to produce and maintain properly.

This is true but unfortunately it is MSTeams, and I don’t think we can use Discourse Chat: we’re encouraging users to share information between customer projects on Discourse, but that needs to be moderated strictly – Customer A cannot learn about Customer B’s secret sauce and vice versa. By using chat we muddy that behavioural expectation in Discourse, and sciphon good information from the shared/open part of the platform into fully private conversations. Even the “move conversation from chat to topic” functionality may not help here - people rush directly to the next thing in a work environment, and many of them will never learn to use this functionality.

This is completely true and thankfully hasn’t taken much encouragement.

How do we solve information going in the other direction though? The questions that are asked in MSTeams don’t result in links, don’t get broadcast and are lost in the Microsoft Ether. The user knows their recipient will recieve a notification immediately. With Discourse this is not the case. Even with email notifications, those are mixed with other messages, and typically get filtered into a folder. This immediacy is a key reason those questions are asked in MSTeams rather than Discourse.

I can vouch for this as a good process. It’s had decent success, particularly when we can sync those topics from another platform with the same markdown flavour like Gitlab.

Thank you for providing these guidelines as reference. Our internal process for this has been a mess and remains undefined. There’s too many platforms, and too many chefs. I’ll bring these up as good examples.

If you feel it’s better suited in that direction I’m happy for you to move it. For us the key problem is losing great long term conversations to MSTeams. Whilst we can continue to insist on asking those questions in Discourse instead, one part of the why is the immediacy of MSTeams. That’s a point where Discourse is currently losing and I think it’s a massive shame. I don’t see us replacing MSTeams with Discourse chat, so I feel like there needs to be another way of competing on a technical level.

In terms of the what, a desktop app could be a way forward, but I can see it being a lot of effort and is it really worth that effort? Probably not.

On the other hand, my search lead me to a few notification mulitplexers/centres. Perhaps it’s worth monitoring projects like these for future integrations? I suspect the ideal solution would be a single platform that centralises all of these notifications, similar to how Discourse Hub centralises a user’s Discourse notifications.

I had a 3-4 minute look at the following options. Not sure if you guys have looked in to them in terms of providing integrations? Would something like this even make sense?

https://novu.co/ - looks promising, though I couldn’t see a list of supported platforms
Pushover: Applications and Plugins - not sure if enterprise would go for this
GitHub - notifo-io/notifo: Multi channel notification service for collaboration tools, e-commerce, news service and more. · GitHub looks pretty nice, web interface seemed pretty slick and easy.

1개의 좋아요

Have you installed the Discourse web app as a PWA on Windows? It will show a notification number badge on the Task Bar icon. This works out of the box.

3개의 좋아요

This is a really good suggestion. I’ll give it a try for a few weeks and see how it goes. One downside is that it’s single tab - at least in chrome. But for this use case of monitoring notifications it’s still a good improvement.

For anyone else looking to try this, on chrome click the desktop icon next to the bookmark star in the url bar

image

1개의 좋아요

Yeah combine this with watching first post on specific categories might help you get alerted of unread new topics of interest.

2개의 좋아요

image

Already loving it! Great suggestion :heart:

5개의 좋아요

See my query here: Implement Badging API - #10 by merefield

3개의 좋아요

Been using this for a week, and still love it. I’ve been pushing it accross the company and expect a very positive impact on response times.

For reference, this works in:

Here is a quick video of how to set this up with edge. I ask it to run on startup for extra convenience.
Note: First thing I click is in the address bar. This isn’t clear in the video due to compression artifacts.

There is also a guide for Chrome with images here: Implement Badging API - #11 by Tris20

1개의 좋아요

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

4개의 좋아요