Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

Have u seen Mac OS X's search tokens?

The Finder includes tokens—a smart way to filter your searches. When you select a suggestion, a token is created. Instantly your search is filtered, and you see only the files that meet those criteria. You can change the scope of the token by clicking the arrow. If you want to narrow your search even more, you can use multiple tokens together. Search Tokens Search for specific file types: For example, if you wanted to find all the JPEG (.jpg) images on your Mac, type .jpg in the search field, and you'll immediately see results pop into the window. Click This Mac in the header to find all JPEGs on your entire hard disk. Not only will Spotlight display thumbnails, small images, of your JPEG images, it'll also list other things that match your criteria, such as documents that contain the word ”.jpg” in them. You can then access the file right from that Finder window.


I was wondering whether having a search-token "Around" that would filter numeric based searches to a +/-10% (or any other %) would make sense to include in a search field.

The problem that I have is that the fields that I want to search might be very precise, let's say $55402.12, $35014.16, $50957.78, and instead of using a range search token (that I'd assume would be complex to implement) that searches between $50000 and $56000 I'd like to search values around $53000 with a +/-10% tolerance.

So, in a nutshell the question is if having an "Around" Search Token would be useful of having usual ">" "<" ">=" "<=" ranges.

share|improve this question

1 Answer 1

up vote 6 down vote accepted

I think this is an excellent idea. People tend to think in those terms, "It was about $50k" so this would match well. I'd be inclined to sort the results by proximity to the search value, and make the range quite generous, but there is some logic which might apply.

This isn't going to be easier to implement than a range though. Either you're going to convert into a range in some way, or you're going to have to check the difference between the search value and actual values, and sort on that difference.

To convert a number into a range, you could use the precision of the number they give to determine the range.

So if someone says around 50000, you assume they're specifying the number to the nearest 10000, so include anything between 45000 and 59999. The reason for the imbalance there is that someone is unlikely to remember 44000 as being 50000 - more likely they'd think 40000. But someone might remember 57486 as 50000 simply because of the first digit.

Alternatively, if someone searched for 53000 then you'd include from 52500 to 53999 using the same logic.

If you don't get any matches then you'd probably want to broaden the range and try again though. You might set a limit that you'd widen by one level of precision, so if someone puts in 53000 and you don't find anything, then try as though they'd entered 50000, but stop there.

This might seem unnecessarily complex, but the idea behind all this is that you're trying to take what someone remembers and think what that might plausibly match, assuming they're not wildly misremembering of course.

share|improve this answer
    
Can you complement the idea giving a example for dates? I think your addition was great! –  edgarator Oct 17 '12 at 12:44
    
Sure, the thing is to think about what a human would think if you specified a vague date. Not enough space here, so I'll add to the answer –  Peter Bagnall Oct 17 '12 at 14:29
    
Sorry to switch on the techie side, but a select abs(log(<searched value>) - log(value)) as score from ... Where ... Sort by score desc; would do it in an SQL based app; this would work well for some datasets, depends on underlying technology and scale though... –  Aadaam Oct 17 '12 at 14:59
    
@Aadaam, not sure that SQL quite does it, it's similar in some ways, but the key part of the idea is that you treat 50000 differently from 53000 by searching a narrower range. In your algorithm there's nowhere to express how confident you are about the accuracy to which you know the number you're looking for. Instead your just sorting by how close you are to the target, albeit doing it logarithmically, which will distort the results somewhat, making higher numbers get treated as closer than low numbers. –  Peter Bagnall Oct 17 '12 at 19:45
    
@PeterBagnall: actually, logarithmic scale makes numbers closer have a higher score and it can ensure factors... Linear is pretty bad for representing factors (eg, '' it was about 50000" can be between 40000 and 6000" but "it was around 5000" is between 4000 and 6000, that's what log() is for –  Aadaam Oct 18 '12 at 6:32

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.