Shop’n’Save
Roope Ilmola, Julian Valdman, Adrian Krepinsky, Ania Szczepaniak
This project was carried out as part of the TechLabs “Digital Shaper Program” in Copenhagen (Spring 2020).
INTRODUCTION
While studying our digital shaper tracks in data science and AI, we put the newly acquired skills into practice by developing a smart grocery shopping app. We are a group of four international students from the fields of business administration, economics, and data science. Most of us had little to no experience in coding before joining TechLabs Copenhagen. Prior to starting off the app development, we learnt the necessary skills using online courses on DataCamp and Udemy.
Nowadays, online price comparison sites are increasing in popularity to find the best price for a product or service. Besides, people are becoming more aware of issues related to sustainability. Our smart grocery shopping app called Shop N Save is aligned with these two trends. We wanted to create an app that helps people to save on their groceries and simultaneously contribute to reducing food waste. According to Too Good To Go, 8% of all greenhouse gas emissions come from food waste. Too Good To Go is a highly popular app that connects users with unsold edible food at restaurants, cafes and hotels. The food that would otherwise be thrown away is sold at a considerable discount. Our app shares a similar idea by letting users find unsold food with discounted prices at grocery stores in Denmark. The user needs to provide their address and a radius within which the grocery store(s) are supposed to be located. Shop N Save then shows food waste products at grocery stores located within the relevant area. Finally, the user can see all available food waste items, their old and discounted prices as well as the location of the grocery stores storing the items in a map. After the user selects what they need, the app creates a shopping list, calculates the total basket price and shows the amount saved compared to paying the normal price of the products.
INTERNAL ORGANIZATION
In order to manage the project, prioritise tasks and monitor the progress, we used Trello as an organization tool. It assisted the team in visualising the several small steps that comprise the bigger picture. Breaking the project into small parts was useful especially as the majority of the team was not very familiar with the programming world beforehand. Trello enabled us to divide the small tasks among the members and further monitor the progress through five different phases: ‘Backlog’, ‘Up next’, ‘Doing’, ‘Testing’ and ‘Done’.
METHOD
During the project phase, different data science techniques were applied such as establishing a connection to an API interface, importing and preparing the data, and building a mechanism that filters the data based on user input parameters. Eventually, we were able to access the API by the Salling Group to which the grocery store chains Netto, Fotex and Bilka belong. The API provides data about food waste products close to expiry, their original and discounted prices, and the stores’ location information. Furthermore, an API for suggested products provides additional product data from a text search. The data is imported and cleaned. Relevant data is extracted and then appended to a global database.
THE DATASET / API
The Excel-database contains, at the moment, more than 23,000 food waste product items with which we filter and serve the user. All of this product data is provided by the Food Waste API from Salling Group. The backend database is updated regularly by the Back Process which is explained later. To extend the functionality and more user services, more APIs are applied. The Store API provides information about all of the stores at Salling Group. For each store, the food waste data is retrieved. The Suggested Products API provides data about other products that may become handy when the user has to decide where and what to shop. These products are shown together with the food waste items. The Location API is used when working with the address that the User enters when interacting with the service. This API is used in converting the input address to more computer-friendly data, like longitude/latitude-format, and finding stores within a radius at a location. All of these three APIs are used in the User Service process which will be explained in the coming section.
INSIDE THE APP / MECHANISM
The project can be divided into two main subprocesses: the Back Process and the User Service. The Back Process regularly updates and extends the product list in the database. This is done by extracting all of the products from the Food Waste API and updating or inserting into the database. This daily or weekly process ensures that the backbone of the service, the food waste products list, is always up to date in terms of quantity, stores, prices, discounts, expiration time and more. The User Service process is activated whenever a user starts a session with the app. Here, the user enters some parameters, like brand or discount preferences, an address and radius. With this, the User Process finds the most relevant products and stores depending on the user data. First, the products located in the entered zip code and belonging to the brand preferences are found and exported to a table. Then all the stores within the entered radius are found. And then, from the filtered list of relevant products, suggested products are found. Even though these are not on discount, they are shown to give the user more opportunities and bigger assortment when shopping. All of this filtered data exported from the User Service, list of relevant food waste products, nearby stores, and suggested products are supposed to be shown to the user.
The two main processes inside the app are shown in the figure below:
HTML / CSS
To show how the personal interaction with the web application itself would look like we published a hardcoded demonstration through github pages. The example is interactive in the meaning that a potential tester can input a zip code and enter a key which is functional from the input field but the result remains the same and no data is pulled by the above described and advanced python. Using HTML and CSS framework we prepared a visual representation of how we would like the application to look like. Classes were assigned to the simple structure of divs and input field so then we could easily reference them in the styles sheet. In styles.css we styled the website, mainly with the use of Flexbox layout, to easily make it responsive and flexible for any size of a browser.
Additionally we applied simple functionality with JavaScript to make a simulation of real user experience. As the functionality is limited the code was not put in the separate .js file, instead it was referenced in the HTML itself, just before the </body> closing tag.
In the example above you can see that we call a DOM element from HTML to add a method for the zip object that would result in the output being shown when the Enter key is pressed (number 13). The finished index.html page where the user is able to look for their desired zip code is shown on the Figure below.
FUTURE IMPROVEMENTS
The idea for the project went through many changes throughout the TechLabs journey due to time and resource constraints. Initially, we wanted to create an app where the user can create a grocery shopping list and based on that list the app would automatically find the relevant products within the relevant area. This would require extensive data grouping to categorize brands and individual items under product categories such as bread. Moreover, the filtering mechanism could be improved by making it only show products that are stored in one store making the actual shopping experience more convenient. This feature was left out due to having limited amount of data and, therefore, us wanting to ensure that the app can provide output for the user regardless of the location of the store.
This project gave us all a valuable opportunity to learn how Python can be utilized to create value from data, how to communicate in data terms and how to work in an interdisciplinary team. We also realized the difficulty of getting access to needed data. In today’s data driven world, we are sure that this experience will benefit us in our future roles.
