Updated 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.
On a high-level, our code essentially has two different models: Complaint, Building. Second row indicates instance variables and third row indicates class methods. All classes come with a default field named id as their primary key.
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 Submit our code sends the address information submitted to be verified with Google Maps. There are two consequences that can happen:
-
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.
-
If the address does exist then the code uses the same BetterForm object on the next page with a map preview of the address and a prompt to confirm the complaint.
The new redirected page in 2 is to check if there were any fields the user would like to change. The following actions and consequences can happen:
-
If the user clicks the back button, he is presented with the original empty form on /report/.
-
If the user clicks Verify, the form is parsed and the system checks if there is already a Building object for the user-specified address. If there isn't, then the system creates a Building object. In both cases, Complaint objects are created for each user-specified category.
Each Building object in the database has a corresponding building page at /building/. These building pages consist of the title for the building, pictorial representation of the address, number of complaints per category and a Disqus embed comment system.
We decided to use Disqus as it would handle comments by users effectively by allowing them to comment via logging into popular social networks (such as Facebook) or through their Disqus account.
Our API lies in /api/v1/... The API provides access to getting all building objects or a specific building object from the database. This is used in our Home page to display markers for each building object in the database.
The home page lies at the root / and consists of a Google Maps embed object. The embed uses our API to fetch all building objects from the database to display markers on the map.
As follows is the navigation structure of the present website:
There are numerous technologies that we decided on using to make organization easier. The following paragraphs describe them and their utility:
-
Jira – This is a online project management tool. 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. Jira is invaluable to maintaining organization throughout the project.
-
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.
-
Foundation – This is a CSS framework we used to style the interface of the website in the form as well as all other pages. Foundation also scales the website to fit on different screen sizes.
-
jQuery – This is a javascript library we used in the website to allow more javascript functionality in our site.
-
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.
-
Disqus – This is a blog comment hosting system that is integrated into our building pages so that users can comment on buildings and read other comments about the building.
-
Tastypie - This is an API framework for Django that was used to build an extensive API for our web application.
-
Django - The framework for Python that is being used to host our application. Django's advantages range from it's easy code-readability (through Python) and extensive add-on support.
The organization of our web application was thought-out and refined over several meetings. Here are crucial changes since the last sprint in software structure:
-
No Submission class – This decision was made to reduce the model complexity of our system by streamlining the process of verification using a Django form class to preserve the form until fully verified.
-
Minimum Viable Design - The Complaint class was streamlined to possess only three fields and the Building class was given more fields to allow the system to achieve functionality of a Minimum Viable Product while being as compact as possible.
-
Building an API - We decided on building an API to allow easy access for our template pages to the models and to also ensure that future programmers can use the API to gain access to ACORN's data without having to completely understand our codebase.