# UofT Faculty of Medicine Application Cost Calculator/TEAM 1

## Product Details

#### Q1: What are you planning to build?

We are improving a website for pre-med students that allows users to obtain a general idea of the total cost they can expect to pay during their med school application process. Many applicants do not realize all of the expenses they will incur until they come up, so this product lets users know ahead of time these additional expenses so students can avoid surprise fees during the application process. The calculator takes into consideration transportation fees, application fees, med school examination fees, prep fees, and so on. Users check off which fees apply to them and the calculator will provide an estimate of the total cost.

The website already exists, and so we will be improving its UI, implementing new features, fixing its architecture, making it customizeable, and making the it easier to maintain and update.

#### Q2: Who are your target users?

There are two target users for the website:
1. Med school applicants: these users can be in any stage of their application journey, from first-year pre med students wanting to get an idea of application costs years in advance, to grads who are currently in the process of applying to med schools, working on their application in July and applying by October. Most of these users will be Canadian students, however students from other countries looking to apply to Canadian med schools will find the service useful as well.

2. Admin leaders who wish to see the cost implications of various services assiciated with applying to Canadian med schools.

#### Q3: Why would your users choose your product? What are they using today to solve their problem/need?

Firstly, there are very few similar products available, and they do not include as much detail as our product does. Secondly, the website includes links to resources related to the different steps of the application process (i.e. interview prep, MCAT prep, etc.), which greatly reduces the time a user would otherwise spend searching for those resources. Lastly, we will be adding functionality that will make the calculator customizeable, allowing users to input their personal exact costs, making the calculator's estimate as close as possible to the real-life cost of applying to med school.

#### Q4: How will you build it?

The website is written in JavaScript with HTML and CSS. React is used on the frontend and the site's data is stored on Firebase. It does not contain any CI/CD processes, so we will be adding devOps capabilities using GitHub Actions, and changes will be automatically deployed to the existing Firebase server.

We will use react-bootstrap as our frontend framework to improve the UI, get access to generic modular components and reduce the amount of CSS styling required to make the page responsive.

The project currently creates specific components separately for each page of the site; we will improve the site's architecture by creating modular components.

