Question: I read [this](https://stackoverflow.com/questions/42041948/making-boxes-around-circles-with-numbers) question and flagged it as *too broad* along with some constructive comments. 

The question was how to make an user draw shapes in a window and then calculate how many circles were enclosed, with some restrictions. I commented what was wrong with the question and gave some guidelines on how the questioner could solve the problem. He/she commented back and said that the guidelines I provided was the answer he/she was looking for.

**Is it on topic to ask for *guidelines* to solve a bigger problem?**

Some acceptable answers contains no actual code but instead general guidelines or pseudo-code, so it seems to be acceptable in certain cases. But in many cases I would believe that these questions are too broad since there are many possible ways to answer them, but I cannot find anything in [what can I ask?](https://stackoverflow.com/help/on-topic) and [what should I avoid?](https://stackoverflow.com/help/dont-ask) about these types of questions. 

And still, too broad is defined as *"There are either too many possible answers, or good answers would be too long for this format"*. An answer with a couple of bullet points don't need to be too long and thus not too broad. Could it be that these questions aren't specific enough?

I understand that asking about specific algorithms is on-topic but is asking *"What are the procedures to implement a help pop-up window?"* a valid question? In other words; questions that are about bigger concepts than just one algorithm.

Answer: 
> 
> Is it on topic to ask for guidelines to solve a bigger problem?
> 
> 
> 

Yes, *as long as* the asker frames their question with enough detail on what they are trying to do so that the question doesn't:

* *Unavoidably* require unreasonably long answers (be it due to needing too much code or explanations of too many things);
* Make speculative answers unavoidable (i.e. you have to guess what the asker is trying to do);
* Invite an endless list of suggestions in the answers.

> 
> I would believe that these questions are too broad since there are many possible ways to answer them
> 
> 
> 

["Many" isn't necessarily "*too* many"](https://meta.stackoverflow.com/a/261370/2751851). In particular, there being more than one way to explain something doesn't make a question about it too broad.

> 
> I understand that asking about specific algorithms is on-topic but is asking *"What are the procedures to implement a help pop-up window?"* a valid question? In other words; questions that are about bigger concepts than just one algorithm.
> 
> 
> 

A vague *"What are the procedures to implement a help pop-up window?"* question is indeed too broad, but not because it is "about bigger concepts". From the point of view of the asker, it isn't about any specific concepts; in such cases, the asker typically just wants to achieve something and have no idea how to do so. That forces the answerer to cover way too much ground in order to cover the (real, or presumed) gaps in the asker's knowledge -- *ergo*, too broad.

> 
> I read [this](https://stackoverflow.com/questions/42041948/making-boxes-around-circles-with-numbers) question and flagged it as too broad along with some constructive comments.
> 
> 
> 

You did correctly. The original revision of the question is too broad, as to answer it you would have to either write the whole thing for the asker or to guide them by the hand, step by step, from the very beginning. The current revision isn't stellar either, as the added code doesn't seem quite minimal, and isn't explicitly connected to what is written in the paragraph above it, but it probably could be worked into something acceptable.
Asking how to *go about* doing something is definitely on-topic, and many times such questions and their answers are more useful than questions just asking for code. Such requests *can* still be too broad if there are too many possible answers or good answers would be too long for the format. 

Who knows, such questions may even eventually be able to be solved very simply using a new built-in method, library, etc.