I have the impression that this happens because it is more difficult to notice in rich text mode that after you remove the text, there is still some formatting.
At least, I haven’t only noticed topics that begin with quotes before the feature was added.
So maybe it makes sense to adjust the template to prevent this.
That’s an interesting theory! I’m going to just remove the category template for now. Maybe we can find a better, less cumbersome way to educate new members to use search before posting.
@chapoi and I were also talking in chat this week about updating the support category description, which currently reads like this:
The first part shows up on the support category banner, and is not very informative.
If this successfully reduces the number of topics with quotes at the beginning, it might be necessary to also remove this from all the buttons to create support topics in the topics of official plugins, themes, and components.
Yeah, thanks for pointing that out. Those buttons are gorgeous and I love them, but they are hard to maintain and error prone when you need to make a change or create a new one.
For the long run we’ll want to edit those topics and remove those buttons. We may also want to make more adjustments there so I will hold off on touching them for now.
So far I am not noticing any more quotes at the top of support requests which is good.
Before we throw away the baby with the bathwater, wouldn’t it be a good idea to have the ability to override the placeholder in the composer via a parameterized link instead of inserting actual text content. We’re now misusing the body parameter.
Something like &placeholder=foo which would then overwrite the “Type here. Use markdown, BBCode or HTML to format.” placeholder with “foo”.
Support 카테고리의 템플릿도 정확히 같은 일을 하지 않았나요? 그것도 본문에 텍스트를 추가합니다. 이것이 제가 템플릿이 포함된 첫 번째 게시글(OP)을 작성할 때 감시 단어(watched word) 때문에 더 어려움을 겪었던 이유가 아니었나요? #marketplace에서 새 주제를 만들 때 본문에도 텍스트가 채워집니다. 그래서 저는 이 경우에도 템플릿이 보이도록 하기 위해 본문 텍스트가 링크의 일부였다고 생각했습니다.
새 주제 버튼을 사용할 때와 공식 테마나 플러그인의 버튼을 클릭할 때 본문에서 동일한 결과가 나오는 것이 여전히 합리적이라고 생각합니다.
일반적으로 공식 주제에 수동으로 입력된 이러한 버튼들이 자동으로 생성되면 더 쉬울 것입니다. 그러면 태그에서 실수가 발생할 수 없고, 업데이트도 훨씬 쉽게 할 수 있을 것입니다. 하지만 그것들은 모두 동일하게 작동하지 않기 때문에 아마도 어려울 것입니다. Data explorer는 #data-reporting에서 질문하라고 제안하지만, SSO 플러그인은 Support 대신 #support:sso에서 도움을 청하라고 말합니다.
This sounds pretty much exactly like what Richard is proposing. I think it’s a good idea because it disappears when you start typing and doesn’t cause stray instructions to end up in topics. We could also then remove the watched word.
Agreed. Will keep this in mind for future changes we might like to make.
I think it depends on the use case. It works well for a short template like the one that was used in support, but I think for longer templates like in Marketplace it wouldn’t be that helpful if the template disappeared once you enter the first character. For me, the text in the body in marketplace topics is a good compromise between a placeholder that disappears when you start typing and a template with fixed fields like the form-templates offer.
Though I wonder if telling users to search every time they create a topic makes a difference. Do people really read that every time they create a topic?
Telling users to search is something I’d more likely tell them the first times they are posting. For example, in the jit composer message shown on the first few topics you create. “Please search” is kind of like “please chose a meaningful title”.
Yeah, in this case for the support category I am happy trying for a period to have no nudge at all. If we see an uptick in people obviously asking questions before searching, we can look to solutions then.
at the upper right to search.
