Imagine you want a PDA phone WITHOUT a physical keyboard. Or a monitor WITHOUT speakers.
There is no way to specify that in the gdgt finder.
And that's because of the model of entering, storing and displaying boolean specs: a value of "no" (the checkbox for "Speakers" in the monitor's specs is not checked) means the same as "Don't care" (whether it has speakers or not) or "Don't know".
I don't know if the gdgt has true/false and also NULL in their specs column, but while adding gadgets is disabled, it would be wise to smarten up the display:
For entering boolean specs: Yes / No / Don't know (don't just show a checkbox - how do I indicate if the monitor has no HDCP support? Do I leave "HDCP" unchecked? How will you distinguish that from "I have no idea?")
For searching: Must have / Must not have / Don't care. This model is also used by Gsmarena.com (www.gsmarena.com/search.php3) and Phonearena.com (http://www.phonearena.com/htmls/phone_filter_advanced.php).
Please, really have the best gadget finder by specs on the web.
The model for storing specs is probably WRONG. Is it too late to change it?
This post has been removed.
It's a very good point which, as the general architect of the system, I've spent an enormous amount of time considering. There are two aspects that informed my decisions surrounding what you're discussing.
First is how our product spec schemas vary from category to category. Namely, what may be boolean for one type of product may not be for another, depending on the context in which an option is presented (i.e. USB ports on a computer, USB ports on a keyboard, and USB ports on a USB hub). As for storage of values, yes, it's safe to say that null values (i.e. the lack of defined data) are not stored as 0/no/none values (i.e. defined data), so that could lead to the occasional issue.
The reason I think that will be rare, though, is because the second point, which regards balancing usability of the specs input interface with the actual granularity of data. It's my feeling that in most cases, the vast majority of users will be looking for products based on what they want, not on what they don't want. In your example, it's hard to imagine a user trying to find a device that does NOT include HDCP support, so if it is unchecked in the finder, the implication is both "don't know" and "don't care" at once.
As such, in large part options of lesser importance tend to have less definition, whereas the most important spec inputs -- namely, something where you would actually expect to be able to define 0/no/none -- should have some kind of boolean value available (or a value set which includes 0, no, or none).
Does that help any?
First is how our product spec schemas vary from category to category. Namely, what may be boolean for one type of product may not be for another, depending on the context in which an option is presented (i.e. USB ports on a computer, USB ports on a keyboard, and USB ports on a USB hub). As for storage of values, yes, it's safe to say that null values (i.e. the lack of defined data) are not stored as 0/no/none values (i.e. defined data), so that could lead to the occasional issue.
The reason I think that will be rare, though, is because the second point, which regards balancing usability of the specs input interface with the actual granularity of data. It's my feeling that in most cases, the vast majority of users will be looking for products based on what they want, not on what they don't want. In your example, it's hard to imagine a user trying to find a device that does NOT include HDCP support, so if it is unchecked in the finder, the implication is both "don't know" and "don't care" at once.
As such, in large part options of lesser importance tend to have less definition, whereas the most important spec inputs -- namely, something where you would actually expect to be able to define 0/no/none -- should have some kind of boolean value available (or a value set which includes 0, no, or none).
Does that help any?
Just noticed another place where a clear yes/no/unknown separation would be helpful: alternate configurations.
Take the Samsung Galaxy. Its gdgt.com/samsung/galaxy/specs/ mentions UMTS 900/2100. But for German, only 2100 is supported (see https://service.o2online.de/portal/?$part=Productc...), so I went ahead and created an alternate configuration. The instructions on that page said that "Alternate configurations should not have all specs defined, only what differs from the base model". Now how do I specify that UMTS 900 is *not* supported?
One idea for adding "unknown" for boolean choices would be to have 3 states for checkboxes: clear, checked, and grayed out (this can still be grayed out checked and grayed out clear - with potential for confusion). Another idea would be a tad clearer, but would take up more UI real estate: 3 radio buttons.
Take the Samsung Galaxy. Its gdgt.com/samsung/galaxy/specs/ mentions UMTS 900/2100. But for German, only 2100 is supported (see https://service.o2online.de/portal/?$part=Productc...), so I went ahead and created an alternate configuration. The instructions on that page said that "Alternate configurations should not have all specs defined, only what differs from the base model". Now how do I specify that UMTS 900 is *not* supported?
One idea for adding "unknown" for boolean choices would be to have 3 states for checkboxes: clear, checked, and grayed out (this can still be grayed out checked and grayed out clear - with potential for confusion). Another idea would be a tad clearer, but would take up more UI real estate: 3 radio buttons.
Replying to my post above since more than 5 minutes passed after posting it.
For boolean specs, probably a drop-down of "unknown/yes/no" would be clearest and most concise.
When editing specs, by default, all boolean values would be "unknown", and the user could set them to Yes or No.
When adding alternate configurations, all boolean values would initially be "no change" or "same", and the user could override the different specs only with "Yes" or "No".
When searching for gadgets, the drop-down would be "Don't care" (default), "Yes" and "No".
For boolean specs, probably a drop-down of "unknown/yes/no" would be clearest and most concise.
When editing specs, by default, all boolean values would be "unknown", and the user could set them to Yes or No.
When adding alternate configurations, all boolean values would initially be "no change" or "same", and the user could override the different specs only with "Yes" or "No".
When searching for gadgets, the drop-down would be "Don't care" (default), "Yes" and "No".
