Process
Test out and print the data on a map before we start coding, and it will help us make decisions about the flow. Over the weekend, we want make a map using plotly.
Safety and comfort are different. Safety is more concrete, and comfort is more of a feeling. Comfort is personal. It changes between people. If we optimize for comfort, we also have to include a person’s own biases in the optimization. Will people use this service if we optimize for their safety rather than their comfort?
Do we want to suggest only one route, or multiple? We want to keep as much of the path generation and optimization behind the scenes as possible and suggesting multiple maps might confuse the user more than help them. Users may have a problem with the one route that we give though.
Older crimes might not be as relevant as recent ones. This is pretty obvious but something we hadn’t considered until the review. Locations change. People come and go. Crime does as well. It still may be indicative of a trend, but older crimes should not be weighed as heavily as more recent ones.
Thresholds for avoiding crimes, should that be up to the user or us? We want to give the freedom to the user but also want to make the interface simple.
We should simplify the flow diagram. Right now, we have a lot of different parts that do similar things, and we can change that. After the review, we iterated based off of individual feedback on our flow, and created a more direct process.
If we have a lot of different categories, we should give the user the opportunity to choose which ones are most important. With that feedback, we decided to limit our categories to four that they can choose. Our stretch goal is to include more than four categories, that the user can rank and potentially weigh.
Code:
In terms of figuring out which Web Application to use, we discovered there are three main ones we can choose from: Flask, Django and Tornado. According to the teaching team, Flask appears to be the best because there is a lot of documentation available and several Ninjas would be able to assist with it. We plan on first exploring Flask as an option for our Safe Route web app, but if it is difficult to adopt we will consider using Django or Tornado.
We also realized that since we are acquiring data from a CSV file that we will need a tool to clean the data - some lines may not have certain data points or there may be columns we want to omit. Based on the teaching team’s feedback we will be looking at Pandas as a tool for cleaning and visualizing. Since we are creating a web page, we plan on having a JSON file to store the data and create the dataframe using Pandas.
Finally, because the data is being altered, we learned how it is important for the dataset to be in one stationary place, and thus we will assign one team member to keep track of the dataset and communicate with the team when it’s being updated.
We got quick and simple answers on our technical questions, e.g. flask is better than django because ninjas know it better than others. We brought in a document with data categories, and flow diagrams for our project. People changed our flow diagram and marked it up, we were able to get that feedback directly. We also now have that feedback concretely to refer back to. For the ethical component, people got hung up on the data. We heard “if the data is corrupt, and you have no other, there is not much you can do” multiple times. We could have given more context prior to the review by assigning some readings, so that they would have had more time to prepare more constructive feedback. In terms of timing we had a timer in front of us and ensured that we stuck to our schedule so we were very satisfied with how much information we were able to gather in our given time frame. At the next review, we want to provide readings beforehand so that our friends can give constructive feedback. Whether it be technical or ethical questions, both deserve some substantial context. We found that since we didn’t do that, the feedback for the ethical question was not very useful.