We will use the Google maps API for automatically detecting locations and calculating the transportation costs (https://cloud.google.com/maps-platform/maps).

To test our React application, we will use Jest and Mocha, and we will implement snapshot testing to test the UI.

To make frontend development more efficient, we will use storybook: https://storybook.js.org/

#### Q5: What are the user stories that make up the MVP?

- User Story:
As an individual interested in applying to Canadian med school, I want to view an organized list of universities in order to find my desired universities faster.
- Acceptance Criteria:
Must be organized by province.

- User Story:
As an individual interested in applying to Canadian med school, I want to view a more organized application fees page in order to improve user experience.
- Acceptance Criteria:
Elements on the page are more conservative of space.

- User Story:
as an individual interested in applying to Canadian med school, I want be able to input the number of trips i require accommodation for in order to obtain a more realistic transporation cost.
- Acceptance Criteria:
Ablility to multiply the accommodations cost by the number of trips.

- User Story:
As an individual interested in applying to Canadian med school, I want to be able to specify my location in the transportation page in order to get a more realistic transporation calculation.
- Acceptance Criteria:
Transporation costs should be dependent on user location, which is automatically detected but can be manually changed.

- User Story:
As an administrator, I want to have no mentions of external companies in info popovers, in order to avoid promoting specific businesses and instead provide helpful messages.
- Acceptance Criteria:
There is no mention of external companies in any popovers

- User Story:
As an individual interested in applying to Canadian med school, I want to view my essential costs verses my non essential costs, in order to obtain a better understanding of the costs.
- Acceptance Criteria:
There must be some sort of visual indication of what fees got replaced with budget alternitives and display savings on the side.

<!-- - User Story :
As the admin, I would like to be able to see a list of all the users so that I can monitor the usage of the website

Acceptance Criteria:
Must be able to see a list of all users
Must be able to see the total number of users
Must be able to see the name of a user and when they were last active
-->

<!-- - User Story:
As an admin, I would like to select a user so that I can inspect their profile and make corrections if necessary.

Acceptance Criteria:
Must be able to click into the profile of any user
Must be able to change certain aspects of the profile that the user can not -->

- User Story:
As the admin of this website, I would like to have the admin role assigned to me and also have the ability to make other people a moderator to have better control/moderation over the website
- Acceptance Criteria:
Ability to make any user an admin.

- User Story:
As an admin, I would like to update the website to include updated information through the website so that I can keep the website a relevant tool for current students
- Acceptance Criteria:
Must be able to change values through the frontend.
The data must be validated before pushing to the website to verify correctness.

----

## Process Details

#### Q6: What are the roles & responsibilities on the team?

Team Lead *1
- Check in on progress of each member of the team.
- Choose where to coordinate the team's effort.

Client Rep *1
- Communication point between the partner Ike and the team.
- Responsible for deliveringing the questions and discuss the meeting times, as well as updating the team's process with Ike.

Prototype *5
- Responsible for designing the UI/UX of the website via Figma
- Ensures that the product is developed based on the prototype

Frontend *4
- Responsible for improving and adding features to the UI of the project
- Review and merge frontend pull requests
- Create snapshot tests to ensure UI works as expected

Backend *2
- Responsible for improving and adding features to the backend of the project
- Review and merge backend pull requests
- Develop comprehensive tests to ensure backend logic works as expected

DevOps *2
- Responsible for maintaining the CI/CD pipeline
- Investigate any pipeline downtimes

### Gaurav
#### Roles and Responsibilities
- Frontend, Prototype
#### Technical Strengths
- Angular (Typescript, CSS, HTML)
- Firebase
- Python
#### Technical Weaknesses
- Express
- NodeJS
- Redux

### Jenna
#### Roles and Responsibilities
- Frontend, Backend, communicate between frontend and backend, Client Representation, Prototype
#### Technical Strengths
- ReactJS + React Bootstrap
- NodeJS + Express
- MongoDB
#### Technical weaknesses
- Redux
- Firebase

### Killian
#### Roles and Responsibilities
- Team Lead, Backend, Prototype
#### Technical Strengths
- Python
- Git/Github
- Scrum
#### Technical Weaknesses
- Redux
- NodeJS
- NoSQL (Firebase)

### Emily
#### Roles and Responsibilities
- Frontend, Prototype, DevOps
#### Technical Strengths
- Python
- Java
- PostgreSQL
#### Technical Weaknesses
- Redux
- Node.js
- Express

### Sharjeel
#### Roles and Responsibilities
Frontend, Prototype, DevOps
#### Technical Strengths
- React
- Redux
- Javascript
#### Technical Weaknesses
- Express
- Databases
- NodeJS

#### Q7: What operational events will you have as a team?

The team has agreed upon conducting a weekly meeting every saturday for the remainder of the course. We plan to conduct to meetings via Google Hangouts, and take meeting notes on Google Docs.

The purpose of each meeting is for the team to get caught up on in-progress tasks and to stay up-to-date on what each team member is working on. This will also provide an opportunity to know if there any roadblocks that the team should work on resolving, and make sure that no team member is stuck on anything for too long. This will also serve as a testing ground for any team member to present their work and get feedback from the rest of the team about it. The next move on the project will be discussed and tasks will be created for the following week.

Meeting Minutes:
https://docs.google.com/document/d/1-bwik26yhHH4DclnNbnfKUA2xsTEmthOYy8QlbgBY-Y/edit?usp=sharing

##### Meeting May 27th, 2-3pm:
Our project partner Ike walked us through the existing website and explained the process of applying to medical school in Canada. He explained the different reasons a user would choose to use the website and provided some user stories. For each page of the website, he outlined what he would like us to improve; for example, on the page where users select which universities they plan on applying to, Ike asked us to change the order that the universities appear on the screen so that they are grouped by province. We also established a regular weekly meeting time with Ike of Tuesdays at 2pm. The outcome of the meeting is that we understood exactly what is expected of us and how we are expected to improve the website.

##### Meeting June 3rd, 12-12:30pm:
We shared our user stories with Ike and he provided suggestions for improvement. He also suggested we begin with the most time-consuming functionality, which we anticipate will be calculating the transportation costs. This brought up a question about whether changes to the logic of the website can be done at the same time as UI improvements, and we believe that if the code is well-written and separates the backend from the frontend, both can be done in parallel. Ike also reiterated the target users for the site: student applicants at any stage of the application process and admin leaders who wish to see the cost implications of various services. Lastly, we changed our meeting time to every other Tuesday at 12pm to align with everyone's schedule. The outcome of this meeting was a confirmation that the user stories and target users we will be basing the functionality of the site on are aligned with what our project partner envisions, and so we are now ready to begin creating our prototype and improving and adding functionality to the website.

#### Q8: What artifacts will you use to self-organize?

In order to self-organize, we will be utilizing a trello board to practice agile development:
https://trello.com/invite/b/HUbO5IJE/5d0de0e07379a9c1cd3b51a7481b6b1a/uoft-fom-calculator

In order to keep track of what needs to be done, we will be creating tickets for each of the stories on trello.


The tasks will be broken down into smaller parallelizable subtasks and will be assigned to the people from the appropriate teams.

The task are prioritized based on what order they are in, in the todo column. Prioritized tickets are at the top and have a red colour, and less prioritized tickets are below.

During weekly meeting we will divide the tickets and the assigned team member's name gets attached to the bottom of the ticket to indicate the ticket is assigned to them.

To track the status of the work, we have multiple columns the tickets can be dragged into. The columns include To Do, Assigned, In Progress, Blocked, Done. Any ticket that is blocking another ticket should be prioritized. The tickets also have labels on them, indicating the type of task (frontend, backend, DevOp, UX, bug, story).

We also have an Outlook Calendar that we share with our project partner that has all of our meeting times, and we will add deadlines to it as they come up.

#### Q9: What are the rules regarding how your team works?

**Communications:**
At minimum, we will be having a weekly group meeting every Saturday via Google Hangouts. We also have a groupchat on Messenger where we discuss the project as needed, as well as a Slack channel where we communicate with the TA.

We plan to meet with our partner every 2 weeks on Tuesdays at 2pm to discuss the progress that we have made over the past 2 weeks. This meeting will provide the team with the opportunity to showcase our work and get some feedback directly from our partner. We plan to keep our partner involved as much as possible and reaching out to him via email whenever time we have a product-related question.

**Meetings:**
If a team member cannot attend a meeting, they should notify the team atleast 24 hrs before the meeting, if possible. After the meeting, the team member should look at the meeting notes and the other team members will fill them in on what was discussed.

<!-- If a team member cannot complete an item on time, they should notify the group and get help. -->

**Conflict Resolution:**
Non-responsive team members: try to reach out via the methods we have setup (messenger, weekly meeting, etc.), then notify the TA if the team member is still unresponsive.

Indecisions: If at first we cannot come to an agreement, we will continue for a while to discuss the matter until we reach one. If there isn't enough time, we will set up a vote.

Failing to meet deadlines: Check in with the team members not meeting deadlines and offer help. If we see that the workload for a certain role is too much (for example, much more frontend work than anticipated), then we will assign more team members to that role.

----
### Highlights

Specify 3 - 5 key decisions and/or insights that came up during your meetings
and/or collaborative process.

* Short (5 min' read max)
* Decisions can be related to the product and/or the team process.
* Mention which alternatives you were considering.
* Present the arguments for each alternative.
* Explain why the option you decided on makes the most sense for your team/product/users.
* Essentially, we want to understand how (and why) you ended up with your current product and process plan.
* This section is useful for important information regarding your decision making process that may not necessarily fit in other sections.

We have assigned roles to each team member, however we have to decided to stay open to the idea of switching roles as we see fit once we begin working. This is because we do not yet know which areas require the most work. As of now, it appears the project is frontend-heavy, and so we assigned more people to work on the frontend than the backend; however, we may find that the backend tasks are more difficult than anticipated and divert more work there. We were also considering starting out with everyone doing fullstack and then assigning specific roles after we begin working, but we decided against this since we believe our work will be more productive if everyone knows exactly what they should be working on once we begin.

About the frontend, we had to consider how to divide the work; we could either have people only design (looks only) and other do the actual implementation, or we instead have each us do the design and implementation of some specific features. Ultimately we decided that we will first come up together with the new looks/redesign of the website, and then we will be able to divide the features into chunks that can be design and implemented by one person. This the best option for our team since none of us are particularly interested in being solely responsible of the overall look of the website (or even have the skills to do so), furthermore dividing the work between designing and implementing might cause us to block each other, and finally designing the website first will allow us to get feedback quickly from the project owner.