Sometimes on my own questions and other people's questions, I see users posting very useless comments that just show they only read the title of the question, and blazed through the specifics explained below. I have even seen answers that are like this, and it is extremely annoying, because they basically restate the OP's assumptions as their answer, then the OP has to refer them to the full text of the question and ask the question again. I understand that part of the rules are to read the question fully and understand it before you can answer, but how can we encourage users to actually do this?

$\begingroup$Are you thinking of a certain post in particular? Does the post have more than one subquestion?$\endgroup$
– Qmechanic♦Jun 19 '16 at 17:41

1

$\begingroup$@Qmechanic not in the sense of multiple questions, more like details they overlook. For example if I state clearly in my text that I am ignoring the effects of friction, but then someone comments/answers saying something negative involving the effects of friction$\endgroup$
– M BarbosaJun 19 '16 at 18:01

$\begingroup$@MBarbosa Do you have a specific example in particular? A lot of the time, especially in relativity and "popsci" particle physics, I can identify "oh, this user has X misconception" within the first few lines. Then I just skim the rest. Many people do this, and it works at least 90% of the time, but I admit it's not perfect.$\endgroup$
– knzhouJun 20 '16 at 0:37

2

$\begingroup$@MBarbosa Also, sometimes we have to override some of the stuff in the OP. For example, if you said "ignoring friction, why does terminal velocity exist", then you would correctly get comments saying "you can't ignore friction." That's not a failure of reading comprehension. Cases like this are why I'd like to see concrete examples.$\endgroup$
– knzhouJun 20 '16 at 0:41

2 Answers
2

This is a technical writing problem, and it is your problem as the author.

Start with a good, representative title. If your title reads like a different or simpler question than you intend then you have communicated something other than what you intended.

If you can't state the question in the title there is a good chance you are trying to cram too much into a single question. Remember the model is one-question-multiple-answers, not several-questions-many-answers.

Make sure the question is suitable for the site. Many beginners want to hear opinions on the ontology of various branches of physics and think a question of this sort would automatically be good for the site without realizing that regulars have seen them many, many times and often consider them to be unproductive philosophy suitable mostly for post-tenure noodling.

Use the right vocabulary. If the problem has a usual name or formulation, use it. This implies that you need to have done a bit research, but that is OK, because if your question is really simple you may find the answer on your own before you post.

More broadly, choosing your words carefully is a part of good technical writing. The ideas we want to express are often pretty complicated and it does not help to introduce extra ambiguity by using an not-quite-right word. Similarly, awkward and unnecessarily-long sentences add to the reader's mental burden.

Be aware that the formulation used in pop-sci treatments is often different from that used by professionals in important ways. Professional quantum physicists rarely perform "the double slit experiment" as such but often perform "diffractive scattering" experiments (a more general category that works on the same physical principles).

Consider including an abstract paragraph. Tell them what you're going to ask them as early as possible.

Don't bog the reader down with a lot of detail without letting them know where the effort of reading and understanding all that stuff is going to take them

Make good use of the formatting tools available. Note in particular that "good" does not mean "copious". If everything is emphasized, then nothing is emphasized.

Don't overlook that the tools on Stack Exchange sites include headings, lists, horizontal rules, and images in addition to changing the typeface.

Finally, I"ll note that good technical writing is not easy and is a learned skill. The effort you put into doing a good job writing posts and comments on technical Stack Exchange sites will be rewarded not only here, but on the job if you are in (or go into) a technical field of work (because communication is a big part of every job in all such fields).

$\begingroup$Thanks for the tips! I agree that sometimes it can be miscommunication. But for example, if I state in my answer that I am ignoring the effects of friction and someone answers using friction then it seems like they were just too lazy to read.$\endgroup$
– M BarbosaJun 19 '16 at 18:03

2

$\begingroup$Here's the thing: I let my better half proofread all my documents because things that I think are "clearly stated" are sometimes not at all clear to someone not approaching the text with my own mindset. It's easy to feel that a direction to ignore friction is a formality and not question when and where in your post to to put it while your reader has a different mindset. That mostly relates to things more complicated than "ignoring friction", but the way you get people to read those short and simple phrase is by making it easy and rewarding for them to read your post in the first place.$\endgroup$
– dmckee♦Jun 19 '16 at 19:22

1

$\begingroup$I like your use of the bold subtitles. I could skim this answer by just reading those, and get a good feeling for the direction of your thinking on the topic. Part of clear technical writing is indeed to make sure that people can skim without fear of losing the most important information.$\endgroup$
– FlorisJun 23 '16 at 15:20

1

$\begingroup$This is a great way to express the same thing I said recentlyl on meta stackoverflow. Putting the real question as early as possible in a TL;DR section is huge. I also like bullet lists for the key points, since the eye tracks down a list more easily than a paragraph of English.$\endgroup$
– Peter CordesJun 30 '16 at 19:51

I agree with knzhou that it is more profitable to discuss concrete (linked) examples. As scientists we like to see the evidence and judge for ourselves rather than adopt somebody else's opinion on an issue.

Your question seems to imply that the fault is with those who post comments or answers. Whether or not that is true, I agree with dmckee that if question-setters want better answers, it is their responsibility to ask better questions.

DanielSank reminds us that detailed advice about how to ask (and how to answer) already exists. I think the reasons it is overlooked or ignored are that (i) it is not prominent, so users don't know it exists or where to find it, and (ii) it is far too long.

This leads me to suggest that question-setters be advised to :

make the crucial question prominent and clear, preferably summarised in the title, and

include just enough context to make the difficulty understandable and well defined, but not so much that it obscures the crucial question or that reading it becomes a chore.

$\begingroup$I agree! I think a nice pop-up "toast" encouraging the asker to develop the question fully, and then another one for answerers to make sure they fully read/understand the question before answering. I also think most people will not ask clarifying questions because in the guidelines it explicitly says to "avoid asking other questions" in your answer/comment. I think that means don't ask another technical question on top of the one you're answering, not "don't ask anything at all".$\endgroup$
– M BarbosaJun 22 '16 at 20:48