While I agree that building a great and relevant search experience with a Lucene-based engine requires lots of extra time and effort to get right, there are other non-TFIDF based solutions that provide a much faster path to great relevance with far less effort (https://blog.algolia.com/inside-the-algolia-engine-part-1-in...), and it's possible to have semantic ranking without too much machine learning (https://blog.algolia.com/promote-search-results-query-rules/). Not to discount the value of machine learning - we're finding that for specific usecases ML can be a very valuable way to help surface more pertinent content for individuals based on their profile/preferences etc. (https://blog.algolia.com/personalization-announcement/).
This may be along the lines of what you mentioned around "commoditizing" complex traditional search workflows. I'd be curious to hear more about what kind of use-cases you think are trickiest without SS.
Although I'm a big fan of Algolia search (because it's freakin' fast) I happen to know little to nothing of your search model other than what I have learned from Algolians chipping in right here on HN.
I used to be quite impressed with Lucene, even at version 1.0 (when a fuzzy search meant a full table scan), then watched in joy when they conquered the search market, before realizing how it struggled (and still does) with, well, I hate to say it (because I'm usually ridiculed when I bring this up), y'know, big (-ish) data. The proposed and popular solution: sharding the data onto a cluster of machines.
Algolia seems to be a focused, streamlined and more efficient ElasticSearch, at least in the FTS use case.
I've worked almost exclusively in e-com for ~20 years. Algolia FTS+personalization seems to fit the e-commerce use case pretty darn well.
I wonder, regarding "Algolia Query Rules" (which also seems like a real killer-feature for e-commerce):
>> automatically transforming a query word into its equivalent filter (“cheap” would become a filter price< 400...
How do you translate "cheap" into "price<400"? By maintaining a dictionary? Also, what if some people think 400 is quite expensive?
I want to build or implement a search engine that is inherently self-maintained in the same way you and me are self-maintained. As humans, however, we do have a serious flaw. In order for us to maintain an index of our knowledge we need to sleep. To start with I'd like to try to mimic that construct, then move past it.
Got it. Would you send me an email at hello@getonboarded.com? I'd love to show you how you could implement a non-modal flow with Onboarded in ~5 minutes. Would love your feedback.
We don't think developers should have to reinvent the wheel, or cobble things together to build a customized experience. You're usually not writing 50 lines of javascript one time only and calling it a day - you are changing your flow all the time, as soon as you see evidence for how to make it better. Onboarded is a tool that will make that process of learning and iteration much more efficient (and thus faster and cheaper). And there's no reason you couldn't integrate with Segment too.
The thing is, we're just focused on the free tier right now. When you've onboarded lots of people and decide you like the product, pricing is an open conversation.
I do not want pricing to be an open conversation. That sounds horrible to me.
To take a wild guess - maybe you think that an open conversation is good for the customer because it represents flexibility? To me it doesn't. To me it screams "UNCERTAINTY!" and the less of that I have the better.
First - apologies. There is a point to this. I apparently like taking the scenic route to get there.
I'm at the tail end of roughing out the high level design of a pretty large (as in complexity, not number of users yet), Enterprise SaaS thing.
In any case, I've had to probably glance at 5,000 things and of those, look at 2,500 things, and of those play with 1200 things, evaluation 700 things to end up with about 300 things (currently) that will turn into probably less than 150 things in production.
At the front end of this process, I probably unfairly dismissed some possibly viable candidates for technologies or services. Which is unfortunate and ultimate unfair to the vendor.
The two top things that made me go away (unless HN or somebody pointed me back) was:
- The front page, the about page, and the top blog post don't really tell me what the company is or the product is. IF I get pointed back to look, I'll poke around github to see if some brilliant marketing maneuver made them put their "about page" from their website into the github Readme.md. (I'm looking at your, Weave)
- I can't find a way to put the right number of zeros behind the price in my estimates. Now. 6 Months. 12 Months. 24 Months. 36 Months. It has to be easy-to-understand (because I am very simple), and look thought-through and stable.
I am 12 months away from having to embed on-boarding into our project, and I will come back and see what you have at that time. But, please, for the love of getting anything past the CEO/CFO/Board ... let me rough out a guestimated cost (for us; pricing for you).
N.B. 1) Our use case probably isn't in your sweet spot, but who knows, you may shift.
N.B. 2) Not trying to be harsh, but I was up to my ass in alligators 2~3 months ago, and I would have tossed the link and not looked back.
Gonna agree with others that I don't like "pricing is an open conversation". Sounds like you just don't know what to price it at. Why not just start with something and then adjust up/down as needed?
The key point about Onboarded is that it's made for developers. It makes it simpler and faster to completely customize the user experience that you want, integrated as you see fit with your app's existing functionality and look/feel.
One of the goals we had when we designed Onboarded was for it to be unobtrusive yet flexible. It can be used to accomplish just what you are saying. The styling as overlay/modal is just a default to get you going. It can be made into a fullscreen flow or inline, or however you want. Onboarded makes it easier to do all those things stylistically, as well as bind event handlers, post data, etc.
Maybe in the intro path in addition to saying 'let me out' you could have an option like 'i like the concept, but show me a different style' and then take a few example paths to show off possibilities
This kind of response makes me think of the mandatory training missions that have started populating the introductory levels of many videogames - Even though movement is the same as every other game, we're going to spend 10 minutes to teach you how to walk around and shoot your gun.
Increasingly, the option to skip is removed. If you want to play a game with your friends, you have to spend 10 minutes doing what the game tells you to do.
While I agree that building a great and relevant search experience with a Lucene-based engine requires lots of extra time and effort to get right, there are other non-TFIDF based solutions that provide a much faster path to great relevance with far less effort (https://blog.algolia.com/inside-the-algolia-engine-part-1-in...), and it's possible to have semantic ranking without too much machine learning (https://blog.algolia.com/promote-search-results-query-rules/). Not to discount the value of machine learning - we're finding that for specific usecases ML can be a very valuable way to help surface more pertinent content for individuals based on their profile/preferences etc. (https://blog.algolia.com/personalization-announcement/).
This may be along the lines of what you mentioned around "commoditizing" complex traditional search workflows. I'd be curious to hear more about what kind of use-cases you think are trickiest without SS.