Sometimes your programming intuition fails you. On a small project like Searchlight, it's generally one guy who's driving it and writing the majority of the code. In those circumstances, users generally believe in the project and its philosophy or they don't. If they don't, they won't use the software and the program will disappear in to obscurity. If they do, then the lone developer can sometimes be faced with the prospect of making a .. *gasp* .. mistake.
Today was that day for Searchlight. Of the cool things still to be done to it - such as integrating and completing Holger's "Snippits" (Very cool idea!) - I decided to work on the scoping issue inside the Refactoring Browser.
For those of you who aren't familiar with Searchlight - you load it up and it adds a Search box to your VisualLauncher, it adds a standalone auto-resizing Searchlight window and it takes over the Find drop down list in the Refactoring Browser.
I had been getting annoyed with the speed of the search in the RB and the fact that it searched my whole image and didn't focus in on my current locality. To this end, I decided to reuse the RBs current state as a scope for the search. The idea had been thrown around a few times and I gave it a go. Some of my die hard fans jumped on the new version and got back to me with feedback almost immediately - which was fantastic.
However, the feedback was thus: "It sucks!" - okay, so they're more polite than me and didn't say it that way. I was sitting back smugly, patting myself on the back at the good job I'd done adding scope to the RBs searchlight.. and I very quickly found out that people didn't like it. Several users told me they didn't like it. I was amazed.. I thought it was the greatest thing since swiss cheese and let's face it, that's how the RB used to do it too.
It turns out that people often have multiple packages which they consider "my code" that they want to search over. And sometimes they really do want to "jump out and find something else" .. but the thing that really surprised me was that they didn't want to have to leave the RB to do it.
In fact, one user of Searchlight remarked that he never used the Find drop down in the RB until he started using Searchlight and now uses it exclusively. To which I can only say "Woops" - since my change totally breaks that kind of usage.
There's no way to know what code the user really wants to jump to - or is there? What if the search program could read your mind, or at least predict what you are thinking. That is the goal of many modern searching tools, such as Quicksilver - they want to inspire the magical, the sentiment of "Wow, how did it know that's what I wanted". They want you to be proud of your search box, pat it on the head and say "Good dog" when it fetches you todays news instead of chewing on your slipper.
So Searchlight should do the same. It should figure out what you want. There are a number of things I can do here - I'm going to backout the scope changes I made and instead use them to alter the results scoring. This will give searches inside the RB a "pull" .. or a "locality". Things nearby will score higher than things further away. This is almost counter intuitive, since things nearby are easier to click on than things further away. But what I've discovered is that a good smart search box can be more efficient at navigation than using the mouse. Search boxes are almost becoming the post modern command line.
The other thing I can try is to simply have the computer observe your behaviour. Given something you type, where do you normally end up going? So when you type something similar or exactly the same, those sorts of things can bubble up to the top of the list. The trick with this sort of thing is to make sure it forgets when you change your habits.
I'll probably give some of these ideas a go tomorrow so that the development stream of Searchlight doesn't stay "broken" for too long. Thanks to Holger, Randy and those who emailed me with the feedback.