Skip to the content
Application Design Records
Decision: Programming language
- Problem: We have to choose a programming language to write the frontend in. This is important because we want to include custom functionality that can’t be replicated by typical website building applications.
- Constraints: The language must be stable and scalable (because we expect the website to be used by people from all over the country), suitable for frontend development (because we’re building the frontend of a website), and also suitable for mobile development (we assume that the client will want to have a companion mobile app at some point to make it easier for users to report litter in the field).
- Summary: In order to make the development process easier and add mobile compatibility, we decided to use the ReactJS framework.
- Problem: We have to decide if we want to use a framework, and if so, which framework to use. This is important because a framework could greatly simplify the development process, but it would also force us to commit to that framework.
- Options: Our main options are React (is fast, provides reusable components, and has cross-platform support, but is not well-documented and is constantly being updated), Vue (very lightweight and has reusable components, but has less resources for developers), Angular (creates organized code and uses the MVC and MVVM architectures, but is more difficult to learn), jQuery (is well-known and simple, but is slightly outdated), and not using a framework at all (we’re exposed to less potential vulnerabilities, but we have to write everything ourselves).
- Rationale: We choose to use React because it’s the framework that we are most familiar with and the only one that provides cross-platform support. We also don’t want to spend the limited amount of time that we have on rewriting existing components.
Decision: Website Map API
- Summary: In order to have a scalable and easy-to-use map API, we decided to choose to use Google Maps API.
- Problem: We have to choose an API for the website’s main map. This is important because the map is the centerpiece of the site and the component on which many other features depend.
- Constraints: The map must have typical map functionalities (such as a search bar, drag-to-move, zoom controls, and a way to move to the user’s current location), be fast, and cover the entire world. Additionally, the map must allow for an unlimited number of calls per day.
- Options: Options include MapBox (provides easy-to-customize maps and can easily integrate into web and mobile apps, but is difficult to learn and may be resource-intensive), OpenStreetMap (is completely free and provides detail on less popular locations, but only provides vector data and has limited features), and Google Maps (is very popular, reliable, and has lots of features, but is expensive).
- Rationale: We choose to use the Google Maps API because it is built for scale, provides a familiar UI to users, and has a lot of documentation and tools already built for it.
Decision: Algorithm Data API
- Summary: In order to provide the predictive algorithm with good data to base its prediction off of, we decided to use OpenStreetMap’s location tags.
- Problem: We have to choose the API that the litter prediction function will get data from for its algorithm. This is important because without a good source of data, the predictive algorithm won’t give accurate predictions.
- Constraints: The API must provide basic location data and information that will help us predict whether a location has litter. In addition, the API must contain data for a large number of locations and allow for a large number of calls per day.
- Options: The main options are OpenStreetMap (provides tags of significant locations, but does not have litter information or images), Mapillary (provides photos of streets which have AI-tagged objects, but is limited to roads), OpenLitterMap (provides locations of litter with photos, but has very few data points and is not very active), and Planet Patrol (similar to OpenLitterMap).
- Rationale: We choose to use OpenStreetMap because of the size of its dataset, the availability of data that could immediately be used for prediction (the tags), and its project activity.