Add Default Text in Support form as a Template for Asking Good Support Questions

[webdevmattcrom]

In a similar vein to #363, it would be useful to allow plugin/theme authors to provide a support template for users to submit their support requests based on pre-given questions.

Github implemented it this way:
​https://github.com/blog/2111-issue-and-pull-request-templates

Potentially, a plugin author could include a file in their repo called .support to pre-populate the New Ticket field. It's unclear to me the complexity of this request but it would certainly make the back and forth of support tickets in the Support Forum in general much more efficient if well-implemented.

[SergeyBiryukov]

#3254 was marked as a duplicate.

[brothman01]

Recently Evan Herman and I were at a contributors day answering support questions on the forum and we were talking about how annoying some questions were because they are unclear and force the responder to both guess what the question is asking and come up with the answer. We came up with a very simple solution:
There should be a template for a the first post of every thread:

[Question in one or two sentences]
[Other relevant details]
[link to site]
[What you tried]
[What result you want]

This template would just be default text that shows in the question box so that the user can choose to stick to the template or delete it ask a custom question if they prefer. This would allow questions on the forums to be asked and answered a lot more efficiently.

There could be a file to include like Matt said or just have a template that goes to every question. I like Matt's idea more because it allows the plugin author to customize their forum a little more, but either solution is an improvement over the current situation where we do not have any template.

[webdevmattcrom]

Thanks @brothman01 for your input. I agree that a standard template would be preferrable to the current situation if that is an easier implementation than the per plugin/theme option.

[brothman01]

@webdevmattcrom's idea is better, if you can do a .support file for each plugin or theme that would be ideal. I meant my idea of a standard apply-to-all template for non-plugin support forums and then the .support file for plugin/theme authors.

I bet if more forum supporters knew about this ticket they would have input and we could democratize this issue a little more...

[maartenbelmans]

+1 for this!

[pothi]

+1. Would save tons of precise hours!

[OptimizingMatters]

Would love to see this, the quality of support requests is a huge problem and a support template could help improve things substantially.

[ben.meredith@…]

This is a "help users learn how to get better support" type of issue.

The more educated the user is on how the WP ecosystem works, the better their support tickets will be. Unless there's a technological blocker here, I see nothing but upside to being able to help users ask for help in a better way.

Often I'll get support requests that assume, for example, that I automatically know from their username where they have installed my plugin.

The more rails we can give them to run on, the better.

[cliffpaulick]

This would definitely be helpful but any template shouldn't duplicate what's already asked of the user. Currently, besides Title, it's:

• Link to the page you need help with
• Select the version of WordPress you are using

[nickciske]

+1 Yes, please. So much time and effort is wasted just getting basic info from users needed to begin troubleshooting.

The Link to the page you need help with is a good start, but at any sort of scale, support quickly becomes a challenge on the forums.

[Collizo4sky]

+1

[xpeedstudio]

+1

[dd32]

Please avoid posting simply '+1', instead please use the 'Watch this ticket' star to indicate interest in the ticket

I think the first iteration of this should be focused on something generic for all plugins, adding a way to customise the prompt on a per-plugin basis could be implemented later.

Based on that, lets determine what would be most beneficial to all plugins, perhaps a list of common questions which you find yourself asking reporters of issues would be a good start.

[netweb]

Also, what is, what isn't, and what should be removed from the new topic FAQ's ?

• Forum: ​https://wordpress.org/support/forum/how-to-and-troubleshooting/#new-post
• Plugin Forum: ​https://wordpress.org/support/plugin/akismet#new-post
• Theme Forum: ​https://wordpress.org/support/theme/twentyseventeen#new-post

[phillcoxon]

+1 for this.

[brothman01]

@dd32
I agree that the template for all would be easier to implement to test this idea out, but the eventual goal should remain to have custom templates the plugin authors can upload. But for the generic and broad template I came up with these questions:

[Question in one or two sentences]

[Expected behavior vs. actual behavior]

[link to site/page demonstrating problem]

