This is a guest post by David Urbansky, CEO and Co-Founder of SEMKNOX and Site Search 360. David is a search enthusiast having built natural language search experiences for e-commerce sites and recipe search engines.
As a startup founder, there are always key product decisions to be made when Site Search 360, our key product, is embedded in one context versus another. I’d like to share some experiences, choices, and challenges in our process packaging Site Search 360 for Cloudflare Apps.
What is Site Search 360?
Site Search 360 is a search solution for websites. Offering a search bar on a website improves user experience tremendously if the site has more than just a handful of pages. According to a eConsultancy study, up to 30% of web visitors use the search feature on e-commerce sites and searchers sometimes make up 40% of the revenue. Additionally, Nielsen Group found that 51% of people who did not find what they were looking for with the first query, gave up without refining the search – the search had better work very well then.
Considering these facts, almost every website should have a search feature. However, implementing that functionality is not trivial. Developers are faced with multiple non-obvious decisions to make, such as:
- What content should and should not be indexed (do you need the header and footer of every page in the index? Probably not!)
- How do I keep my index up to date when I add new pages or change something?
- What storage engine should I use and how do I handle complex queries?
- How to maintin the additional codebase, especially if non-technical leadership wants to change a decision on what to index?
Thus, for most sites, a highly customizable off-the-shelf search solution is the fastest and lowest maintenance way to go. Site Search 360 offers that along with additional features, such as:
- Autocomplete and search suggestions
- High speed
- Mobile capability
- Full control over search results
- Analytics about user behavior and search trends
To make a search solution fit perfectly into the style and theme of a website, one has to be able to customize it. Site Search 360 offers over 60 parameters developers can tinker with to make the search behave and consistently fit the brand and style of the rest of the site.
Cloudflare Apps are configured visually though, and 60 input fields, radio buttons, check lists, select boxes, and sliders would be too much for the average Cloudflare user. Applying the Pareto Principle, we were able to identify the 7 parameters most frequently used that have the highest impact on a website’s look and feel. We chose these for our Cloudflare app.
Experience developing the Cloudflare Apps
We have integrated Site Search 360 with other platforms, such as Zapier (read more), Integromat, WordPress,and Drupal, so we’ve seen multiple interfaces and experienced many different processes of getting an integration working and approved.
Where Cloudflare stood out is the declaration-driven approach to app development. Using only the form elements provided by Cloudflare required us to think about how to map our configuration parameters to Cloudflare components and make them as simple as possible. Just this process alone made us reconsider some of our configuration options and how we could make them easier to use, even outside the Cloudflare use case. For example, instead of letting the user choose between a set of icons for the search bar, we opted for picking one. This allowed us to embed it directly in CSS and minimize the CSS file size that would otherwise get considerably bigger with every Base64 encoded icon choice we could have provided.
The single best thing I have to say about the process is the support. No matter how good the documentation, developers always have questions, so it was crucial for us that we could get quick and thorough feedback every step along the way. Cloudflare takes the approval process very seriously and only allows high quality apps into their store. Their eye for detail challenged us to go back to the drawing board more than once and rethink certain design choices, e.g. did we really need sliders for the margin of an element or can we simplify it to a choice between “none”, “little”, and “more”?
We encountered two main challenges:
- jQuery had to die: Since we have no idea on which of 7+ million sites the Cloudflare app will be installed we had to move away from jQuery completely to avoid possible conflicts. This is another example of a push that came through the platform that benefits our product also outside of Cloudflare.
- Account & Sign Up: In order for the user to see the search working, we have to have some indexed data. However, if a user without a Cloudflare account just previews the app, there is no indexed data. We therefore created a preview account that shows search results from Wikipedia, making registration unnecessary to preview the app.