피드백 버튼

피드백 버튼이 없는데, 최종 사용자는 어떻게 피드백을 제출할 수 있죠?

그런데 '피드백 버튼이 없다’는 피드백을 받게 되면, 버튼 추가를 고려하시겠습니까?

물론 최종 사용자를 대상으로 설문 조사를 실시하여 UX 피드백을 수집할 수는 있습니다. 하지만 애초에 할 말이 있는 최종 사용자에게는 그 말을 전달할 방법이 여전히 없게 되죠.

네, 미래의 피드백 버튼에는 다음과 같은 문구를 넣을 수 있습니다:

“존니가 제 게시물에 욕설로 답글을 남겼습니다”, “잔디깎기 토론 그룹에 가입할 수 없습니다” 등의 문제는 관리자에게 문의하십시오. 여기를 클릭하세요…

하지만 "화면 상단이 잘립니다"와 같은 문제는, 네, 여러분의 피드백을 기꺼이 환영합니다! 여기를 클릭하세요…

참고로, 저는

또는 특정 사이트에만 적용되는 피드백 채널인
https://meta.discourse.org/c/site-feedback/
에 대해 이야기하는 것이 아닙니다.

1개의 좋아요

이러한 비독성적이고 민감하지 않은 일반적인 피드백의 경우, Contribute > Site feedback 카테고리에 토픽을 게시하도록 사용자를 권장합니다. 피드백을 위한 이러한 공개적 접근 방식의 장점은 커뮤니티 전체를 문제 해결 방식 및 솔루션에 대한 논의에 참여시킬 수 있다는 점이며, 이전 논의들을 확인할 수 있어 여러분(그리고 다른 사람들)이 반복해서 설명할 필요가 없다는 것입니다. 왜 이런 내용을 숨기겠습니까? 장기 회원들이 다른 사람들을 도울 수도 있어 여러분이 직접 개입할 필요가 없을 수도 있습니다! :+1:

이러한 사용 사례는 이미 게시물 신고 시스템에 구현되어 있으며 처리되고 있습니다. 특정 게시물을 정확히 참조할 수 있어 더 좋습니다. :+1:

4개의 좋아요

개별 사이트마다 설정과 커스터마이징이 크게 달라질 수 있으므로, 문제를 해당 사이트의 Contribute > Site feedback 카테고리에 먼저 보고해야 하는지, 아니면 이곳에 직접 보고해야 하는지 혼란스러울 수 있습니다. 일반 사용자의 경우, 어떤 문제가 잘못된 설정, 사이트별 맞춤 테마, 또는 서드파티 플러그인 등 무엇에 의해 발생했는지 식별하기가 쉽지 않습니다. 또한 해당 사이트의 문제 해결 방법을 조언하거나, 문제를 더 깊이 디버깅하는 데 필요한 핵심 정보를 제공하기에도 가장 적절하지 않은 위치에 있습니다.

물론 사용자가 메타(Meta)에서 피드백을 제공할 수는 있지만, 모든 것이 어떻게 연결되는지에 대한 더 깊은 이해가 필요하므로, 그것이 진정으로 유용하려면 상당한 시간이 소요됩니다. 모든 포럼에 사용자가 쉽게 접근할 수 있는 두드러진 링크를 배치하면, 사이트 관리자가 더 잘 해결할 수 있는 많은 주제들이 생성될 것이라고 생각합니다.

4개의 좋아요

어쨌든, 이렇게 생각해보면 수천 개의 사이트에서 서비스를 이용하는 최종 사용자들이 여러분과 직접 소통할 수 있는 직접적인 경로가 없습니다. 공식적으로 찾을 수 있는 경로도 없죠.

이는 많은 다른 소프트웨어와 대비됩니다. 그런 소프트웨어에서는 항상 구석 어딘가에 피드백 버튼이 있는 법이니까요.

1개의 좋아요

Discourse의 주요 목적이… 피드백이기 때문일까요? 다른 소프트웨어들은 다른 일을 수행하는 경우가 많아서, 연락할 다른 방법이 없는 곳이 많습니다.

제 경우를 들면 이메일 주소를 표시합니다. 이메일을 사용할 수 없는 사람이 있을 수도 있지만, 저는 그 가능성을 낮게 봅니다.

1개의 좋아요

사용하시는 사이트의 관리자와 얼마나 많이 대화하시나요?

1개의 좋아요

