kfogel
commented
12 years ago At Open Gov Hack Night in Chicago, we made a branch that implements full-text search. It needs some cleaning up, but the basic functionality is there:
https://github.com/OpenTechStrategies/srtracker/tree/full-text-search
Things that need cleaning up:
- If you enter an SR number as the search string, such as "12-00699487", the back end might return multiple results due to its own algorithm for breaking up the SR number for searching -- in this example, these two issues would be returned: 12-00699487 and 09-00699487.
- While it might make sense to return multiple SRs when the search string is an SR, the top one should be the exact one named and the rest should be SRs that are related to it in some way (not SRs whose numbers just happen to be similar)
- After the user does a search, the search string should be left in the search box for further refinement (currently, the search box is cleared out again, as if they want to start a completely new search)
- This search functionality should just be what the front page does (e.g., even without "/search" as the URL). Furthermore, the search boxes in the header and on error pages should do this same search. Basically, smart search is the One True Behavior, and it should just be reachable from everywhere, including the front page.
- A result might be returned because the search string matches text in a field that the API doesn't make available to SRTracker to show the user -- e.g., the description field, to name one likely candidate! Not sure what the right solution here is, except possibly to display a message informing the user that that's what's going on.
- When there are no results, it should do better than just showing blank space.
- We're limiting to 499 results right now because the server side limits to 500 anyway. The real answer is proper pagination.
There's probably other stuff we haven't thought of, but hopefully this is a start. Go wild :-).
Mr0grog
Chicago's Open311 API supports searching by using the "q" parameter on the requests.json/xml endpoint. (http://dev.cityofchicago.org/docs/api/service_requests). It would be great to optionally support this in SRTracker.