Design and Technology Manifesto

Our main goal was to build an interactive map so that users can view previously posted complaints as well as report complaints of their own. Our language of choice was Python with the Django framework.

HIGH-LEVEL OVERVIEW

On a high-level, our code essentially has four different models: Complaint, Building, User and Submission. Here is an overview of the process of reporting a complaint that uses the above models.

When the user first navigates to /report/, he is confronted with a form that needs to be filled in. Once the user clicks Verify our code sends the address information submitted to be verified with Google Maps. There are two consequences that can happen:

1. If the address does not exist on Google Maps, then the user is redirected back to the form with a prompt to enter a valid address.

2. If the address does exist then the code sends a POST request with the latitude and longitude returned for the address from Google, type of complaint, user’s name, user’s email and user’s phone number to /report/verify/. This creates a temporary Submission object in the database.

After this the user is presented with a verify page called /report/verify/. This page consists of an embedded Google Map that shows the address the user entered, prompting the user to see if the address is correct. If the user presses Cancel, then he is redirected back to the form at /report/.

If the user changes the address then it’s latitude and longitude is saved, and when the user clicks submit a multitude of things happen:

Firstly, the latitude and longitude along with the type of complaint is used to create a new Complaint object. Then the code checks to see if a Building object for the latitude and longitude already exists. If it doesn’t then create a Building object . Either way the code will store the created Complaint object in the Building object’s list of complaints.

Once this is done, the name, email and phone number are used to create a User object if the user isn’t already in the database.

All of these models are stored in the database and once the three objects are created, the temporary Submission object is destroyed. Then the user is redirected to their relevant Building page with their complaint highlighted.

There are two more components of the website:

Index – The index page lies at / and it displays an embedded Google Map that iterates through all the Building objects in the database and creates pins on the Map for them as well as a link of the pin to it’s corresponding building page.

Buildings - The building page lies at /building// and basically parses the corresponding Building object’s complaint list and displays them on the page.

An overview of the navigation can be seen as below:

Technologies Used

There are numerous technologies that we decided on using to make organization easier. The following paragraphs describe them and their utility:

1. Jira – This is a online project management tool. We moved from Trello to PivotalTracker to Jira in search of an optimal tool and Jira does everything we need it to do. Our SCRUM board lies in Jira and allows us to assign sub-tasks along with their story points and estimates, all of which can be used to automatically generate a Burn Down Chart.

2. Flowdock – This is an online chat tool that is very helpful in communication between members. It has several features including tagging other people and hashtags in posts, where hashtags can be helpful when querying the chat history.

3. Foundation – This is a CSS framework we used to style the interface of the website in the form as well as all other pages.

4. jQuery – This is a javascript library we used in the website to allow more javascript functionality in our site.

5. Google Maps API – We are using the Google Maps API when querying our address when the user first verifies his submission. This allows for Google Maps to handle the address validation.

6. Disqus – This is a blog comment hosting system that we want to integrate into our Building pages for Sprint 2 so that users can comment on buildings and read other comments about the building.

7. Genmymodel – This is an online tool that was used to build the UML and interface diagrams. It’s ease of use and similarity to most graphics tools made it a very viable tool for UML design.

Decisions Made

The organization of our web application was thought-out and refined over several meetings. By looking at the minutes of our last meeting, one can see that we made our most critical decisions at that time. Among them was the following:

1. No Contact Us Page – We decided against having a page for users to click on and contact ACORN because we could just as easily provide them with this information after they submit a complaint.

2. Using a new Submission class – This decision was made in order to handle proper verification of the user’s submission. With the inclusion of this class we are able to generate the relevant URL at /report/verify// so the user can check his complaint before submitting it.

3. Modular design – We decided to make two new classes, User and Building to make our program more modular and thereby reducing the instance variables that we previously allocated for the Complaint class.

4. Redirection in website – We discussed and decided on the general interface for our web application, with all the pages that we deemed were necessary and the behavior in case of user error.