[What you tried]

[steps to reproduce (if possible)]

any others?

[amboutwe]

Would it be helpful to specifically ask for a full error message, if one occurred? Possibly in the first part.

[Question in one or two sentences, including error messages]

[Howdy_McGee]

I've thought about this before and when brought up previously the consensus was that they did not want to make the submission process more difficult than it needs to be. Adding additional fields would add onto the submission process. I think the middle ground would be placeholder text with examples and expected information. I've also seen plugin authors in the past sticky threads regarding submission guidelines/templates.

[webdevmattcrom]

@Howdy_McGee

the consensus was that they did not want to make the submission process more difficult than it needs to be. Adding additional fields would add onto the submission process.

-- The consequence of this line of thought is getting replies from the plugin authors asking for additional information that could have been provided in the users first response. That is much more troublesome than taking a little extra time.

I think the middle ground would be placeholder text with examples and expected information.

Placeholder text would be a good first step in the right direction, but what often happens is that users don't actually replace the placeholder text.

I've also seen plugin authors in the past sticky threads regarding submission guidelines/templates.

We do this -- it means zero, users never read pinned threads.

[brothman01]

@amboutwe yes, however sometimes there is no error message (such as when a plugin not showing the information it should, when there is a styling issue, etc) so we should modify '[Question in one or two sentences]' and change it to '[Question in one or two sentences + error message (if applicable)]'

@Howdy_McGee Adding more fields would make this more complicated, but like you said adding placeholder text is probably the right move so that adds no complication and is optional.

@webdevmattcrom You are right that some users may just leave the placeholder text, but we can assume that the majority, or even just a lot of people asking the questions will want good answers to their questions and so will replace the placeholder text. But you bring up a good point and so maybe we should add a disclaimer or something before the text field that says something like 'the more information you give by replacing placeholder text, the more likely someone will be able to give you a good and helpful answer.'?

So the template so far seems to be as follows (if anyone has ANYTHING to add or change I would love to add it):

Disclaimer: The more information you give by replacing placeholder text, the more likely someone will be able to give you a good and helpful answer. (before the input field)
[Question in one or two sentences + error message (if applicable)]
[Expected behavior vs. actual behavior]
[link to site/page demonstrating problem]
[What you tried]
[steps to reproduce (if possible)]

[bemdesign]

Just my 2 cents...While the theory of this sounds good, getting a good implementation seems particularly tricky and it may not actually resolve the main issue at hand, namely getting users to provide more meaningful and accurate information up front. I don't think placeholders will work out well as many users will just ignore them and aim for the big comment box to start dumping their tales of woe and anguish - frankly a lot of support is more about having another human "hear" and recognize their experience. Then there's the barriers if we have more "required" fields before posting. Ultimately the simpler the interface, the better for the users. So I'm torn on this. On one end it could help users start to recognize the importance and utility of providing facts about the issue, making for easier and more efficient support experiences. On the other end, we could end up driving users to seek alternative support channels and the forums (and other users) would be poorer for it.

[Clorith]

I'm also not sold on these templates, I've seen them on GitHub, and honestly... they're a wall of text "blocking" me from doing anything. I don't think I've ever followed them, I mark all, delete, and get to writing in a manner that's comfortable to me.

I view this as either scaring users off, or being treated like I treat them, like noise that has to be removed straight away. (I understand I'm not an average user here, and often know how to write a ticket, but I think my process here will be familiar to many if it's left as a template you can write into). And I am absolutely entirely against adding required fields, it's then no longer a forum but a ticketing system. (we've mentioned this a lot of late, because that is what this is after all).

I'm leaning towards wontfix here.

[Otto42]

Realistically, the idea of asking several questions for the user is less of a "give me better information" and more of a "don't bother asking for help" type of scenario. The more complex you make the form, the less people will use it. And while that might fit the developer's case of having less support requests just fine, it doesn't actually help more people.