음, 제 말은 바닐라 설치판에… 뭘까요? 아니, 소프트웨어에 이름이 아예 없어요. 적어도 최종 사용자에게는요. 어쨌든, 이 소프트웨어의 바닐라 설치판에는 메뉴 어딘가에 UX 개선 제안으로 여러분에게 연락할 수 있는 방법이 포함되어 있어야 합니다.

1개의 좋아요

음, 이 소프트웨어의 OpenStreetMap 설치판과 Bitwarden 설치판을 사용하곤 하는데, 관리자가 누구인지 한 번도 확인해 본 적이 없었어.

2개의 좋아요

다시 말하지만. 왜 자신을 최종 사용자라고 부르는 건가요?

질문이 있어서 계정을 만들지 않는 제 방문객들은 누구나 /about 페이지가 무엇이고 왜 있는지를 알고 있습니다. 당신은 수십 개의 버튼이 최상의 UX의 신호라고 생각해서 이 페이지를 사용하고 싶지 않은 거죠. 아니요, 그렇지 않습니다. 사용자가 쉽게 할 수 있도록 하는 방식은 좋은 UX 관행입니다. 대부분의 사이트가 동일한 문제를 해결하기 위해 /about 페이지를 사용하는 것과 같습니다.

하지만 어딘가에서 당신에게는 적합하지 않은 것 같습니다.

1개의 좋아요

하지만 내 생각엔 사이드바 때문에 /about 페이지의 가시성이 많이 떨어졌어요. 상단에 있던 햄버거 메뉴 방식이 훨씬 나았어요.

2개의 좋아요

예를 들어 About - Bitwarden Community Forums, About - OpenStreetMap Community Forum, 또는 해당 사이트의 다른 곳에서 사용자는 해당 사이트를 관리하는 조직이 사이트 전체를 구축했으며, 다른 누구도 관여하지 않았다고 인식하게 됩니다.

모든 사이트에는 그런 카테고리가 있는 것은 아니지만, 사이트 자체에 대한 메타 카테고리를 별도로 두는 경우는 꽤 흔합니다.

예를 들어, 다음에서 링크된

이 바로 해당 사이트에 대한 피드백을 제공하기 위해 사용되는 카테고리입니다:

3개의 좋아요

참고로, 최종 사용자가 자신이 어떤 소프트웨어를 사용 중인지 공식적으로 알 수 있는 방법을 마침내 찾았습니다!

$ w3m -dump https://community.*.com/ | grep -i discourse
Powered by Discourse, best viewed with JavaScript enabled

맞습니다! 사용자는 자바스크립트를 꺼야 합니다.

아쉬운 점은 이제 이 비밀을 말해 버렸으니, "파견된 팀이 이를 파괴하러 올 것"이라는 겁니다.

자, 다시 본론으로.

우리는 HTML 태그를 확인합니다.

meta name=“description” content="Report issues with this Discourse site and also request new features, categories or changes.

링크 미리보기에서는 훌륭해 보이지만, 사용자가 해당 페이지를 방문하면 그런 문구는 어디에도 없습니다!

자, 우리는

을 찾지만, 메시지를 방문할 때 'Discourse’라는 단어조차 하이퍼링크로 연결되어 있지 않습니다.

어쨌든,
https://en.wikipedia.org/wiki/Talk:Comparison_of_Internet_forum_software#Transparency_to_end_users
이것이 제가 말하려는 것입니다.

아니면 여기 예시로 사용해보세요:

질문자님의 우려가 크게 의미 있다고 보기는 어렵습니다.

법적으로 사용 중인 소프트웨어의 전체 구성, 애드인 포함은 각 사이트와 그 소유자에게 달려 있습니다.

특정 버전의 Discourse만 사용하는 것이 아닙니다. 해당 버전 번호가 노출되더라도 오해의 소지가 있을 수 있습니다.

사이트가 "Discourse 버전 3.1"을 사용한다고 해서, 해당 사이트가 동작에 영향을 미칠 수 있는 상당한 로컬 커스터마이징을 사용하고 있을 가능성을 배제할 수는 없습니다.

Discourse가 단일 개체가 아닌 플랫폼이며, 이 플랫폼은 다운로드 및 설치된 후 핵심 개발진이 의도하지 않았을 수도 있는 방식으로 상당한 수준에서 커스터마이징될 수 있다는 중요한 점을 놓치고 계신 것 같습니다.

