At ZendCon during one of my “wander around in a nice inebriated stupor while supposedly maybe promising M— that I’d go see Facebook’s API talk” times, I ended up at the Krugle booth and talked to Mel Badgett their V.P. of Product Management, which quite frankly, was much more interesting than learning about an API I already know about.

I suppose I should talk about Krugle because they gave me a $5 Starbucks gift card which will may have a little use when I’m out with friends who need to get their fix—by my count, that’s just about anyone here in the Bay Area.

For those who don’t know, Krugle is a code search engine, like the one Google has in their labs section. Only probably a fair bit more complete than Google’s because Google and vertical search has been an unmitigated disaster, IMO.

You can watch an instructional video of the how to use Krugle which gets to my big beef with the search engine from a user interface point. I’m not the target market for these things and I understand that a developer who is going to use Krugle is easily going to be repaid in time to learn the thing, but this begs the question: Should I need to?

Because of my position, I rarely need code snippets, myself. If I do, I can e-mail six friends and have the answer back quickly. Mostly, I just need syntax, and I use search term for that.

For instance

There are four search elements on the code search page: They are a text box, narrow by language, which type of code block it is found in (comment, code block etc) and what software project it is in. The UI seems cluttered this way. Compare this to Google or Apple Spotlight which just gives a text box and allows special strings to narrow the search—””, for instance. Granted this way is more available and if I’m a PHP developer I’m probably interested in only PHP blocks, but for most people (especially Mac users who don’t have Easy Access turned on), it is going to be much faster just typing the modifiers in the text block. And, like we assume, those who need to know are going to figure it out.

Another issue is the site is heavily AJAX’d in a manner that is very non-intuitive for a search engine (shades of A9 rear their ugly head). For instance, when you do a new search, it opens a new tab inside the page. This tab is not obvious at all to a first time, half-drunk user like me. No sir! Also they broke the back button along the way so hittng back goes to their main page instead of the previous search like I’d expect. They should add hashlinking here.

(Now in their defense, I’m told this style makes it easier to integrate the website into IDE’s in a manner that is intuitive for people who use IDEs. But if that is the case, why not make a special page or query parameter that sends it to a different mode? Besides, if it’s an IDE thing, why not work with the IDE developers via an open web-based API that would enable search using the IDE’s widget set and conventions?)

Another thing I’d like is a trick from It’d be nice if I could just type and have it just do the search for me.

Okay, I’m done bashing, now about some…

Interesting features

  • They have a powerful “search related” functionality. One clever thing is this includes an an area to allow sponsored searches/ad revenue. The example they give is selling related books from O’Reilly/Amazon.
  • The ability to add a note to a code and share that note with others.
  • You can search documentation, not just code
  • The ability to search within a certain (open source) project. But this might be good as a web appliance/intranet tool for tech companies.

Going vertical

Krugle is an example of vertical searching. Increasingly, instead of “googling” for something or someone, people are finding customized engines for looking up what they want.

  • Search for source code. Krugle see above.
  • Search for directions. I loved Mapblast until Microsoft bought them out and got rid of line-drive directions. Now I use Google Maps because the Yahoo! flash interface runs too slow on my Macs.
  • Search for people. I use Plaxo to look up information on people I know (too bad our interface sucks for that use-case. Go figure). Most people are starting to use their favorite network: LinkedIn for professional/HR, FaceBook for college, MySpace for… Though I wonder how well that works when people don’t keep that information up-to-date and there’s no way to get that stuff on your smartphone.
  • Search for images. Yahoo! image search. If you are commercial, you use the stock images service which you can afford.
  • Search for video. I use Truveo. Of course, you can suffer in the hell that is YouTube’s excuse for a searchbox. That’s the first thing Google should fix.
  • Search for jobs. I don’t know the answer to this one, but I suppose that SimplyHired and Indeed are good sources.
  • Search for other stuff. Like looking things up on Wikipedia, searching blogs using Bloglines or Technorati, etc.

Which ones will win? If I knew the answer to that, I’d be rich. But I remember using Yahoo! back when they were (“Yet Another Hierarchically Organized…” -dropdown box-). Then I switched to because it was so fast. Then I switched to Google because AltaVista went all portal on me.

Google won for me because it was fast and easy. Then Apple added it to the top right of Safari and now they own the top right of my browser.

This makes me think about Google. Google owns general search hence the term “to google”, but not they are facing a tremendous explosion of market segmentation in the form of vertical searching.

Getting back to that Starbucks card Krugle gave me. Before the 90’s, we got our “cup of joe” from Dunkin’ Donuts and McDonald’s and were perfectly happy with it. Now we go to a Starbucks or our local coffee shop. Where were they when I was a kid? Somehow the market segmented in a way that no matter how great McDonald’s Premium Roast gets, that segmented vertical is here to stay.

Will the same thing happen to Google?

Who will own the top right of my address book? my Photoshop? my video player? my IDE?

4 thoughts on “Krugle

  1. Hi Terry,

    Thanks for taking the time to give Krugle a try!

    A few comments about specific comments you made in your post…

    1. Using special strings to narrow the search. Actually you can do that, in two different ways.

    First, you can use special terms such as language:xxx, project:xxx, site:xxx, etc.. Grant wrote a nice blog post about this.

    Or, for some languages, you can just enter the language name in the query as a shortcut. For example, searching on “php ecard” will return PHP source files that contain the term “ecard”.

    2. AJAX & the tabbed interface. Yes, this is a common complaint we get. The problem is that for exploratory search, having a tabbed interface can be a real win. See here for more discussion on this.

    But to help alleviate the problems this causes, our most recent release adds support for static pages in most UI elements. Just about everywhere that you see a link, there will also be a “static page” icon that you can click on to open the page in a new browser tab/window, instead of a Krugle internal tab.

    All links are also “link masked”, where you can control/right-click the link to get the standard browser popup menu (which typically includes items to copy the link, open the link in a new tab/window, etc).

    3. Back button. Sigh. Yeah, that’s been a persistent bummer. Especially if you want it to work properly on Safari. But fixing this is on the roadmap.

    4. IDE integration. Yes, that would be a beautiful thing. We actually implemented the entire site using a RESTful back-end service, which the web UI leverages to create a browser-based interface. So it’s fairly straightforward, once we’ve resolved the monitoring/throttling issues, to open up the API.

    Our big challenge is figuring out the “right” way to integrate…something more than just a lookup box with static search results comes to mind.

    5. Search via URL. It is possible, with the most recent release. The URL format is:

    For example, try this search.

    There are also plugins available for Firefox 1.5/2.0 and IE7 here.

    Chris Burmester, our AJAX dude, wrote a lengthy blog post with the gory details.

    Anyway, hope this helps – thanks again for taking the time to try out Krugle, and let us know if you have other questions or suggestions.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.