With almost 25 thousand buildings, having a way to search the database would be nice. And just like how I did geo searches client side, searching buildings was done client side too. The inspiration for the interface was The Texas Tribune’s Tribpedia landing/search page. The final building search page can be found at elevators.texastribune.org/building/ and the JavaScript source can be found at github.com/texastribune/tx_elevators/blob/2013-april-fools/tx_elevators/static/tx_elevators/js/search.js.
How it’s made
The one lonely chart on the home page isn’t the only place where D3 is used. The building search UI is built using D3. “But it looks like HTML, not SVG!” the astute reader might remark, and you would be correct. D3 is not just for SVG, it can be used for HTML too.
The first step was to build the NOSCRIPT version, which was just a list with links. This list also serves as a way to map building ELBI IDs to urls and as a map for search engines. This was partially because the original API didn’t have a way to return urls, and because I wanted to keep the json light. As a side note: When I moved to putting slugs in the building URLs, I had to go back and modify my geolocation API to return building URLs (and thanks to generators, it was not hard to do).
The first thing I did was bin each building by name. The important thing to note is that I split it up into several steps. The binData function organizes the raw data into bins, which almost parallels the structure of the final HTML. The binned data then gets passed to the prepNameData function which finesses that data to look exactly like the structure of the HTML. The next block of code, prepBinsHtml, is just basic D3 to to map the finessed binned data to the final HTML. The rest of the file is just jQuery for the user interaction. This demonstrates the power of D3: Once I had the code to map the one set of raw data to HTML, changing the data, either by filtering it for search or re-binning the data, just magically worked.
Performance details
I didn’t have a lot of time to make tweaks, or even do basic documentation, but I did make one optimization: I kept the number of dom elements to a minimum. I used divs for items to avoid ul>li nesting, and I didn’t use a tags because it would have doubled the number of elements needed for each building. And when you have nearly 25,000 buildings, it matters. The major downside is I had to fake a tag behavior, which is still incomplete. For example, you can’t middle-click to open in a new tab, and the hover interaction is only partially there. Much of that optimization was inspired by these slides by Jon Rohan of GitHub. And if you compare the interaction of the Tribpedia landing/search page with the building search page, you’ll see that this approach results in a much faster experience.