the Planner Bot
Raising residents’ awareness of changes in their neighborhoods in San Francisco.
for Programming for Online Prototyping
This is an individual project
Many residents in San Francisco are not aware of or engaged with changes in their neighborhoods.
This is because:
channel of information and engagement is limited and often not readily accessible to all population;
information is presented in a dry and complex format; and
residents felt that they have little say about what is to happen
An SMS chatbot that provides easy access for residents to learn about what developments are proposed and built in their neighborhoods.
Curious? Text 916-571-1439 !
Powered by Existing Data
“Karl the Planner Bot” is powered by DataSF’s API – SF Development Pipeline 2018 Q2. This database is currently built and used for various technical purposes within city planning and operation.
My goal for building this bot is to experiment whether I can make this information accessible for more people by leveraging conversational user interface.
Who should use this bot?
Anyone! (ideally :) )
With the current iteration, however, the information remains rather limited and some terms still sound quite technical. For now, it is probably best for planners around the region or individuals who are somewhat familiar with urban development and related terminologies. Karl offers them a quickly learn about ongoing projects in San Francisco.
Feature 1: Neighborhood Specific Info
Users can ask about information by neighborhood in San Francisco. The current version of Karl does require users to know the SF neighborhoods.
The original data from DataSF's API had information by "Planning District" – a region unit used specifically by planners but not by the general public.
How do we work around this and still make the bot informative? To overcome this without altering the original data, I did some quick mapping and created another database that includes roughly the Planning District of each neighborhood.
A better way to overcome this would be actually include the neighborhood information in the original data base (through spatial join with neighborhood data in GIS) – that’s be something to consider in the next iteration.
Feature 2: Any Project in the Planning District
After learning about the project in the Planning District, there is an option to look into details of a randomly selected project.
The ideal situation, again, would be prompting any project that’s more relevant – closest to the user’s current location, home, work, etc. It’s also be useful if the bot can search with keywords. They’d all be valid features to build for the next iteration.
Feature 3: Random Project Info
Users may choose to know info of any project in San Francisco (without the PD filter). The feature is built on the same mechanism as feature 2.
You’ll see that the generated messages can be very awkward to read when certain data points are missing information. This is something I didn’t get to address very well in my code but I will keep working on it!
Dialogue Flow & Tone
Aside for coding, most my energy thus far has been spent on making the bot addresses failure and dead-end properly. The design of tone and attitude matter significantly in these situations.
Building the bot’s personality was one of the toughest part of the process and one part I wish I have pushed more. I explored various types of personality – (1) a long-term SF residents who is opinionated about SF development, (2) a friendly corner store owner and a neighborhood know-how, and finally, (3) a City Hall intern who is courteous and with limit knowledge.
Because the data was so technical, it was really hard make the information flow like everyday conversations ("I can't believe that department building only has 13 affordable units!").
As blend as the final bot's personality turned out to be, I actually appreciated the mild formality and was interested to see what feedback I’d got in the upcoming testing stage.
Reflection and Next Steps
I knew walking into this project I'd be working with a dataset whose technicality will cause limitations, specifically how natural the resulting conversations may be. I wanted to use this project to make a point that with little edits, technical data can have more use cases that benefit a larger population.
If I had more time, here are a few items I would like to tackle:
tweak the language of technical terms to be more natural-sounding (ex. bp filed --> Business Permit Filed)
better handle blank/missing data in a sentence thread
incorporate database to remember user's request and provide project update when the status of the projects changes
work more on the personality of the bot and its tone of voice
Overall it was a great learning experience, and I hope to push the bot a bit further to function as a true resource for the public!