This is the question edition of What is required for an answer to be high quality?

One of the key problems that I see Software Recommendations having, is people asking extremely vague and simple questions that ultimately boil down to one of the two close reasons we see on the rest of the network:

  • too broad
  • unclear what you're asking

To aid the future of this site and to clearly define what we classify as a high quality question containing enough information to actually provide suggestions that will be useful to the asker, I feel that we need to discuss exactly what "enough information" is.

Note: since it's possible to customise close reasons, my intention is that this post is referenced in a (as of yet to be defined) close reason that states something along the lines of "Not enough information has been provided for this software recommendation to be answerable or meet our quality guidelines, please see <this post> for information on how you can improve your post" (or something to that effect).

I feel that high quality software recommendation requests (questions) should follow guidelines on both formatting/presentation and content.

Content

The content provided in the question needs to clearly identify the use case for the software. What are you going to do with it? What is it for? How are you going to use it? These are all important questions and I feel that these should be required for a question to be on topic here, to reduce ambiguity and ensure that this doesn't just devolve into a guessing game.

Are there any other key things that you feel questions should include in order to meet a minimum quality level and fulfil the requirement of "containing enough information to be answerable" in addition to the below? (Answers in the answer section below)

What kind of application are you looking for?

This is pretty fundamental, without it, there isn't a question to begin with. What kind of application are you looking for, what is the purpose of this application? Are you trying to create an image file? Edit audio? Looking for an IDE for <some language>? This should ideally include an outline for the intended use case. The more you tell us about the kind of application you want and how you're going to use it, the higher quality the answers you're going to receive will be.

If you're looking for a replacement application for something you're already using, it would be helpful to tell us what application you're currently using and what it already does/doesn't do - and most importantly, how you would like our recommendations to differentiate themselves from what you're already using. Not including this information could result in us spending time recommending something you've already tried, or with features you specifically don't want.

What operating system do you want the application to run on?

In a world dominated by Windows, we could make an assumption, but that assumption wouldn't always be popular. I feel that in the event the asker is after a desktop application, the operating system(s) the application is intended to run on should be clearly stated. If they're after a web application, this should also be clearly stated.

What budget do you have?

Would you agree to pay money for the software, and if yes up to how much? Are advertisements or usage fees OK?

What features must the application have?

This starts to get down into where our area of expertise will be. It's easy enough to type "replacement of notepad" into Google and get some answers, but I feel that we are here to recommend software based on a set of features, in addition to an intended purpose. These should be listed in order of importance from "must have" down to "these are optional but would be nice". Tell us what the software has to be capable of doing and we will recommend software that does it.

Formatting

How a software recommendation request is presented is just as important as the content it contains. Each request should be formatted in a way that makes it clear what the requirements are, makes the post easy to read, etc. Formatting is important.

Titles should be clear, concise, and avoid being subjective

"What is the best product for <this thing I want to do>?" - we should actively avoid this kind of title. Best differs from person to person and provokes discussion in the answers and comments below - something we need to avoid to maintain quality levels. Instead of "best", try using "good", or, don't qualify for the product in this way at all.

Feature requirements should be listed in order of importance

Every question should contain a list of features in order to keep the scope of the question from becoming too broad. These should be listed in order of importance from "must have" down to "these are optional but would be nice". Using Tim Post's examples:

  1. Must run on OS/2, with 128 MB of RAM
  2. Must not be pink
  3. Ideally takes less than 2MB of disk
  4. Big plus if it plays music

Listing in order of importance allows us to quickly see what the asker views as the "killer features" and allows us to tailor our answers to meet these requirements a lot easier than if the requirements appeared in the post in any other way.


Some further reading:

share
3  
We've been using Tim Post's guidelines. The important thing you missed out is that in addition to requirements, a question needs a task, a user story. –  Gilles Feb 9 at 20:19
    
Indeed, and that's a good post, I'm just thinking that since this will be such an important issue going forward that we collate our requirements in one well defined post that's easy to find and suitable for linking from a close reason. –  Flyk Feb 10 at 8:45
    
The next step is a similar thread about answers. I offer meta.softwarerecs.stackexchange.com/questions/86/… as a starting point. –  Gilles Feb 10 at 11:07
    
I agree - I think we should deal with question quality and answer quality as two distinct subjects. We should probably break it out into a post specifically about answers though (clearly labelled as "What is required for an answer to be high quality?" so we have a matching pair of clearly titled reference questions) –  Flyk Feb 10 at 11:10
    
I have posted the question What is required for an answer to be high quality? as the answer equivalent of this post. –  Flyk Feb 10 at 11:35
    
this is way too many extraneous hoops to jump through esp for a beta site with low activity, & the focus of the young/small group should be on quality answers instead of question contents... ie avoid the common trap of many other se sites, micromanagement –  vzn Feb 22 at 4:22
4  
@vzn Quality standards should be set in beta and enforced too, or do you want to go closing and improving thousands of questions when the site graduates, if it does? Beta is the time to prove that the site can be of use and produce quality content. –  3ventic Feb 22 at 11:42
    
@vzn nononono, didn't you read the ground rules? We are trying to make this site works right (tm) and traffic? we will get lots of traffic. We already are over the 320 visits/day and only 3 days in public beta. Once we start to appear in the Google index we will get lot more... –  Braiam Feb 22 at 12:38
    
early indications may be healthy but do not guarantee longterm viability/ engagement ... there are many se beta sites that do not grow substantially and to assert reflexively that this one will is arguably naive... the fixation on so-called "question quality" incl by mods is not supported by official se policy. its the answers that are the main measure of so-called quality & many se mechanisms/policy point to that –  vzn Feb 22 at 16:10
    
@vzn You mistake ... beta is exactly the right time to work out what a quality question looks like and set that as a pattern before volume hits us. Please stop trying to excuse half baked questions. –  Caleb Feb 22 at 17:03
    
"half baked" ≠ casual/informal/brief... do questioners serve answerers or vice versa? cart before the horse.... but, its a common groupthinking attitude on se.... not surprising! a misconception regrettable in its ubiquity across se! widespread, systemic issue! good luck! –  vzn Feb 22 at 19:39

1 Answer 1

A software recommendation question has two essential components: a goal to accomplish, and a set of requirements. The goal establishes the setting and explains in broad terms what you want to do with that software. The requirements put specific constraints that the software must verify.

Think of your task as a picture puzzle. The goal is an overall description of what the picture represents, in brush strokes. The requirements define the exact shape of the missing piece that you're asking about.

Define your goal

Describe the task that you want to accomplish. Explain your goal, putting it in context. Part of a good recommendation is to work out the best tool for the job — so tell us what the job is.

This part can include a user story: “As a <role>, I want <goal>” or “I am a… I want to…” or “As <who> <when> <where>, I <what> because <why>”. Then explain the role of the software your're asking about in this task.

Don't use words like “best” or “good”. We aren't going to recommend bad software. Explain what the software has to be good at. It's not about what's best in the absolute, but what's best for a specific task or purpose.

If you're looking for alternatives to software that you're already using, don't describe your goal as “alternative to X”. There is often no exact equivalent to X, so tell us what you use X for. See How to ask for an alternative to some software for more tips.

Define your requirements

There are a number of must-haves — a number of features that are required for the task. Tell us what must absolutely be there, so as to avoid answers that will be useless for you. These requirements need to be absolute and objective: either it's there or it isn't there.

Almost all questions need a platform requirement: are you going to run this software on a PC or a smartphone? Under which operating system? Is a webapp ok or does it have to work offline?

After the must-haves come the nice-to-haves. What features would you ideally like to see? These can be rated: requirement #4 is strongly prefered, requirement #5 would be a nice plus. These can be gradual in a the-more-the-better way (or the-less-the-better), but beware of adjectives which lack a frame of reference such as “lightweight” or “low-cost”.

Show what you know

Did you search for suitable software? What did you find?

If you find a single program that seems to match, that's probably the obvious solution. Also look at software that's bundled with your operating system. Try it out! Sometimes the obvious solution is the best one. If you're unsatisfied with what you found, say why: “I tried X and it didn't meet <requirement #5>”.

If you found a lot of seemingly-matching programs, it's a sign that your requirements may be too broad — try to refine them. If you found nothing, we're here to help (but then consider relaxing your requirements if they indeed cannot all be met).

Write a to-the-point title

The title should summarize your goal in a few words and mention the most important requirements.

See How do I write a good title? for tips on writing good titles.

Tag your question

At least one tag should correspond to the category of software you're looking for or the category of task that you want to perform, something like or . Look at other existing tags. Be sure to check their description (tag wiki) to make sure you understand what the tag is for.

If you're looking for software to run on a specific platform, use the corresponding tag, e.g. or .

Yes, I've read these guidelines

If you have a question that meets this guidelines, welcome! Follow this link to ask your question.

share
    
This is a first stab at a community FAQ for “how do I write a good question”; it is inspired by Tim Post's guidelines and our experience these first few days as well as experience on other SE sites. It sorely lacks examples — I'm out of time right now, please add some (without overdoing it). –  Gilles Feb 10 at 11:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .