QuikSchedule, a scheduling app for UCSD students

QuikSchedule is an scheduling Android application that allows UCSD students to integrate their class schedule with the click of a button and notifies them when to leave for the classes. The user can use the app to route directions from their current location to any event in the day by just clicking on the event notification or the event details. Additionally, if the user does not go to UCSD or would not like to integrate their class schedule, it can be used as a regular scheduling app with the same routing and directions capabilities as before.

My role in this project was to create the user interface and front end design for the application. This included every single thing that was displayed on the app, from the calendar to the displaying of the map. Additionally, it was my job to present our progress and final product to our customers, who were the Teacher Assistants, other students in the class, and the professor.

Methodology: To create an accurate and functioning app within the allotted time of 2 months, our team used the agile development methodology to make sure that we facilitated communication between our team and the customer as well as stayed on deadlines while implementing the correct features. Here is a list of the agile ideals we incorporated into the project:

1. Iterations: We used iteration to outline our development process and account for any loss in time or features, meaning we could still recover from a setback by reiterating on the features that we failed to implement.

2. Burndown Charts: This was essential in keeping track of our progress. The chart documents quantitatively how many features we were getting done in time.

3. User Stories: We used user stories to understand what the customer wanted as the template for user stories demands that we be consistent and through in order to fill it.

Features: We gathered a list of features from our customer in our initial Requirements Gathering phase (See “Requirements Gathering” under “Process”). Here are the most common and critical features we were to implement in user story format:

  • As a user I want to link the application with my UCSD account so that I can access my classes and add them to my schedule to view them
  • As a user I want to be able to connect to Google Maps so that I can see where my events are taking place
  • As a user I want to add custom events to the app so that I can track events that do not show up on my Google Calendar and Webreg and ensure that I plan them into my schedule accordingly
  • As a user I want to be able to map a route to events so that I know the most efficient path
  • As a user I want to be able to show my agenda for the day on opening page so that I can see my entire day laid out before me
  • As a user I want to be able to add an automated notification system for the next event so that I don’t miss my events and can route my way there


1. Requirements Gathering: First, my team and I met with our customers to hash out what requirements and features were needed for the application. This was a key step because it allowed us to narrow down exactly what features needed to be implemented as well as clear up any assumptions we had about what the end-product was supposed to be. Additionally, the requirements gathering phase allowed our team to get familiar with each other and our development style and environments.

2. Project Planning: After we had gathered all the requirement and features, we created user stories that depicted what a user could do on our application. We then broke these stories up into individual tasks that were single units of work, such as the calendar view on our app consisted of the two tasks: creating a tab layout for swiping through days and button that allowed the user to specify what date he or she wanted to go to. Following this, we did estimations of how long each task would take and added them up to the corresponding user story that they were in to calculate the project timeline. Since there were features that could not be created in the 2 month span we were given and there were some features that required to be done first, we prioritize, with our customers in the next meeting, which features we needed to get done first through a rating system. We then inputted this information into Trello, an agile methodology program, so that we could keep track and manage our features electronically. Here we created a burndown chart that would help us track our progress and deadlines:

Burndown Chart for QuikSchedule

3. First Iteration: With our planning phase done, we had to start implementing the features. We first started out with the calendar view feature that allows the user to view their calendar and swipe through days as well as pick a new day:

Calendar View for the user to swipe through the days
Page that allows the user to pick any date

4. Second Iteration:
Our second iteration consisted of scraping the user’s WebReg and pulling the events into a database so that we can access it from the mobile application and throw it onto the display. We also let the user specify whether he or she wanted to let us take their textbook information and include it within the event that will thrown on their calendar. This was done through a Java injection and then pushing those changes into the FireBase database:

5. Third Iteration: Our third iteration consisted of displaying the events we gathered from the user onto the UI. This was accomplished by parsing the phone’s database, where the events where held, and turning them into our own custom EventView objects that holds all the information and displays the key ones on the calendar, such as the event name, time, and place. Then we calculated the event position on the page by taking the start and end times and calculating the time from midnight and the number of minutes the event will take. These two pieces of information were key in creating what the event will look like to the user. The end result looked like this:

User’s events for the day

6. Fourth Iteration: In the fourth iteration we implemented the custom events by creating a form that the user could fill out with information about the event and the transportation mode they would take to get there. This was pretty straightforward as all it required was a number of input forms that is already native to Android development. We also included buttons that we would use later on, such as “Delete” which we will use to delete the event from the user’s calendar.

Event view for creating, editing, and deleting events

7. Fifth Iteration: In our fifth iteration we did the mapping functionality as well as the notifications functionality where the user could swipe on the notification of an event and be taken to the maps. This had many bugs and took the longest iteration, upon which the customer was not satisfied and we had to redo the iteration for more edge cases and specifications.

Users location that could then be used to map to an event

8. SIXTH ITERATION: Our sixth and final iteration consisted of wrapping up the final details of the application. This mainly had to do with edge cases that we found along the way during our testing, such as the login page, deleting events, and creating a settings page so that the user could change the notifications settings or add classes from WebReg if they hadn’t already. This was also the phase where we overhauled the UI so that we got a sleeker design with a black and pink theme and a new cleaner logo.

Login page that welcomes the user to the app and makes them login to Google
Settings page that gives the user options to configure the apps functionality

9. Testing and Documentation: With our product finished in terms of features that needed to be implemented, we started to test the overall application using the inbuilt Android studio framework as well as Robotium scenario-based tests that tested real world progressions through the system. Additionally, this was also where we documented our code with method headers and inline comments so that future developers or even our team can understand what is going on within the code.

10. Final Deliverable: The final step of the project was to deliver and present the product to the customer. This included getting feedback on what was done and how well the product fit what the customers envisioned. After delivering it to them, they were very impressed with the end result and all the features we were able to pack in for them to use. They indicated that we should release it to the public via the Google Play store so that they can use it for the coming quarters.

Challenges: In this project, I encountered many challenges, both with development and working with people.

In terms of design, there was an initial learning curve, as person with backend experience working on UI, in understanding how the UI should be laid out and the best color scheme to go with it. I underestimated the amount of thought that goes into something simple such as picking a theme.

There was also an initial learning curve in understanding the Firebase database and the phone’s database, in addition to all the API’s that go along with it. This is where resources like Stack Overflow came in handy.

Working with people in a group context always poses a problem. Surprisingly, most of the group was motivated and delivered quality work on time. There were instances where people did not do their job, but they always made up for it on the next iteration, for the most part. There were a couple people on our team who did not carry their fair share of work nor did they attempt to, but the rest of us were able to make up for that by teaming up to implement their share of the features.

Conclusion: Overall, this was my favorite project to work on because it allowed me to work with other capable developers in a agile environment as well as hone my Android development skills. I was also able to test my abilities as a leader as I was tasked with presenting the product to the customers as well as making sure that all the features were being implemented in time.