The support forums are first-and-foremost "forums", not a bug tracker, and not a ticketing system. Users can leave comments on plugins and other users can comment on those. They don't need to give versions or answer complex questions in order to do that. Adding more complex templates might seem like a good idea for people trying to provide support, but it's not such a good idea to put a barrier to entry in the way of people who actually need support.

[webdevmattcrom]

Replying to Clorith:

I view this as either scaring users off, or being treated like I treat them, like noise that has to be removed straight away. (I understand I'm not an average user here, and often know how to write a ticket, but I think my process here will be familiar to many if it's left as a template you can write into). And I am absolutely entirely against adding required fields, it's then no longer a forum but a ticketing system. (we've mentioned this a lot of late, because that is what this is after all).

I disagree that it scares users off. Particularly because notifications of replies can easily get hidden, we risk not helping the user at all because they didn't provide enough information on their first post and they didn't see the follow-up reply come in. Providing actionable information ensures that users get the answers they need, instead of having a back and forth encounter over and over again.

Replying to Otto42:

Realistically, the idea of asking several questions for the user is less of a "give me better information" and more of a "don't bother asking for help" type of scenario. The more complex you make the form, the less people will use it

I'm not sure what you're basing that on, but in my experience -- where we use a lengthy intake form, users are very satisfied because they can get answers in 1-2 replies tops.

I'm also confused by the idea that "this is a forum, not a ticketing system". No one is asking for a full ticketing system, but Plugin Support is definitely not simply a Forum either. That's why plugin authors and contributors and plugin support have labels on their profiles, so users can know that they are getting answers from the source. That's also why we can marked issues as "Resolved" and not simply just "Closed".

Empowering plugin/theme authors to give better and more efficient support should be the goal here. The current status-quo is severly limiting in enabling us to best support WordPress users as a whole, and the users of our plugins/themes specifically.

[webdevmattcrom]

The best evidence is actually the benefits that have come from adding the website url field to the form. There was a lot of pushback to that simple idea. In the end, it's been incredibly effective. This idea is an extension of that first step in the right direction.

[webdevmattcrom]

Based on all previous conversation, my best recommendation is simple global placeholder text, with the following format:

1. Describe what happened that was unexpected or problematic.

2. Describe what you expect to happen instead.

3. Describe what steps you've already taken to fix the problem, if any.

That alone would make first support request posts immensely more productive. It would only be placeholder text, so the user could just ignore it completely, but at least they'd have a structure to follow that would ideally help guide how constructive their request is.

[Howdy_McGee]

Replying to webdevmattcrom:

Based on all previous conversation, my best recommendation is simple global placeholder text

I absolutely agree. Best case scenario the user reads the placeholder text and answers the provided questions supplying more information to the support topic possibly leading to a quicker turnaround. Worst case scenario the user ignores the placeholder text, clicks inside the box where the text automatically disappears ( by browser standards ) and they submit their request as normal, no harm no foul.

I don't see it anymore of a hindrance than the Search WordPress.org in the .org search bar.

[xkon]

Just my 2c since this is really interesting. When I see wp.org as a whole (at least as far as I'm concerned and on the pages that I've been hanging out :D) everything is consistent on each 'section'.

So even though I do understand the need of extra input fields etc to create a better user experience by [1]users providing more specific information -> [2]to authors being able to create less and more precise replies and solve the problem faster etc. This would bring somewhat of an inconsistency and might hit back in the wrong way. I can't even imagine myself being in the forums having 3 input fields, then going in a plugin having 5 and on another after having 15 because that's the custom template that Author decided to upload even if it's for the better.

Also on the last 2 comments about the the placeholder text mentioned, if I see more than 1 bullet point in there and I click to write and that list vanishes, I'm lost already... I won't even remember what 2. was after 3 minutes of trying to explain my problem as I'm focusing on my issue and not what the holder was telling me.

