From our analysis of help panel usage, we see that not everyone who begins to ask a question ends up submitting their question, and we also think that we could encourage more people to ask questions. Below are specific numbers showing how many people enter question text, how many click "Continue" to the review step, and then how many submit.
In particular, we see that 25 of 33 Czech users submit their question after reviewing, and 21 of 26 Vietnamese users submit their question after reviewing.
We hypothesize that we can increase the number of users starting questions and submitting questions by giving better context to the users about what will happen when they ask a question, who will see it, and when/how they can expect a response. Some specific ideas include:
- Making it easy for users to see what goes on in their wiki's help desk, so they get a better sense of what kind of question to ask and where it will go. Research on the English Wikipedia Teahouse suggests that the ability to view the Teahouse is valuable for newcomers and their confidence. They may even find the answer to their question without asking. It could be good to consider how to enable this without causing the newcomer to leave the context of asking a question. Perhaps we could show them some recent questions, as opposed to the whole help desk.
- Making it clear how much time it will take to get a response. Right now, all help panels say a response will come in a "day or so". But in practice, we can know a more specific time. For instance, in Czech Wikipedia, the median time is 13 minutes (although that depends on the time of day and time of week).
- Providing more informative placeholder text in the question box. Right now, the placeholder text reads, "I need some help with editing. How can I..." This seems to have caused many users to ask really short questions, just completing the placeholder sentence by "add a photo".
- Rethinking the steps in the question workflow. Right now, users can type right into a box in the help panel, then click to review, then click to submit. Perhaps that's not the optimal flow.
Note: if this task spurs multiple feature changes, those should become subtasks.