Wash U Doing

Project Overview

Wash U Doing is a novel interactive website bringing Washington University students and student groups together. On-campus WUSTL groups will have the opportunity to create events on Wash U Doing, which students can find by easily filtering through their event interests.

Members

• Kristine Ehlinger, Systems Engineering '20
• Dylan Zubata, Systems Engineering, Economics and Strategy '20
• TA: Natalie Ng

Objectives

• Display current and upcoming events posted by WashU organizations
• Display an annotated map, using arcGIS, with locations around WashU main campus
• Allow users to filter through events by specific tags
• Create a database to enter and retrieve data
• Fulfill our goals of bringing together students and students groups on two main pages: an event creation page for data input and a home page for displayed and filtered data

Challenges

• Code using HTML, PHP, and SSH with limited coding experience
• Understand arcGIS software, complete annotations for a map of WUSTL campus, and implement it into our webpage
• Create a live-feed network on our website using a database
• Utilize AWS and its services, phpMyAdmin, PuTTY, and MySQL Workbench to suit the needs of our project
• Make the website user-friendly through set filters
• Assemble code that fulfills our website's purpose with no indication of syntax errors (because of working in PuTTY)

Budget

• arcGIS Map = $0 (Provided by arcGIS)
• Downloads for Notepad++, phpMyAdmin, PuTTY, and MySQL Workbench = $0
• Amazon Web Services Account: $0
• Domain Name Purchase and other AWS services (1 year ownership of the domain and data storage) = $38.88

This charge is largely based on a year's access to AWS and specific tools we access including Route 53, RDS, and the Elastic Compute Cloud. The charge breakdown includes:

  Elastic Compute Cloud- cost changes with usage
      *$0.005 per Elastic IP address not attached to a running instance per hour (prorated)
      *$0.10 per GB-month of General Purpose SSD (gp2) provisioned storage - US East (Northern Virginia)
      *$0.012 per On Demand Linux t2.micro Instance Hour
  RDS Service- cost changes with usage
      *$0.017 per RDS db.t2.micro instance hour (or partial hour) running MySQL
  Route 53- cost changes with usage
      *$0.40 per 1,000,000 queries for the first 1 Billion queries
      *$0.50 per Hosted Zone for the first 25 Hosted Zones
  Registrar
      *Registration of "www.washudoing.com": $12

https://aws.amazon.com/pricing/services/

Gantt Chart

This Gantt Chart reflects the distribution of work since the beginning of our progress on the final project idea.

Design and Solutions

Home Page and Event Creator page:
Both the home page and event creator page were created using HTML code. Our intentions were to make the site as functional, aesthetically pleasing, and user-friendly as possible. We thus included the ArcGIS map on both sides of the site and implemented filters so users could see particularly categorized subjects at the touch of a button. In terms of improving the aesthetic, we made the top bar hoverable and chose a tactful color scheme.
The home page consists of a two-button hoverable top bar where users could transition from the home page to the event creator page; a thirteen-button hoverable top bar where users could click on a particular filter and the site would automatically scroll to the category of one’s choosing; a list of each of the events under their respective alphabetically-ordered categories; and an annotated map highlighting all possible destinations on Danforth campus and the South Forty.
The event creator page consists of a two-button hoverable top bar where users could transition from the event creator page to the home page; a form including details on the name of one’s event, the group that posted it, the date and time of event, description, location (via dropdown menu), and three tags (via dropdown menu); and an annotated map highlighting all possible destinations on Danforth campus and the South Forty.
Our solution to accomplishing this project involved splitting the website into two parts: the front-end (the html code) and the back-end (the PHP code and AWS), and then integrating the two parts together in the last two weeks. When we reevaluated our project at mid-semester, we decided to edit our goals to make sure that we could accomplish our project; this involved how the data was displayed. Instead of a calendar and infinite tags, we had a set list of filters which you could easily navigate. We also encountered many problems in debugging our code. In order to overcome these issues, we used online resources to test our code and consulted with a professional for direction.

ArcGIS:
ArcGIS is an online cloud-based mapping tool that allows users to create and share maps. We annotated a simple map that was zoomed in to Washington University’s campus with all the potential destinations organizations could be holding events. This added to the user-friendliness we intended to provide both for students and organizations. The arcGIS map can be seen on both the home page and the event creator page, and if one clicks on any of the pinpoints, he/she is able to see exactly what location it is hovering over.

AWS:
AWS is an online service that allowed us to create and host our website. We utilized development tools including S3, Route 53, CloudFront, and RDS. In conjunction with PuTTY and LAMP, we followed various tutorials to set up our domain, hosted zone, and IP address that identified our website on the web. From there, we got advice from a professional and created connections across AWS to allow changes to be made to our site and web traffic.

MySQL Workbench:
After creating a test database in phpMyAdmin, we set up our final database in MySQL Workbench. In PuTTY, we connected to our database in order to input and extract the data from our website. By using MySQL Workbench, we could view and edit our database as needed.

PHP:
PHP acts as the intermediate between our website (the front end display) and our server. By creating PHP code, we added the “functionality” to our website; we were able to input data from our website and select specific information from our database. This was especially challenging to create due to the complexity of working with a database; there were no clear instructions or guides to create and edit the PHP code to our specific needs. We accomplished our goals by consulting with a professional and creating the code in pieces such as creating the connection to AWS, creating the connection to our database, forming a general SELECT statement, etc.

March 23rd, 2017:

Results

Our final code has been uploaded to a repository in Github: https://github.com/kristine-ehlinger/ESE205.

Home Page and Event Creator Page:;
The home page and event creator page were fully functional: organizations were able to get to the event creator page, fill out the form, and submit into our database, while students were able to hit filter buttons to jump directly to a filter or scroll through the site to see all events under their particular categories. AWS and our SQL database were set up and connected to our website, and our PHP code worked according to the way we chose to input and display data on the webpage.
Two of the major factors that impeded our results from being ideal were that (1) we struggled at first to find the project of our choosing that was plausible within the given time with our limited knowledge and (2) after losing a group member, we reevaluated the scope of our project midway through the semester.
When we first proposed this project, our ideal vision was for the events to be color-coded by filter and inserted into a calendar. We were able to embed a Google calendar, but were unable to understand how to send events into the calendar automatically and color-code them via filter. Our next best idea was to have the events listed under their respective filters, promoting the user-friendliness we first envisioned. Another idea we were unable to implement was to allow the tags to be unlimited, rather than finite. We envisioned the organizations to have the opportunity to type in filters, and as they were typing the site would suggest filters based on the letters that were entered. Given the limited time constraints and lack of coding knowledge, we came just short of that, but implemented a MUI dropdown menu in its place, finitely limiting our filters to 13 that we felt were all-encompassing.