Hacker News Reader

Comment by chefandy | Hacker News Reader

While the overall point holds true, some of the complaints don't make sense. Searching "rice" for example will probably get you parboiled white rice, instant red beans and rice, chicken and rice canned soup, and rice pudding— many of those facets make prefect sense. If you were searching for rice paper for crafting, or even "nuts," that "food" facet would be plenty useful.

You can't look at one narrow usage path to judge an interface. You can only customize the interface so much for specific use cases before it becomes confusing as hell to use because it lacks consistency between tasks.

View on HN

The complaint about "rice" is that the tagging is incomplete. "vegan" isn't a bad facet, but the count is wrong. When you select "vegan", most vegan products are removed. I don't see how filtering wrong data isn't a valid complaint.

The problem is obviously that the data isn't tagged. But Costco is huge, profitable and doesn't have a huge inventory, so why can't they tag it? And if the tags are so incomplete, maybe it's better not to include them?

Tagging products sounds like something a LLM could do rather well with just a little human supervision.

Have worked on this and it’s between 60 and 90% OK in my experiments. You run into lots of fun issues because people don’t write titles and descriptions for machines, they write them to appeal to human emotions to close a sale.

> Searching "rice" for example will probably get you parboiled white rice, instant red beans and rice, chicken and rice canned soup, and rice pudding— many of those facets make perfect sense.

Well, no, if I ask for rice, the odds are overwhelming that I'm looking for rice, in which case chicken and rice canned soup is a totally inappropriate response. It would make as much sense as returning alcohol-free wine when asked for "alcohol".

But chicken and rice canned soup contains rice and the word is part of its logical title.

You should be able to unearth the soup with a partial match. What makes the alcohol/alcohol-free problem is that alcohol free is one token that can't be subdivided.

That is not a consistent position. If "alcohol free beer" doesn't contain the word "alcohol", then "chicken and rice soup" doesn't contain the word "rice".

Moving the argument into the realm of things that matter, chicken and rice soup is not a product that can be called "rice", and therefore isn't an appropriate response to a search for "rice". The title is irrelevant; if you're stocking rice with a fancy name and its title doesn't include the word "rice", that product still should show up in a search for "rice".

I don't get this position, chicken and rice soup is not the most relevant result for the query rice but it is a match. It should show up in the results somewhere. If I page through all the results of rice I expect to get all the results that conceivably match the query.

Yes: chicken and rice, rice cakes, rice paper, cauliflower rice, rice cooker, rice krispies, rice university jersey, mochi, risotto.

No: licorice, ricetta tiramisu.

> I don't get this position, chicken and rice soup is not the most relevant result for the query rice but it is a match.

As I said, that is inconsistent with your simultaneous position that alcohol-free wine is not a match for "alcohol". Either they both are matches to their respective queries or they both aren't; there isn't a difference between the two examples. This is true from the perspective of dumb text searches, but it's equally true from the perspective of correct linguistic parsing.

That rice is part of the listed title for chicken and rice soup is a coincidence; the argument for returning it also tells you that you should return the same soup when asked for "tomatoes", if tomatoes are an ingredient in the soup.

Your "yes" and "no" examples don't seem to work. What rule excludes "licorice" that would include anything containing the raw textual string "rice" without regard to whether any rice is involved? Rice paper, rice cooker, cauliflower rice are all purely textual matches. Mochi is a purely semantic match!

You’re describing the problem from a computer scientist POV. OP is describing the problem from a user’s POV. Nobody cares if there’s a subset of their query in the title. That item is not “rice”. No one is searching for “rice” and wants soup. They would search for “soup” then. Tokens aren’t all of equal value in a title, and this is a big part of why ecom search is horribly bad (I have spent years working on ecom search and partnering with vendors trying to improve it. It’s a hard problem.)

What if I want a rice-based ready meal, but don't know exactly what kind of meal yet (I'll know when I see it), so I'd like to search rice and see what's on offer?

Oh! Chicken and rice soup, I could go for that. Cart.

> What makes the alcohol/alcohol-free problem is that alcohol free is one token that can't be subdivided.

It's not even a problem... it's an unfounded assumption that alcohol-free wine wouldn't ever be relevant to the user at all. If the only place open on a holiday was Walmart that I didn't realize didn't sell booze, and I needed some kind of booze to make a pan sauce or a braise, I wouldn't necessarily think to search for non-alcoholic booze-- but it would be a very useful substitution for me, and not by accident... they're two versions of the same product. I'd much rather see that they had non-alcoholic beer and wine in my search than completely empty search results.

This is why competent companies hire designers to work on interactions like this rather than leaving it up to the implementing developer's gut instinct about user needs. If only the tagging could keep up.

Assuming these sorts of things about your users' intent causes big usability problems. Trying to predict how users will use search usually ends up more frustrating than not for many people. Most people who use these tools don't have a working mental model of how search engines work, so they can't troubleshoot easily if your expectations and theirs don't line up. This is exactly the sort of "smart" feature that developers crow about all the time. Unless you have some way of predicting how individual people will use search boxes then you're much better off with something more general.

Reply on news.ycombinator.com