Swiftype for Mobile: Full-text search for iOS and mobile Web | Hacker News Reader

Swiftype for Mobile: Full-text search for iOS and mobile Web

swiftype.com

59 points100k18 comments

I'm really proud of this release. I'm happy to answer any questions about it.

If anyone has any doubts about how hard Geoffrey Grosenbach or Ryan Bates work on their screencasts, put them to rest. Those things take _forever_ to make!

Great great screencast. The product it also looking awesome. Congrats!

Yep, never underestimate how long a quality screencast takes. It's totally worth it since many developers and customers want to see what it looks like before trying it. And especially for platforms, describing in words is sometimes too abstract.

I believe Ryan Bates has said 1 hour per minute. If anything, that's an understatement. Maybe it gets easier as you do more (this is my second screencast).

1 hour per minute is a pretty good estimate. It does get easier. It's all about preparation and setting up an efficient workflow.

I am confused about the swiftype value proposition? What does it offer over simply installing elastic search (et al.) and pushing json documents. Making a mobile/web search front-end isn't very difficult using json results+mustache templates etc.

I was unable to find on the swifttype website what the advantage of using the product. I did like the drag/drop result ranking though, that's pretty neat.

They have an overview video on the homepage. Seems like analytics and ease of use are the big wins for it. For someone that wants no hassle search the crawler looks pretty neat.

Interesting. Odd that I should be downvoted for asking this question, but whatever.

I get the benefits of cloud based search hosting, but am surprised that analytics and a crawler is enough of a reason to pay money though. Crawler's are flawed because there's always a latency. if you already own the data, it's much better to push content than wait for a crawler to pick it up at some arbitrary future time.

For someone that wants no hassle search there's always site: from google, but I wish these guys luck and find it interesting how a little feature like analytics can make a business.

I thought it was unfair you were being downvoted, I counteracted that.

It more accurate to push data (and many of our customers do) but most people with web sites are not able to do that. We are working on making our crawler as fast as possible (for example, we just released incremental updates: http://swiftype.com/blog/incremental-updates.html) and paid users will be able to crawl as frequently as necessary.

Regarding Google Custom Site Search...let's just say we don't hear of people switching _away_ from Swiftype to Google Custom Site Search. IMNSHO, our product is already better in just about every way.

Good to know, thanks. Crawling certainly is easier, made especially so using tools like JSoup/BeautifulSoup, but areas like gist extraction, learned removal of navigational elements, the benefits of a truly massive IDF for terms, phrase extraction, date extraction etc all seem beyond the realm of a startup. I have written these pieces and know it can be a real time sync.

I'm curious about your drag/drop ranking tool. Does this create a static or query dependent ranking boost? In my experience, the former is easy, but not very effective, the latter is much more difficult because of stemming, synonyms, partial match etc.

I had to look up IMNSHO :)

For developers, we have an API (http://swiftype.com/documentation/quickstart) that is not much different than setting up Solr or ElasticSearch. However, you no longer need to manage the search servers. We handle reliablity and scaling. On top of that, we offer client libraries (like SwiftypeTouch), search analytics, and a management dashboard (think: you write the search, the business people take over managing the results).

For less technical users, we have a web crawler with automates the creation of search engines. Combined with our crawler controls and meta tags (http://swiftype.com/documentation/meta_tags) you can build a really powerful site search engine with little effort.

thanks for the information. Speaking as someone who has worked in the search industry for many years I am surprised to see this. For me, setting up an ES server on AWS and pushing content directly into it seems pretty trivial, but I get the business analytics, dashboard etc.

The meta tags seems like a reinvention of og?

How about scaling that ES server to 100,000+ queries a day? ;-)

We support a few og tags as well, but our goal is ultimately to be able to make very flexible search engines without code, so the person managing (say) the help section of a website can make an amazing search engine without involving engineering.

100k per day is just over 1 q/s, which shouldn't concern any scale engineer. If you take that two or three orders of magnitude higher it starts to become something the scale engineer pays attention to, otherwise, I don't see the concern with that low qps.

I get that it's cloud based, with all the elastic benefits that affords, but if I look at this from a VC perspective we have two use cases:

- the customers with their own private data that wouldn't trust two guys in a "garage" in Potrero Hill. - the customers that want a no engineering solution to providing a no-engineering solution to making a section of their website searchable. This seems pretty much covered by Google's search offerings in this area. Complete with a scale out story beyond the wildest dreams of a startup. It also has the huge benefit of a relevance engine that is best in class.

Clearly, if you have customers, I am wrong!

We have been using Swiftype at SupportBee for searching the help docs - https://supportbee.com/helps. We still use ES for core application search (tickets etc) but for things like help documentation, site search etc it's hard to beat Swiftype's setup time and ease of use. The analytics is pretty useful too. Disclaimer: Swiftype is our customer as well but we used them for many months before they found out about us and signed up :)

404, guess that was https://supportbee.com/help

funny though that it shows 0 results for "supportbee"

I saw "Swiftype" and my brain thought "Swiftkey" + "Swype"...two things that I wish would someday come to iOS.

I too thought immediately of Swiftkey, and wondered if Swiftype will have branding and/or trademark issues.

OT, but Swiftkey is actually working on a swype-like input called Flow. http://www.swiftkey.net/flow/

Reply on news.ycombinator.com