Application

1. Application Design Decisions While studying the current website, we came to the conclusion that it was overly complicated and did not emphasize the most important parts. For example, the home page is cluttered with text, making it all but impossible to find the tiny button that will take you to the submit a request page. For our application, we decided to focus on user needs and streamline our design to include only the most essential elements. Problem: Residents need a way to conveniently report maintenance problems as they arise Existing Solution: Currently, RSSP has a website where residents can submit maintenance requests when something breaks in the halls; however, the site is not mobile friendly Our Solution: We created a web application that is user friendly on any device and performs the same essential functions as the existing site. Features Challenges • User Authentication through Calnet Login • Ability to Submit Maintenance Requests • Ability to View Status of Maintenance Requests In making this application, we were faced with many challenges that we had to work around and decisions that needed to be made: Problem 1: The IT department was too busy to work with us, so we could not have access to the main databaseWe had a couple options as to how to proceed here. We could either a) Have our app serve as a layer on top of the existing website, automatically entering user-provided information or b) Fire off an email to the Candi (our customer) and her team each time a request is made Solution: After some debate, we eventually decided on the latter because there is a possibility that the current website will soon be redone, thus rendering our service useless. While the email option is not ideal, we wanted our application to last longer. Problem 2: Since we do not have access to the database, we could never be 100% up-to-date with the status of a requestHere again, we had two options: do a lookup on the current website or send an email to Candi’s team and have them inform the user of the current status Solution: We decided to do both. Since users of the current site are accustomed to instant results when they lookup a request status, we decided to scrape the current website for information regarding a given request. Alternatively if a user does not know his work order number, we also display each of a user’s submitted requests with a link that, when pressed, will tell Candi’s team to send the user an update email. This will serve to preserve functionality if/when the current website is ever changed. Lessons Learned • Throughout this project we learned that: • When working with an external customer, you must be flexible and find ways to work around their constraints • Agile programming practices such as pair programming and short iteration cycles are great ways to make a large project seem manageable Group 12: Chris Turney, Frank Yu, Phoebe Simon, Robbie Gleichman