Searching

A central component of the third phase of the IDB project was implementing a "Google-like" search that could also handle multiple terms. Search is crucial to user experience online, and Google, the web's most popular search engine, forms the foundation for individuals' connection to the Internet. Google, with its famous PageRank algorithm for displaying search results, set the standard for proper user-oriented search. All other online searches are implicitly or explicitly compared to its abilities. Implementing "Google-like" search for our project was a daunting task and one that we did not take lightly. Calling a search "Google-like" is a privilege that must be earned by a meticulous combination of intuitive design and simplicity. Incorporating search into our project was a large challenge. Even defining what "Google-like" search meant, for us, was quite an endeavor.

Defining what "Google-like" Search is

In order to define what "Google-like" search was, we decided that we needed, to use a popular sports turn of phrase, to go "back to the basics" – defining what search itself means. Ultimately, we determined that we consider baseline search capability to be the ability to find any representative, political party, or district associated with the user's input term. This, of course, is rather simplistic – one expects to see Speaker Paul Ryan appear in the results of a "Paul" search – but it gave us a foundation on which to begin building. The next step was defining what we meant when we used the term "Google-like." Ultimately, we decided that "Google-like" search was the ability to associate seemingly unrelated terms with any of the content from our three models. This meant that not only would we display Speaker Ryan, we would also show his associated party and district. A user, for example, may have intended to search for Wisconsin's 1st district, but could not remember its specific name or formulation. Our "Google-like" search provides users with the opportunity to use vague terminology and gives users the opportunity to decide which results were best suited for their query.

Implementing our search

We first had to add our Search component to our website so that users could even have the ability to perform searches. We decided to put our Search component in our Navbar (located in frontend/src/js/Navigation.js).

We then had to implement the actual search functionality, which we did through the backend (located in backend/routes.py:509). Every time the user makes a search request, it sends an API request to our backend in the following form: api.swethepeople.me/search/?query=USERQUERY. Our backend looks through each attribute of every element within each of our three models looking for items similar to each word in the user inputted search query. Once a search query element shows up in an attribute of an element, we increment that element's rank by 1. After we search through all our models and find relevant elements and their corresponding ranks, we then create the response object, which is returned to the frontend.

The frontend will then parse the response and display the cards, ordered by their rank, to the user, highlighting anything on the cards that have the user query. This is the end result of our search process.