버전 번호에서 일부 정보를 파악할 수는 있지만, 상호작용 중인 정확한 모든 코드를 파악하기에는 부족합니다.

그리고 그런 정보만으로는 특정 사이트의 신뢰성이나 운영 방식이 보장되지도 않습니다.

그래서 이러한 질문은 실제로 사용 중인 사이트로 직접 가져가야 합니다.

사용 중인 사이트의 특정 문제에 대해 핵심 Discourse 커뮤니티가 항상 처리해주기를 기대하지 마세요.

사용 중인 사이트들에게 접근해서 피드백을 제공해 보셨나요?

이러한 문제를 메타(meta)에서만 논의하고 사이트 소유자들과 직접 다루지 않는다면, 이는 다소 "상급자에게 바로 보고한다"는 인상을 줄 수 있습니다.

사이트 소유자가 원하거나 선호하는 것을 무시할 수 있는 소프트웨어 변경을 희망하고 계신 건가요?

그분들을 논의에 포함시키고 계신가요?

다음 앱을 살펴보겠습니다.

이 앱에서는 읽는 모든 Discourse 사이트를 입력해야 합니다.

하지만 Discourse의 정책상, JavaScript를 끄지 않는 한 해당 사이트가 Discourse 기반임을 알리지 않습니다. JavaScript를 끄면 ‘Powered By’ 메시지가 표시됩니다.

따라서 https://whatcms.org/ 를 사용해 확인해야 합니다.

실제로 이 사이트는 Discourse의 버전까지 알려줍니다.

다만, 실제 버전은 비공개이므로 정확하지 않을 수 있습니다.

어쨌든, 사용자가 해당 사이트가 Discourse를 사용 중인지 확인할 공식 방법이 없습니다!

다시 한번 묻고 싶습니다 — 왜 이것이 그렇게 중요한가요? 사용자들은 인터넷을 돌아다니며 모든 것 뒤의 플랫폼이 무엇인지 궁금해하지 않습니다.

사용자가 포럼이 Discourse인지 아닌지 알아야 하는 상황은 딱 하나 있습니다: DiscourseHub. 그리고 Hub를 사용하는 모든 사람이 해당 포럼이 Discourse인지 아닌지 바로 알아볼 수 있다는 것은 확신합니다.

당신은 한 가지 질문에 대한 답변을 계속 회피하고 있습니다: 왜. 네, 당신에게는 그 데이터가 어떤 이유로든 중요한 부분이라는 것을 알고 있습니다. 하지만 당신은 여기서 일반 사용자들에 대해 이야기하고 있는 것입니다.

버전을 확인하더라도, 여기서 다음과 같은 질문들이 남아 있습니다:

  • 어떤 플러그인이 활성화되어 있나요?
  • 어떤 테마/테마 구성 요소/사용자 정의 변경 사항이 사용되고 있나요?
  • 설정 xyz는 어떻게 구성되어 있나요?

이 모든 질문은 관리자만 답변할 수 있는 내용입니다. 따라서 해당 Discourse 사이트의 관리자에게 문제를 보고해야 합니다.

Discourse는 다양한 커뮤니티의 서로 다른 요구 사항을 충족하기 위해 다양한 방식으로 커스터마이즈될 수 있습니다. 따라서 사이트의 요구 사항에 맞지 않는 부분이 있다면, 변경이 필요한 부분을 결정할 수 있는 사람은 해당 사이트의 관리자입니다.

1개의 좋아요

참고로, Discourse Land는 제3자 앱입니다:

@Jagster 님이 말씀하신 대로, DiscourseHub가 공식 버전입니다.

다만, 피드백을 제공하기 위한 특정 버튼을 추가하는 것과 관련하여 이 주제는 다소 주제에서 벗어난 것으로 보입니다.

이 아이디어는 제3자를 거치지 않고 사용자가 직접 피드백을 보낼 수 있는 방법을 제공하는 것입니다.

다만, 이는 제3자가 아닙니다. 사용자가 현재 이용하고 있는 사이트가 서비스를 제공하는 주체입니다. 이들은 적절한 시점에 핵심 팀이나 오픈소스 커뮤니티로 문제를 에스컬레이션할 수 있습니다.

예를 들어, 제3자가 개발한 플러그인을 활용하고 있을 수 있습니다. 누구에게 연락해야 하는지는 해당 사이트 측만 알 수 있습니다.

4개의 좋아요