One idea of 'combining' both things ( if that's possible ) would be for the plugin authors to be able to alter (or extend even) the notice area that is right above the form.

If that's possible:

• There's no UI/UX difference between support forums + plugin forums.
• The user will always be able to see what the Authors want as a 'standard' reply to help faster.
• If the user wants he can still avoid everything and just proceed on mumbling on whatever he likes without interference.
• Everything is still on a consistent 'theme' of having the same form everywhere with 1 notice above. No frustration, no confusion whatsoever.

[webdevmattcrom]

Thanks @xhon for chiming in. Just a couple points of clarification:

1) The proposal isn't about adding new fields. It's about the placeholder text like Github does it.
2) "Placeholder" might be the wrong term actually in the end. It's actually "default text" that serves as a template. Meaning, it will NOT disappear when you click in there.

I like your notice area idea, but I don't see that as a replacement for the "default text template", but it might be worth creating a separate issue about that.

[kevinwhoffman]

And while that might fit the developer's case of having less support requests just fine, it doesn't actually help more people.

As someone who has been in the "fix it" role for both WordPress.org and premium support issues, I can say unequivocally that it is more difficult to help users on WordPress.org because of the lack of information provided. This isn't about developers wanting to scare users off or reduce the number of support requests; it's about having the information necessary to actually help the people that do need support.

Answering three simple questions that would improve any support request seems reasonable. The folks who know to provide that information already won't be bothered, and those who don't know how to request support will get the guidance they need.

[Howdy_McGee]

I've misunderstood then, default text is a bit different than placeholder text. It adds another step that the user needs to take in order to ask their question. I can't say I'm in support of this.

The default text/questions may not even pertain to their question which they'll then have to select all and remove before proceeding. What if this case out weights the cases where the default text is helpful? Wouldn't it be annoying if you had to delete default paragraphs in WordPress when creating a new page every single time?

Maybe if the new post section had it's own screen it could be customized a bit more but as it is now I don't think the forum overall would benefit from default text/questions.

[webdevmattcrom]

Replying to Howdy_McGee:

The default text/questions may not even pertain to their question which they'll then have to select all and remove before proceeding. What if this case out weights the cases where the default text is helpful? Wouldn't it be annoying if you had to delete default paragraphs in WordPress when creating a new page every single time?

Maybe if the new post section had it's own screen it could be customized a bit more but as it is now I don't think the forum overall would benefit from default text/questions.

I think this speaks to a fundamental divide between how some interact with .org "forums" in different part of the forums. In the more general forums, I can clearly understand how any default text could miss the mark in terms of guiding the user in how they ask their question.

But for those of us doing support for plugins and themes, generally speaking, every question needs to have some basic information in order to get productive replies. When that basic information is not there, additional time and friction in the discussion experience is spent just getting actionable information. In this way, the plugin and theme "forums" are not actually "forums" in the true sense of what a forum is. There isn't a lot of general chatter, or banter, or dissecting ideas or anything like that. It's plugin support, it's theme support, which is 9 times out of 10 between one user and one (or more) plugin author(s)/support technician(s).

So while you might not see the value for the general .org forums, the value is immense for plugin/theme support. It's harder and harder to justify spending time in these forums when the support experience is so limiting and restricting both for the user and the plugin/theme authors.

[bemdesign]

Does it make sense and is there enough value to have different forms for different support areas?

Meaning that the themes support forums would have a different form and associated fields then the plugins support forums and both of these would be different than the general WordPress support forums form and fields.

It's nice to be consistent but maybe we are being too consistent (constraining) with dissimilar user support tasks and contexts.

[mrfoxtalbot]

This ticket was discussed during ​this weeks Meta Ticket Scrub.

Because we now have blocks in the forums, this would need to be handled via Gutenberg. I have created an ​issue to explore the feasibility and scope of this.

[webdevmattcrom]

@mrfoxtalbot -- thanks for bringing this back up. I'm still a strong believer that some minimal effort could bring very positive results for the quality of first posts added in the support forum.

I see that the "blocks-everywhere" issue you raised has already been closed. The idea of replacing the default prompt in the block editor sounds interesting and could be helpful. I wonder though if pre-defined blocks within the editor would be even better or possible?

Something like this: