Introduce Properties for Options


#1

Property may not be the best term but I need something. Think of shopping online for a shoe. You’ll want a shoe with the correct size, it should be intended for running, and the sole should be made of fiber glass.

A property is a detail about the option which is genarally applicable. This can be a pro or a neutral state of the option. For example “What is the best messaging app for iOS?” Someone may have interest in answers for Android, many of the options could also be applicable their; this makes iOS a property.

Similarly, one might consider the ability to “Integrates with your GMail contacts” as a vital pro for their app and want to ask, “What is the best messinging app for Android which integrates with GMail contacts?”

It is important to note that properties don’t remove the need to ask a question with these new restrictions, but if the question is derived from a question then contributers will have the option to pull in existing answers.


Comparisons should support tables, barely usable now
#2

I have spent longer than I care to admit thinking about this very problem, and you hit it right on the head and so did @johnlbevan in another thread.

Out of all the potential solutions (properties + filtering, NLP, properties + tables) the only one that really works for me without making me want to tear my hair out is make generating new questions from existing content really really easy.

In your above example, we could have “Best messaging app?” and the two tighter-scoped questions of “Best messaging app for android?” & “Best messaging app for android?”

With the property feature, we could just have the looser scoped question with the ability to filter options to meet your criteria. Unfortunately, this leads into a lot of complications for both the contributing model (what we ask people to do), the required UI and the data sources we would need to reliably use.

Properties are essentially ways to scope the solution space to only show things you’re interested in. When we were initially trying to figure out how to model Slant, we realised there was another tool to scope the solution space: the question.

When I’m shopping for laptops, I might be looking for “the best laptop for programming under $1,500”. This question has the property of price in the title, so it effectively pre-scopes the solution space.

This is what I want to build (and something @johnlbevan wants too). When someone adds “Whatsapp” as a potential option for a question, we’re going to create a separate object for that product in our db and keep track of the pros/cons added to it.

If you then want to ask the tighter scoped question of “Best messaging app for iphone” and begin to type “wh…” we could suggest “Whatsapp” from our database, thus correlating the data. You would then see “suggested pros/cons” for easy content generation of the new question.

Eventually we could get really clever with this. Instead of browsing via questions, you could browse via products. A product page on Slant would have all the questions it’s mentioned in, the most common pros/cons etc. We could even pull in wikipedia data for that option. We could even get really sexy and use external data sources like https://www.semantics3.com/ to pull off the properties/filtering feature without requiring users to type it in.

But the first step IMO is to allow users to ask a more tightly scoped question from existing Slant data, which is exactly what you and @johnlbevan suggested. This would allow us to have 5 different questions for “Best shoe in size 10”, “Best shoe in size 11” etc while not forcing users to repeat information that’s consistent throughout the questions (a type of shoe that comes in lots of sizes).


Reusable Answers / Reference from Multiple Questions
#3

I just want to note, that I think it should also go in reverse. A tighly scoped question could be expanded to general scope when the second tight scope question is asked. This leads into more “management after the fact” and UI, but I think that is a desired direction, eventually.


#4

Definitely - if we have multiple narrowly scoped questions, users shouldn’t have to investigate them all individually to get answers to their more broadly scoped questions. To do this, we’ll need to consider how we could effectively merge multiple instances of the same option (and their reasons) from different questions.


#5

I’m only here because I came across this tidbit here. If you ever do implement something like this, I encourage checking out our product, Datafiniti, as well. It has a pretty extensive feature set for what you can search on and the data you can get back - very helpful for doing automated supplementing of product data.