A More Interesting Search Mechanism

There are a lot of things that I like about the 10Centuries platform. It can run on a minimal amount of hardware. It can support a wide array of goals1. It can even keep it's sole developer busy and out of trouble for the most part. One thing it can't do very well, though, is search.

A Better Search Box

There are search functions in the system, of course. My complaint is more about the ineffective way I go about delivering search results as there are two different methods that are employed. On blogs such as this one, for example, the search page performs the look-ups locally in the browser. When the page is loaded, the API is queried to return all of the post titles, tags, and a couple of other attributes which is then stored in memory. As a person types in the text field, the browser runs through everything in the memory to see what matches, then presents the filtered list.

While this works for the most part, the method is woefully incomplete. To find a blog post with the word "yellow" anywhere in the body, I would need to use a search engine like DuckDuckGo, Google, or Bing, as the body text is not returned and stored in the browser, given the sheer size of some websites (like this one).

The other option would be to go with the standard search method of showing the text box and waiting for a person to press the search button before querying the API. Going right into the database with a specific set of criteria would be a far better way to provide more specific results without filling a person's browser cache with superfluous data. This is how it was done for 10Cv2 and it's how search works for the social posts. Given how most sites across the web work the same way, this would make the most sense … right?

Even if it is the simpler solution to the problem, it's not the most interesting. Performing search with the help of a database is just too easy. The instant feedback of results as we type our criteria is a much more exciting challenge, particularly when the back-end API is written in PHP rather than Python, Ruby, or something else that can more easily use websockets to maintain an active connection between the front and back of the system. What I'd like to do is find a middle ground that could offer the best of both worlds2 without bogging down the browser.

Google shows common and related searches based on what's typed. Bing does much the same. 10C simply does not have the volume of search requests to make this a feasible option (nor is there even any tracking for what search queries people run), but one option might be to have a list of unique words sent to the browser for auto-completion. This way a person looking for "Nozomi" would see the option after the first or second character is entered. Once a person is happy with their filter criteria, the "Search" button is hit and results come back from the API.

Is this more interesting than the current mechanism? Sort of. Will it be something that makes search more useful? That's the $50 question.


  1. The 10C core platform has been used for: blogging, social networking, note-taking, library cataloging, school management, shuttle-bus coordination, and even recording temperature readings from various network-connected thermometers and presenting the data in a real-time feed to people interested in such things.

  2. Mind you, this is all geared towards people who have JavaScript enabled in their browser. A person who has disabled JavaScript for security or other reasons will just have a text box until they hit the "Search" button.