How could end users submit feedback, that say, there is no feedback button?
Then, armed with the feedback that there is no feedback button, would you consider adding one?
Sure, you could do end user surveys to dig up some UX feedback, but end users with something to say in the first place would still have no way to give it to you.
Yes, the future feedback button could say:
For problems like “Johnny replied to my post with a swear word”, “I am not allowed to join the Lawnmower discussion group”, etc. contact your administrator. Click here…
But for problems like “the top of the screen is cut off”, well, yes, we would be delighted to have your feedback! Click here…
이러한 비독성적이고 민감하지 않은 일반적인 피드백의 경우, Contribute > Site feedback 카테고리에 토픽을 게시하도록 사용자를 권장합니다. 피드백을 위한 이러한 공개적 접근 방식의 장점은 커뮤니티 전체를 문제 해결 방식 및 솔루션에 대한 논의에 참여시킬 수 있다는 점이며, 이전 논의들을 확인할 수 있어 여러분(그리고 다른 사람들)이 반복해서 설명할 필요가 없다는 것입니다. 왜 이런 내용을 숨기겠습니까? 장기 회원들이 다른 사람들을 도울 수도 있어 여러분이 직접 개입할 필요가 없을 수도 있습니다!
이러한 사용 사례는 이미 게시물 신고 시스템에 구현되어 있으며 처리되고 있습니다. 특정 게시물을 정확히 참조할 수 있어 더 좋습니다.
개별 사이트마다 설정과 커스터마이징이 크게 달라질 수 있으므로, 문제를 해당 사이트의 Contribute > Site feedback 카테고리에 먼저 보고해야 하는지, 아니면 이곳에 직접 보고해야 하는지 혼란스러울 수 있습니다. 일반 사용자의 경우, 어떤 문제가 잘못된 설정, 사이트별 맞춤 테마, 또는 서드파티 플러그인 등 무엇에 의해 발생했는지 식별하기가 쉽지 않습니다. 또한 해당 사이트의 문제 해결 방법을 조언하거나, 문제를 더 깊이 디버깅하는 데 필요한 핵심 정보를 제공하기에도 가장 적절하지 않은 위치에 있습니다.
물론 사용자가 메타(Meta)에서 피드백을 제공할 수는 있지만, 모든 것이 어떻게 연결되는지에 대한 더 깊은 이해가 필요하므로, 그것이 진정으로 유용하려면 상당한 시간이 소요됩니다. 모든 포럼에 사용자가 쉽게 접근할 수 있는 두드러진 링크를 배치하면, 사이트 관리자가 더 잘 해결할 수 있는 많은 주제들이 생성될 것이라고 생각합니다.
Anyway, I was just thinking, there is no direct route, for end users on thousands of sites, to communicate directly with you guys. There is no official pathway they can find.
This contrasts with very many other pieces of software, where there’s always a feedback button in the corner somewhere.
Well I’m saying a vanilla installation of… Of what? No, the software doesn’t have any name at all. At least to the end user. Anyway a vanilla installation of it should come with deep down in the menu somewhere a way to contact you guys with some ux improvement suggestions.
Let’s see, I use the open street map installation of this software, the bitwarden installation of this software… I never checked who the administrators were.
Every single one of my visitors who has something to ask and doesn’t create account for that know for what and why there is /about-page. You don’t want to use it because by your opinion dozens of buttons is sign of the very best UX. No, it is not. Doing things such way that is easy for an user is good practise of UX. Like using /about page as about majority of sites has solved out same thing.
I am saying, for example, on About - Bitwarden Community Forums , or About - OpenStreetMap Community Forum , or anywhere else on those sites, users are to be under the impression that the entire site was constructed by the organization who is administrating it. And there was nobody else in the picture.
Legally the full suite of software you are using, add-ins and all is up to each individual site and its owners.
You aren’t necessarily just using a specific version of Discourse. Even if that version number was exposed it might be misleading.
Just because a site uses “Discourse version 3.1” does not in any way preclude the possibility that the site in queston is using significant local customisations which could affect the behaviour of anything.
I think you are missing the significant point here that Discourse is a platform not a single entity and that platform can be downloaded, installed and then customised in significant ways and in ways the core developers didn’t necessarily intend.
You can glean some information from the version number but not enough to pin down all the exact code you are interacting with.
Nor will any of that guarantee the trustworthiness of a specific site and the way it is run.
That is why you should take these questions to the actual site you are using.
Don’t expect the core Discourse community to always deal with specific issues you have with the sites you are using.
Have you approached the sites you are using and given them any feedback?
It smacks a little of “going above their heads” if you only discuss these issues on meta and not with the site owners themselves?
Are you hoping to make changes to the software to that might override what the site owners might want or prefer?
We are supposed to enter all the Discourse sites one reads.
But it is Discourse’s policy not to reveal that a Discourse site is a
Discourse site, unless one turns off javascript, to reveal the Powered
By message.
Again — and why is this so important? Users aren’t wandering all over the internet wondering what is the platform behind everything.
There in one situation when an user needs to know if a forum is Discourse or not: DiscourseHub. And I’m totally sure that everyone who’s using the Hub sees right away if a forum is Discourse or not.
You are avoiding answering to one question all the time: why. Yes, we know for you it is important piece of data for some reason, but you are talking about general users here.
And even if you check the version, the next questions here like:
which plugins are active?
what theme/ theme component/ custom change is used?
how is setting xyz configured?
Are all questions only an admin can answer. That’s why you report the problem to the admin of that special discourse site.
Discourse can be customized in many ways to fit the different needs of different communities. So if it does not fit the admin of that site is the one, who can decide where a change is needed.
It’s not a third party though. The site you are using is the entity responsible for providing the service. They can escalate to the core team/open source community as appropriate.
For example, they might be leveraging a plugin that is made by a third party. Only they will know who to contact.
