28 | Log-in below using your TDSB Google account.
29 |
30 |
31 |
32 |
38 |
39 |
40 |
41 |
42 |
43 |
44 |
150 |
151 |
166 |
--------------------------------------------------------------------------------
/server/app/main/routes.py:
--------------------------------------------------------------------------------
1 | from app.main import bp # noqa
2 | from bson.objectid import ObjectId
3 | from app.controllers import StudentController, CourseController, TaskController, FileController
4 | from flask import jsonify, abort, request, make_response
5 | from app.database import DB
6 | from gridfs.errors import NoFile
7 | import datetime
8 | import requests
9 | import json
10 | import base64
11 |
12 | @bp.route('/')
13 | def index():
14 | return 'Hello World!'
15 |
16 | @bp.route('/api/students', methods=['POST'])
17 | def post_student():
18 | data = request.get_json()
19 | first_name = data['first_name']
20 | last_name = data['last_name']
21 | email = data['email']
22 | image = data['image']
23 | _id = data['_id']
24 | courses = data['courses']
25 | StudentController.post(first_name, last_name, image, email, _id, courses)
26 | return jsonify("Sucessfully added test student")
27 |
28 | # endpoint to get student detail by id
29 | @bp.route('/api/student/', methods=['GET'])
30 | def get_student(id):
31 | return StudentController.get(id)
32 |
33 | # endpoint to upadte student information by id
34 | @bp.route('/api/student/', methods=['PATCH'])
35 | def update_student(id):
36 | student = DB.find_one("Students", {"_id": id})
37 | sync = request.args.get('sync')
38 | if student and sync and sync == 'true':
39 | last_sync_date = datetime.datetime.utcnow()
40 | DB.update("Students", {"_id": id}, { "$set": {"last_sync_date": last_sync_date}})
41 | return jsonify("Successfully upadted the student information")
42 |
43 | return jsonify("No student matching given id")
44 |
45 | # calls external dictionary API for given word
46 | @bp.route('/api/dictionary', methods=['GET'])
47 | def get_dict():
48 | word = request.args.get('word')
49 | dict_url = 'https://googledictionaryapi.eu-gb.mybluemix.net/?define=' + word
50 | result = requests.get(dict_url)
51 | return result.text
52 |
53 | # upload files
54 | @bp.route('/api/file/upload', methods=['POST'])
55 | def post_file():
56 | files = request.files.getlist('file')
57 | return FileController.upload_files(files)
58 |
59 | # get files by id
60 | @bp.route('/api/file/retrieve', methods=['GET'])
61 | def retrieve_file():
62 | file_id = request.args.get('id')
63 | try:
64 | file_result = FileController.get_file(file_id)
65 | response = make_response({"filedata": base64.b64encode(file_result.read()).decode("utf-8"), "filename": file_result.filename})
66 | return response
67 | except NoFile:
68 | abort(404)
69 |
70 | # endpoint to create a task
71 | @bp.route('/api/task', methods=['POST'])
72 | def post_task():
73 | data = request.get_json(silent=True)
74 | title = data['title']
75 | date = data['date'] # should be in the form of "08 Nov 2019"
76 | time = data['time'] # should be in the form of "12:00 PM"
77 | course = data['course']
78 | description = data['description']
79 | student = data['student'] # student id
80 | attachments = data['attachments'] # a list of uploaded file returned by the upload api
81 |
82 | grade = 0
83 | progress = 0
84 |
85 | deadline = TaskController.create_date(date, time)
86 |
87 | result = TaskController.post(title, deadline, course, description, attachments, student, grade, progress)
88 |
89 | return result
90 |
91 | # endpoint to get a task by id
92 | @bp.route('/api/task/', methods=['GET'])
93 | def get_task(id):
94 | return TaskController.get(id)
95 |
96 | # endpoint to delete a task by id
97 | @bp.route('/api/task/', methods=['DELETE'])
98 | def delete_task(id):
99 | return TaskController.delete(id)
100 |
101 | #endpoint to update task by id
102 | @bp.route('/api/task/', methods=['PATCH'])
103 | def update_task(id):
104 | data = request.get_json()
105 | print(data)
106 | title = data['title']
107 | date = data['date']
108 | time = data['time']
109 | course_id = data['course_id']
110 | description = data['description']
111 | attachments = data['attachments']
112 |
113 | if ('grade' and 'progress' in data):
114 | grade = data['grade']
115 | progress = data['progress']
116 | result = TaskController.update(title, date, time, course_id, description, attachments, id, grade, progress)
117 | else:
118 | result = TaskController.update_without_progress(title, date, time, course_id, description, attachments, id)
119 |
120 | return result
121 |
122 | # endpoint to get all tasks for a student
123 | @bp.route('/api/task/student', methods=['GET'])
124 | def get_task_by_student():
125 | student_id = request.args.get('id')
126 | return TaskController.get_by_student(student_id)
127 |
128 | # endpoint to get all tasks for a student for a specific course
129 | @bp.route('/api/task/student/course', methods=['GET'])
130 | def get_task_for_student_and_course():
131 | student = request.args.get('student')
132 | course = request.args.get('course')
133 | return TaskController.get_by_student_and_course(student,course)
134 |
--------------------------------------------------------------------------------
/deliverables/iteration-03.final.md:
--------------------------------------------------------------------------------
1 | # Team 12 Final Iteration
2 |
3 | ## Final Iteration
4 |
5 | * Start date: Monday, Nov 18th
6 | * End date: Monday, Dec 2nd
7 |
8 | ### Changes from you `product.md`
9 | List the most significant changes you made to your product (if any). It's normal to change features mid-project or reduce the scope to meet timelines.
10 |
11 | * Start with the most significant change
12 | * Identify either a change in features or a reduction of your original scope
13 | * For each change, explain why you are making it and what you are hoping to achieve from it
14 |
15 | > *Note:* If you are not making (or haven't made) any changes to your product, it means you successfully scoped, planned and executed the development of your application.This is a very rare occurrence - describe what you believed enabled your team to do so and why.
16 | > -->
17 | 1. The most significant reduction that we did was not include a chat system for this application. We initially thought that we would develop the chat system by this iteration, but then we were unable to foresee the amount of time and effort that is needed to develop a well-rounded chat system that was secure, well-designed and distributed across all users. Since our project partner was not there to provide feedback and explain what the exact requirements of the chat system were, we were left with very vague details. We were unsure of how to proceed and that hindered our progress. Therefore, we decided to focus more on the other features and improve their quality, since we had a better idea of them.
18 | 2. The other significant change that we did was re-design how students organize their tasks. At first, we were told to create an image gallery for each user to store pictures of their assignments/tasks. However, as we proceeded to make the application, we realized that the choice was redundant and that each user should be able to attach specific image files to a task instead of going to a separate gallery to upload images. Since we did not receive a response from our project partner regarding the change, we decided to pursue it as it not only made the application much more cohesive but it was also more user-friendly. It allowed the user to individualize their tasks in order to organize better.
19 |
20 | ### Handoff Plan
21 |
22 |
28 |
29 | Our team was in the unique circumstance of having an absentee project partner that did not reciprocate communication with the team after the first week of November. Due to this unfortunate situation, we were forced to work with the initial project proposal that was submitted by TDSB, and the information garnered during the project partner meetings we had upto the last time we communicated via email. This resulted in the team taking the majority, if not all, of the crucial decisions without being able to confirm whether or not it was in-line with the project partner's vision.
30 |
31 | We continued with decisions regarding the initial mockups which we attempted to confirm with the partner, and moved with what we decided to be the most user friendly and in-line with core UX design principles. We then came up with the plans for the sprints and promptly completed the front-end in VueJs, the back-end in Flask, and the databases in MongoDB. The trello of our sprint decisions and team management as well as task assignments can be found at our Trello at https://trello.com/b/68RfNTky/term-project. The codebase was committed at equally frequent development intervals to our team's github repository at https://github.com/csc301-fall-2019/team-project-tdsb-team-2. To ensure we had a presentable demo and that our application was usable, we deployed a build of it to heroku at https://tdsb-app.herokuapp.com/. As our project partner has nor replied to set up any meetings for a potential handoff we are currently not able to perform a project handoff of these artifacts.
32 |
33 | Our team has taken steps to ensure that the application is easily scalable and maintainable. We have followed modularity techniques as shown in lecture as well as microservice based architecture. This makes sure that any new features and functionalities may be added to the application with ease. We also modularized many components of the front-end to ensure reusability and maintainability. As our project partner seemed very non-technical and as it was made known that the application would not be able to be maintained by very technically savvy developers, we made sure to incorporate sufficient amounts of documentation to enable readability of the different code we added during development. We hope that if any potential project partner or team wishes to continue working on this, they will be able to do so with ease and get familiar with the codebase in as little time as possible and be able to start making meaningful changes right away.
34 |
35 |
36 |
37 |
--------------------------------------------------------------------------------
/front-end/src/components/home/home.vue:
--------------------------------------------------------------------------------
1 |
2 |
71 |
72 |
73 |
157 |
158 |
183 |
--------------------------------------------------------------------------------
/deliverables/README.md:
--------------------------------------------------------------------------------
1 | # Team 12 - TDSB Application
2 |
3 |
4 |
5 | ## Description
6 |
9 | Our application allows Toronto School Board District students to manage all of their school work and to use various tools aimed to improve their school performance.
10 |
11 | Students can create 'tasks' which are added to their calendars; tasks can range from any simple chore, to assignments and exams. Creating such tasks allows students to easily see and manage all of their various workload. Tasks have deadlines and are conveniently inserted into their Google Calendar so that it is organized and easily accessible.
12 |
13 | Students can also keep track of their performance in multiple ways. For one, they can keep track of all of their grades by inputting their assignment and exam results into the app. Students can also set weights to every assignment and exam and see their current average grade for any course. Most importantly, students can get truly useful insight about their performance by using the 'Graphing' tool of our app, which showcases their grades and tasks completion over time for a course, which is a great way to gauge how well they're keeping up with the material and whether they should adjust the amount of effort they should be putting into said course.
14 |
15 | There are many problems this app is trying to solve. For one, there is a lack of planning features available in TDSB's current system as the current system doesn't allow students to view and plan their work in a comprehensive and exhaustive manner, which leaves gaps in the planning process and can hinder students' success. Additionally, students currently have no way to easily see their performance and evaluate themselves, which TDSB considers vital for its students. Lastly, TDSB's current system relies entirely on a third party, so TDSB would like to have their own platform for more flexibility and control over the system, effectively allowing them to tailor the system for their students.
16 |
17 |
18 | ## Key Features
19 |
21 |
22 | * **Log In** [User authentication, database structure and front-end completed]
23 | A user must login first before they can access the features on the website.
24 | * They login with their Google Account and are validated through OAuth.
25 | * Once they login, an account is setup for them for the application.
26 |
27 | * **Home Screen** [Front-end completed]
28 | Users can see a general overview of their school work on the home page.
29 | * There is a section where users can see all the tasks they have due today.
30 | * There is also a feed section where they can see recent updates to their courses.
31 | * A small monthly calendar is there for them to see dates when tasks are due.
32 | * Users can also view a section for a summary of their tasks due this week and how far along completed they are.
33 |
34 | * **Tasks** [Front-end completed]
35 | For this feature, users can view all their tasks. They can also add, modify or delete their tasks.
36 | * They can view their tasks in both a calendar (month, week, day) or list format.
37 | * When they click add a task, they can enter the title, select a due date with a date-picker, select a course, write a description and upload attachments for it.
38 | * Users can view their tasks from their Google Calendar on this page.
39 | * Users can also search and filter through their tasks.
40 | * There is a section for them to conveniently see all the tasks that are due soon.
41 | * On the same page, there is also a section for them to see all the classes they are currently taking.
42 |
43 | * **Graphing** [Not completed for this iteration]
44 | The application will allow the users to see their progress in a visual format.
45 | * **Dictionary/Thesaurus** [Not completed for this iteration]
46 | Users will be able to access a dictionary from the application to assist them with their homework.
47 |
48 | ## Instructions
49 | The fully deployed application on Heroku for this iteration can be found here: https://tdsb-app.herokuapp.com/
50 |
54 |
55 | - Students from TDSB have their school accounts linked to Gmail so they directly log and get authenticated with Google. Sample account for testing is tdsb301@gmail.com with password csc301csc301. [Completed]
56 | - Once they log in, the home page will show a brief overview of assessments with due dates and their self inputted completion on each assessment. [Completed]
57 | - They will be able to see detailed information on each of their courses in the courses page (details include teacher, coursework, grades and ongoing assignments). [Not completed for this iteration]
58 | - In the Tasks page, they will be able to see a detailed calendar showing when tasks are due. Tasks are assesment deadlines from Google Classroom and self inputted objectives for completion. Students chunk their assesments into mini tasks themselves, manually set a deadline for it and are given notification reminders (email and in app) on these tasks.
59 | - Also in the Tasks page, students can click the AddTask button to add a new task. They can input the title, description and other related factors to the task. [Front-end completed]
60 | - The next option in the navigation bar is Progress. In this section, the student can get an overview on their grades and task completion overtime to track progress. [Not completed for this iteration]
61 | - The next option is the Tools page. As a significant of homework relies on using the dictionary for these students, they will have access to a TDSB approved dictionary.
62 | - In the Profile page (accessed from the drop-down menu on the very right), they are able to see and edit their information, such as timezone settings, password reset, etc. [Not completed for this iteration]
63 | - They can sign-out in the Profile drop-down menu to exit the application. [Completed]
64 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # TDSB Homework Management System
2 |
3 |
4 |
5 | ## Description
6 |
9 | Our application allows Toronto School Board District students to manage all of their school work and to use various tools aimed to improve their school performance.
10 |
11 | Students can create 'tasks' which are added to their calendars; tasks can range from any simple chore, to assignments and exams. Creating such tasks allows students to easily see and manage all of their various workload. Tasks have deadlines and are conveniently inserted into their Google Calendar so that it is organized and easily accessible.
12 |
13 | Students can also keep track of their performance in multiple ways. For one, they can keep track of all of their grades by inputting their assignment and exam results into the app. Students can also set weights to every assignment and exam and see their current average grade for any course. Most importantly, students can get truly useful insight about their performance by using the 'Graphing' tool of our app, which showcases their grades and tasks completion over time for a course, which is a great way to gauge how well they're keeping up with the material and whether they should adjust the amount of effort they should be putting into said course.
14 |
15 | There are many problems this app is trying to solve. For one, there is a lack of planning features available in TDSB's current system as the current system doesn't allow students to view and plan their work in a comprehensive and exhaustive manner, which leaves gaps in the planning process and can hinder students' success. Additionally, students currently have no way to easily see their performance and evaluate themselves, which TDSB considers vital for its students. Lastly, TDSB's current system relies entirely on a third party, so TDSB would like to have their own platform for more flexibility and control over the system, effectively allowing them to tailor the system for their students.
16 |
17 | ## Key Features
18 |
20 |
21 | * Log In
22 | - Upon entering the application, a user must log-in before they can access the features on the website.
23 | - Since the whole application is based on Google services such as Google Calendar and Google Classroom, they need to log-in with their Google account and then they are validated through OAuth.
24 | - Once they login, an account is setup for them in the database, and they are ready to use the application.
25 | * Home Screen
26 | - The first page is the home page which contains a general overview of their school work.
27 | - The navigation bar contains five hyperlinks to different sections of the application (Home, Courses, Tasks, Progress and Tools).
28 | - The drop-down menu on the right side is an account-specific menu which contains the option to log-out and also to view the current account settings.
29 | - There is a "Today" window which contains all the tasks and assignments that are due today.
30 | - There is a Feed window which contains all the recent activities of the user (i.e. addition of a new task, progress update, etc).
31 | - There is a Calendar window where the users can see all the tasks and assignments displayed according to their deadlines.
32 | * Courses
33 | - The user can see an overview of the courses that they are currently enrolled in this semester. Each course has specific information attached such as the instructor, the grades, and other metadata.
34 | * Tasks
35 | - This page enables the user to add tasks, delete tasks and view all tasks that are both uncompleted or completed.
36 | - When they click add a task, they are taken to a pop-up modal where they can enter the title, select a due date with a date-picker, select a course, write a description and upload attachments for the task. The task is then added to the list of tasks.
37 | - There is a calendar window where they can see all the current tasks sorted by their deadlines in month/week/day or list format. All the tasks either added manually or retrieved from Google Calendar are displayed here.
38 | - Users can also search and filter through their tasks.
39 | - There is a window for them to conveniently see all the tasks that are due soon.
40 | * Progress
41 | - The application will allow the users to see their progress in a visual format.
42 | - For each course, the user can self-input the main assignments and the deadlines. For each assignment, they can input the current completion percentage if uncompleted or the grade if it is completed.
43 | - The result is a graph which shows the user's progress over time as well as the averages in all the courses obtained from the main assignments.
44 | * Tools
45 | - Users will be able to access a dictionary from the application to assist them with their homework.
46 | - Other tools can be added to the tools page if necessary.
47 | * Account Settings
48 | - The account settings displays the current configuration of the user's profile. They can edit their settings if applicable.
49 |
50 | ## Instructions
51 |
52 | * Users can log in the website by clicking the button on the login page where the app starts. It requires a pre-created Google account (We are using Google account because TDSB is using Google account). After login user will be directed to the homescreen. If users want to logout they can click the icon on the top right corner and click sign out. For user profile click the "Profile" above the "Sign out". Users can also use the Google account "tdsb301@gmail.com" with password "csc301csc301" to log in and experience the app, the account has a few courses enrolled in the google classroom for demonstration purposes.
53 | * On the homescreen users can view their tasks and assignments that due today and also recent activities. A calendar is shown in the right and users can switch the month using the two buttons on it. Activity information is shown on the calendar
54 | * Users can go to the course page by clicking "course" on the top navigation bar. Information about all enrolled courses will be displayed on the page.
55 | * Users can go to the task page by clicking "Task" on the top navigation bar. The "Due soon" window on the right shows all upcoming tasks with a close deadline. Users can interact with the calendar on the left. By clicking "Sync with Google" button users can retrieve all tasks from their google calendar. In order to add more tasks, users can click the "Add Task" button on the top right corner of the calendar. Then they can input task information in the pop-up window then submit it to create a new task. All tasks can be displayed in both calendar and list views, users can choose the way they prefer by clicking the "month/list" switch button. To change the month use the pair of "<"">" button on the left. Also the "today" button is used to highlight all tasks due today.
56 | * Users can go to the progress page by clicking "Progress" on the top navigation bar. The page shows their progress in assignments and tasks by using graphs. For showing the progress for a specific course, use the selector on the right. After a course is chosen, click the "Assignment" button for adding and editing assignments. For adding assignments, click "Add assignment" and input assignment information in the pop-up window then submit. Use the edit and delete button for each assignment to make changes. For showing the grade of each assignment, click "Grades" and input the grades.
57 | * Clicking "Tools" on the top navigation bar for additional tools like dictionaries.
58 | ## Development requirements
59 |
61 | The application is deployed on https://tdsb-app.herokuapp.com/. If the developer wants to run and revise the source code, then the following steps are necessary:
62 | ### Technical Requirements
63 | - Languages: Python (3.0+) and JavaScript
64 | - Frameworks: Flask, Vue.js, Bootstrap
65 | ### Running the Application
66 |
67 | git clone https://github.com/csc301-fall-2019/team-project-tdsb-team-2.git`
68 |
69 | * Front End
70 | - `cd front-end` to access front-end elements
71 | - `npm install` to install front-end dependencies
72 | - `npm run serve` to start the front-end on `http://localhost:8080/`
73 | * Server
74 | - `cd server` to access the server folder
75 | - `pip install -r requirements.txt` to install back-end dependencies
76 | - `python -m venv .venv` to initialize a virtual machine
77 | - `export FLASK_APP=app.run.py` to set app.run.py as the entry point
78 | - `python -m flask run` to start the server
79 |
80 |
81 |
82 |
83 | ## Licenses
84 |
85 |
90 | We decided to apply an MIT license to our codebase, which would most likely not affect the development of our code, but it does allow anyone to use or contribute to the code, so maybe we will see some pull-requests on our repository!
91 |
--------------------------------------------------------------------------------
/deliverables/README.final.md:
--------------------------------------------------------------------------------
1 | # TDSB Homework Management System README
2 |
3 |
4 |
5 | ## Description
6 |
9 | Our application allows Toronto School Board District students to manage all of their school work and to use various tools aimed to improve their school performance.
10 |
11 | Students can create 'tasks' which are added to their calendars; tasks can range from any simple chore, to assignments and exams. Creating such tasks allows students to easily see and manage all of their various workload. Tasks have deadlines and are conveniently inserted into their Google Calendar so that it is organized and easily accessible.
12 |
13 | Students can also keep track of their performance in multiple ways. For one, they can keep track of all of their grades by inputting their assignment and exam results into the app. Students can also set weights to every assignment and exam and see their current average grade for any course. Most importantly, students can get truly useful insight about their performance by using the 'Graphing' tool of our app, which showcases their grades and tasks completion over time for a course, which is a great way to gauge how well they're keeping up with the material and whether they should adjust the amount of effort they should be putting into said course.
14 |
15 | There are many problems this app is trying to solve. For one, there is a lack of planning features available in TDSB's current system as the current system doesn't allow students to view and plan their work in a comprehensive and exhaustive manner, which leaves gaps in the planning process and can hinder students' success. Additionally, students currently have no way to easily see their performance and evaluate themselves, which TDSB considers vital for its students. Lastly, TDSB's current system relies entirely on a third party, so TDSB would like to have their own platform for more flexibility and control over the system, effectively allowing them to tailor the system for their students.
16 |
17 | ## Key Features
18 |
20 |
21 | * Log In
22 | - Upon entering the application, a user must log-in before they can access the features on the website.
23 | - Since the whole application is based on Google services such as Google Calendar and Google Classroom, they need to log-in with their Google account and then they are validated through OAuth.
24 | - Once they login, an account is setup for them in the database, and they are ready to use the application.
25 | * Home Screen
26 | - The first page is the home page which contains a general overview of their school work.
27 | - The navigation bar contains five hyperlinks to different sections of the application (Home, Courses, Tasks, Progress and Tools).
28 | - The drop-down menu on the right side is an account-specific menu which contains the option to log-out and also to view the current account settings.
29 | - There is a "Today" window which contains all the tasks and assignments that are due today.
30 | - There is a Feed window which contains all the recent activities of the user (i.e. addition of a new task, progress update, etc).
31 | - There is a Calendar window where the users can see all the tasks and assignments displayed according to their deadlines.
32 | * Courses
33 | - The user can see an overview of the courses that they are currently enrolled in this semester. Each course has specific information attached such as the instructor, the grades, and other metadata.
34 | * Tasks
35 | - This page enables the user to add tasks, delete tasks and view all tasks that are both uncompleted or completed.
36 | - When they click add a task, they are taken to a pop-up modal where they can enter the title, select a due date with a date-picker, select a course, write a description and upload attachments for the task. The task is then added to the list of tasks.
37 | - There is a calendar window where they can see all the current tasks sorted by their deadlines in month/week/day or list format. All the tasks either added manually or retrieved from Google Calendar are displayed here.
38 | - Users can also search and filter through their tasks.
39 | - There is a window for them to conveniently see all the tasks that are due soon.
40 | * Progress
41 | - The application will allow the users to see their progress in a visual format.
42 | - For each course, the user can self-input the main assignments and the deadlines. For each assignment, they can input the current completion percentage if uncompleted or the grade if it is completed.
43 | - The result is a graph which shows the user's progress over time as well as the averages in all the courses obtained from the main assignments.
44 | * Tools
45 | - Users will be able to access a dictionary from the application to assist them with their homework.
46 | - Other tools can be added to the tools page if necessary.
47 | * Account Settings
48 | - The account settings displays the current configuration of the user's profile. They can edit their settings if applicable.
49 |
50 | ## Instructions
51 |
52 | * Users can log in the website by clicking the button on the login page where the app starts. It requires a pre-created Google account (We are using Google account because TDSB is using Google account). After login user will be directed to the homescreen. If users want to logout they can click the icon on the top right corner and click sign out. For user profile click the "Profile" above the "Sign out". Users can also use the Google account "tdsb301@gmail.com" with password "csc301csc301" to log in and experience the app, the account has a few courses enrolled in the google classroom for demonstration purposes.
53 | * On the homescreen users can view their tasks and assignments that due today and also recent activities. A calendar is shown in the right and users can switch the month using the two buttons on it. Activity information is shown on the calendar
54 | * Users can go to the course page by clicking "course" on the top navigation bar. Information about all enrolled courses will be displayed on the page.
55 | * Users can go to the task page by clicking "Task" on the top navigation bar. The "Due soon" window on the right shows all upcoming tasks with a close deadline. Users can interact with the calendar on the left. By clicking "Sync with Google" button users can retrieve all tasks from their google calendar. In order to add more tasks, users can click the "Add Task" button on the top right corner of the calendar. Then they can input task information in the pop-up window then submit it to create a new task. All tasks can be displayed in both calendar and list views, users can choose the way they prefer by clicking the "month/list" switch button. To change the month use the pair of "<"">" button on the left. Also the "today" button is used to highlight all tasks due today.
56 | * Users can go to the progress page by clicking "Progress" on the top navigation bar. The page shows their progress in assignments and tasks by using graphs. For showing the progress for a specific course, use the selector on the right. After a course is chosen, click the "Assignment" button for adding and editing assignments. For adding assignments, click "Add assignment" and input assignment information in the pop-up window then submit. Use the edit and delete button for each assignment to make changes. For showing the grade of each assignment, click "Grades" and input the grades.
57 | * Clicking "Tools" on the top navigation bar for additional tools like dictionaries.
58 | ## Development requirements
59 |
61 | The application is deployed on https://tdsb-app.herokuapp.com/. If the developer wants to run and revise the source code, then the following steps are necessary:
62 | ### Technical Requirements
63 | - Languages: Python (3.0+) and JavaScript
64 | - Frameworks: Flask, Vue.js, Bootstrap
65 | ### Running the Application
66 |
67 | git clone https://github.com/csc301-fall-2019/team-project-tdsb-team-2.git`
68 |
69 | * Front End
70 | - `cd front-end` to access front-end elements
71 | - `npm install` to install front-end dependencies
72 | - `npm run serve` to start the front-end on `http://localhost:8080/`
73 | * Server
74 | - `cd server` to access the server folder
75 | - `pip install -r requirements.txt` to install back-end dependencies
76 | - `python -m venv .venv` to initialize a virtual machine
77 | - `export FLASK_APP=app.run.py` to set app.run.py as the entry point
78 | - `python -m flask run` to start the server
79 |
80 |
81 |
82 |
83 | ## Licenses
84 |
85 |
90 | We decided to apply an MIT license to our codebase, which would most likely not affect the development of our code, but it does allow anyone to use or contribute to the code, so maybe we will see some pull-requests on our repository!
91 | Unfortunately, our partner has become unresponsive, so we couldn't demo our app to them, let alone determine what license would best tailor their needs. However, it would be a shame for our efforts to go to waste, so we decided to simply make the code open-source and available for all since there is nothing proprietary in our code, but many cool and useful features. Another reason why the MIT license is a suitable option is its "as-is" approach, which wouldn't hold us accountable for any possible bugs or mistakes in our code.
92 |
--------------------------------------------------------------------------------
/front-end/src/components/progress/progress.vue:
--------------------------------------------------------------------------------
1 |
2 |
111 |
112 |
113 |
311 |
--------------------------------------------------------------------------------
/deliverables/iteration-02.review.md:
--------------------------------------------------------------------------------
1 | # Team 12, Deliverable 2 - Part 2
2 |
3 |
6 |
7 |
8 | ## Iteration 02 - Review & Retrospect
9 |
10 | * When: Saturday, November 9th
11 | * Where: Online
12 |
13 | ## Process - Reflection
14 |
15 | Beginning with the mockups, we have implemented the basic design and highest priority features of the front-end as well as set up the basic back-end, as well as the databases. We have added integration with the Google APIs as well included an interface which will allow users to log in with their TDSB accounts.
16 |
17 | #### Decisions that turned out well
18 |
19 |
26 |
27 | - Our decision to do the mockups and front end initially at the beginning of the project helped to pave the way for the design and tasks of the overall application. We had a very good general idea of what the different functionalities would look like and how we would go about implementing them. The mockups could be found here: https://trello.com/c/x8RTRyLu/7-ux-mockups-prototype
28 | - We split the team up into different development groups, dealing with the front-end, back-end, databases, mockups, etc. Having teams specifically focusing on the different areas ensured that the same task was not being done by multiple people, and that people could shoulder responsibility and that motivated everyone to contribute. This also made sure that no redundant work was being done, resulting in an efficient development process.
29 | - The trello proved to be a more concrete form of task tracking and management than just discussing and assigning tasks in the Facebook group chat. We also used it as a reference hub for all the decisions made and the features requested by the project partner. This allowed group members to quickly find references to mockups and links to external sites and resources which they found useful and were able to leverage in completing the deliverable. The entire trello taskboard can be found here: https://trello.com/b/68RfNTky/term-project
30 |
31 | #### Decisions that did not turn out as well as we hoped
32 |
33 |
38 | - The project partner was absent throughout the majority of the development process. She was not responsive to emails to set up meetings, validate our updated user stories and acceptance criteria, conduct user interviews and select mockups, and attend a demo. Therefore, we could not interact with the intended userbase (students from middle to high school) as well as we had hoped. This resulted in us having to make many decisions ourselves on how we would approach the project requrements, and much of how the end product will look like. We, however, still attempted to follow the requirements set forth initially to the best of our abilities and always factored them in to our development plan and decisions.
39 | - We initially attempted to allow users to create their own accounts in the product. However, this was not necessary as the students had their own TDSB accounts (Gmail) that they could use to log in to the application. Therefore, all that was needed is a sign-in redirection that led to the Google sign-in page. Thus, this resulted in some redundant work which we were fortunately able to turn around quickly after reviewing the requested requirements. Log-in with Google can be found in the github repository ( https://github.com/csc301-fall-2019/team-project-tdsb-team-2), under `/commit/76f741178bfc115caae711d8f15a12a937ae95b2`.
40 | - We also attempted to incorporate branching for different features into our development process. However, more often than not, we ended up committing to master which did not follow the suggested development practices from the course. As members ended up working on very separate aspects of the application, we ended up not needing to branch for every feature since there were almost always no conflicts.
41 |
42 |
43 | #### Planned changes
44 |
45 |
49 |
50 | - Our application deployment plan was changed to be done in Heroku. We still utilized the docker image which helped in the deployment process. It proved to also be beneficial as the change allowed for a much simpler deployment with easily updateable builds.
51 | - As we were not able to get in contact with the project partner to obtain some test Google Classrooms and test student accounts, the majority of the development was done with mock data created by us to simulate real student accounts, Google Classrooms, and Google Calendars. This helped substantially to make the data we were working with concrete so we could move on with the development process rather than having to wait for any data. This also allowed us to simultaneously develop front and back end components of our application while following a specified JSON contract.
52 |
53 |
54 | ## Product - Review
55 |
56 | #### Goals and/or tasks that were met/completed:
57 |
58 | Overview of Tasks can be found on Trello: https://trello.com/invite/b/68RfNTky/7bf7c72f2b6a52990927cfb8dc48d44c/term-project
59 |
60 |
63 |
64 | 1. **Server and Database Set-Up (Priority: High)**
65 | Assigned to Anirudh Baskar, Alex Shang and Samin Khan
66 | * Initialize Flask app to run a server on localhost (for now)
67 | * Initialize an instance of MondoDB with the necessary URI and create static methods to control data (insert and modify)
68 |
69 | Proof (Github: https://github.com/csc301-fall-2019/team-project-tdsb-team-2):
70 | * Initial server set up: `/commit/21917a160e30ce10abc465ca4ca74a80c707b64e`
71 |
72 |
73 | 2. **Basic Front-End Set-Up (Priority: High)**
74 | Assigned to Raiyan Rahman
75 | * Integrate basic Vue.js template to include the main window, navigation bar, account menu and background.
76 |
77 | Proof (Github: https://github.com/csc301-fall-2019/team-project-tdsb-team-2):
78 | * Preliminary front-end files: `/commit/d840b2541c1e8b0bc163df448caa19dab114dc8b`
79 |
80 | 3. **Home-Screen (Priority: High)**
81 | Assigned to Raiyan Rahman, Gazi Jarin, Anusha Fazal
82 | * Replicate basic mock-up of home screen to create a static webpage.
83 | * Features include: static toolbar (Home, Profile, ourses, Tasks, Gallery, Tools), overview window to store recent activity, side calendar and task-list.
84 |
85 | Proof (Github: https://github.com/csc301-fall-2019/team-project-tdsb-team-2):
86 | * Static background: `/commit/d840b2541c1e8b0bc163df448caa19dab114dc8b`
87 | * Fixed navigation bar: `/commit/2a8a97cba1c4c57a0353073b8fe6174c610ad8ba`
88 | * Home-page elements: `/commit/702e4316eb77131cec3e0b5f8dc5483bf53ccdd4`
89 | * Tasks page: `/commit/2cf447366c86b610f7946e92f037b6ee5c9723e5`
90 | * Search bar and addTask button: `/commit/5d75025d52fae3132b46ec7e7e066be0517f1fc3`
91 | * Icons: `/commit/2c3dbc76093497de865cbca7d1984faf175940b6`
92 |
93 | 
94 |
95 |
96 |
97 |
98 | 4. **Log-in and Registration (Priority: High)**
99 | Assigned to Anirudh Baskar, Alex Shang, Samin Khan, and Michael Katilevsky
100 | * Replicate basic mock-up of log-in to create a static webpage.
101 | * Features include: form input (name, password) and the ability to log-in with a Google account.
102 | * Create APIs to insert, modify and update student information such as courses, name, and user id.
103 |
104 | Proof (Github: https://github.com/csc301-fall-2019/team-project-tdsb-team-2):
105 | * Log-in page: `/commit/76f741178bfc115caae711d8f15a12a937ae95b2`
106 | * Log-in with Google: `/commit/76f741178bfc115caae711d8f15a12a937ae95b2`
107 |
108 | 
109 |
110 |
111 |
112 |
113 |
114 | 5. **AddTask Screen (Priority: Medium)**
115 | Assigned to Gazi Jarin, Raiyan Rahman
116 | * Replicate basic mock-up of addTask to create a static modal using Bootstrap elements (b-button and b-modal) in the Tasks page.
117 | * Features include: form input (title), date and time picker, description text editor box, and attachment box.
118 |
119 | Proof (Github: https://github.com/csc301-fall-2019/team-project-tdsb-team-2):
120 | * Title, description, course selection, date and time picker, attachment: `/commit/a7efd2b6e29c5d3c57f2804709fa3d7bb2728a11`
121 | * Implemented full modality of AddTask: `/commit/5bb000e28db0def8ab4bd0321a5f84123e83ed1e`
122 | * Edited time picker: `/commit/4d69037fac314036fe9e652723de040818d6cd4b`
123 |
124 | 
125 |
126 |
127 |
128 | 6. **Calendar Integration (Priority: Medium)**
129 | Assigned to Anusha Fazal
130 | * Display Calendar in the Tasks page where the tasks will appear as they are added in.
131 | * Get tasks from user's Google Calendar via the Google API and display it on the Calendar in the Tasks page.
132 |
133 | Proof (Github: https://github.com/csc301-fall-2019/team-project-tdsb-team-2):
134 | * Static calendar: `/commit/7843777a460e80a556419f3dbf65a64a3a250485`
135 | * Calendar library: `/commit/38b9baa8a591975f4063d19b66712a4f73859416`
136 | * Get Google Events: `/commit/853b7849e8751c184b047dd1f1907124e1a2988d`
137 |
138 |
139 | 
140 |
141 |
142 |
143 | #### Goals and/or tasks that were planned but not met/completed:
144 |
145 |
148 |
149 | 1. **Graphing Software (Priority: Low)**
150 | Assigned to Gazi Jarin, Anusha Fazal
151 |
152 | Uncompleted: Did not allocate much time for this feature since it was low priority, predominantly because we only n the main features up and then we wanted to move forward with the extra features. Therefore, it should be completed for the next version where we fully implement the back-end for the main features and move on to the front-end for the less important features.
153 |
154 | 2. **Dictionary/Thesaurus Integration (Priority: Low)**
155 | Assigned to Alex Shang, Gazi Jarin
156 |
157 | Uncompleted: Same argument as the Graphing Software task. Dictionary integration was only a side feature in the main application so less time was allocated for it. We aim to have it done after we have completed all the more important features.
158 |
159 | #### How was your product demo?
160 |
165 |
166 | * We took preparations for the demo by compiling all the mock-ups that we did before-hand, as well as the front-end prototypes to display our current efforts in re-creating the vision of the TDSB app. We each had prepared our section of the talk by relating it to the tasks we have completed under the Goals and Tasks section.
167 | * The demo would consist of three parts - one part would be displaying the mock-ups that we had made, another part would be allowing the partner to interact with the application by herself to get a feel for it (live demo of the front-end prototypes), and last part would be talking about our future steps with the application. Throughout the demo, we hope to get an insight on how we are doing and to adjust our product accordingly to reflect the vision of the partner and her organization.
168 | * Important: We did not get a chance to demo yet due to our partner being unresponsive. We have sent our partner the initial blueprints and mock-up for the project through e-mail, as well as attempted to set up an in person meeting to update her on our progress, but we have received no response as of yet.
169 |
170 | ## Meeting Highlights
171 |
172 |
179 | * The Google API integration has simplified a lot of development, allowing us to leverage existing technologies to get calendars and classroom information, giving us time to focus more on the requested features by project partners.
180 | * Student accounts must be created the first time they log in to the application. This way, we may use existing information for this, and we can store their events and calendar information in the MongoDB databases for easy retrieval by the backend.
181 | * The initial demo and prototype has been created with a lot of mock data. To ensure that the data sent by the backend is of the same nature, we will have to create a JSON schema for the backend to follow so that the data that the front-end receives from the back-end is of the same structure, allowing it to be used with only minimal changes.
182 |
--------------------------------------------------------------------------------
/front-end/src/components/tasks/tasks.vue:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
16 |
17 |
18 |
19 |
20 |
21 |
Tasks
22 |
23 | Add Task
24 |
25 |
26 |
27 |
36 |
37 |
38 |
39 | {{ errors[0] }}
40 |
41 |
42 |
43 |
44 |
45 |
46 |
47 | {{ errors[0] }}
48 |
49 |
50 |
51 |
52 |
53 |
54 |
60 | {{ errors[0] }}
61 |
62 |
63 |
64 |
65 |
66 |
69 |
70 |
71 |
72 |
73 |
74 |
75 |
85 |
86 |
87 | Delete Task
93 |
94 |
95 | Submit Changes
96 |
97 |
98 | Submit
99 |
100 |
101 |
102 | Make sure you fill out Title, Date and Time!
103 |
104 |
105 |
106 |
107 |
108 |
109 |
110 |
116 | Sync with Google
117 |
118 |
119 | Last Sync Date:
120 | {{ last_sync_date }}
121 |
122 |
168 |
169 |
170 |
560 |
561 |
615 |
648 |
--------------------------------------------------------------------------------
/deliverables/iteration-02.plan.md:
--------------------------------------------------------------------------------
1 | # Team 12, Deliverable 2 - Part 1
2 |
3 |
5 |
6 |
7 | ## Iteration 02
8 |
9 | * Start date: October 25th, 2019
10 | * End date: November 12th, 2019
11 |
12 | ## Process
13 |
14 | We are developing a web application that is will allow students to keep track of the dates and deadlines for their homeworks and assignments, while allowing them to leverage information from their Google Classrooms and their personal Google Calendars. They will be able to log in with their TDSB (Gmail) accounts, create new tasks to do, and track their progress as they complete them.
15 |
16 | #### Roles & responsibilities
17 |
18 |
20 | - **Front End**: Work on the VueJs application
21 | - Add different components for each page for each feature
22 | - Create Mockups for each page before actual design and implementation
23 | - Ensure proper functionality of front-end components
24 | - Connect to proper backend endpoints to make required calls
25 |
26 | - **Back End**: Work on the Flask microservices
27 | - Set up the flask microservices
28 | - Add appropriate endpoints to ensure proper calling of the backend APIs
29 | - Add necessary functionality that the frontend can leverage
30 | - Set up the databases in MongoDB and connect to them via the microservices
31 |
32 | - **Full Stack**: Combination of front and back end
33 | - Ensure that the front and back end calls and behaviour are working as expected
34 |
35 | - **Project Manager**: Ensure that the correct communications are being made with the project partner
36 | - Send appropriate emails to the project partner
37 | - Set up meetings
38 | - Promote group discussions on matters
39 | - Ensure goals are being met
40 | - Breakdown road blocks
41 |
42 |
45 |
46 | **Members:**
47 |
48 | - **Anirudh Baskar**:
49 | - Role: Back-end (primarily API design)
50 | - Components:
51 | - Server-side and databases
52 | - Database Schemas
53 | - Features: Setting deadlines, Thesaurus, Notfication Systems
54 | - Technical strengths:
55 | - Languages
56 | - Python, Java, Javascript
57 | - Backend development and API design:
58 | - Flask and Node.js
59 | - Databases
60 | - MySQL and Firebase
61 | - Front end development
62 | - Vue.Js
63 | - Technical weaknesses:
64 | - UI design
65 | - React.JS
66 | - Software Testing
67 |
68 | - **Gazi Jarin**:
69 | - Role: Full-Stack, Product Management
70 | - Components
71 | - Server-side and app design
72 | - Features: Chatbox, Calendar
73 | - Task Page
74 | - Technical strengths:
75 | - Languages
76 | - Python, Javascript, Java
77 | - Backend development:
78 | - Flask, Node.js
79 | - Front end development
80 | - Vue.js, HTML, CSS
81 | - Other
82 | - Google Services (Firebase, Dialogflow), AWS server deployment, UI/UX design
83 | - Technical weaknesses:
84 | - Software Testing
85 | - Databases
86 | - SQL
87 |
88 | - **Raiyan Rahman**:
89 | - Role: Full Stack, Product Management
90 | - Components:
91 | - API Design and Implementation
92 | - UX Design
93 | - Front-End Design and Implementation
94 | - Features: Home screen, App Set up
95 | - Technical strengths:
96 | - Languages
97 | - Python, JavaScript, VueJs, Java
98 | - Backend development and API design:
99 | - Microservice design
100 | - Flask
101 | - Databases
102 | - Flask's SQLAlchemy, SQL
103 | - Front end development
104 | - VueJs
105 | - Wireframes and Mockups
106 | - UI/UX Design
107 | - Technical weaknesses:
108 | - Databases
109 | - Integration Testing
110 | - MongoDB
111 |
112 | - **Anusha Fazal**:
113 | - Role: Full Stack
114 | - Components:
115 | - UX Design
116 | - Front-End Work
117 | - Back-End API Integration
118 | - Features: Homework submission, Graphing, Google Calendar/Classroom integration
119 | - Technical strengths:
120 | - Languages
121 | - HTML, CSS, Javascript, Python
122 | - Backend development and API design:
123 | - Flask and NodeJS
124 | - Databases
125 | - SQL, MongoDb (noSQL)
126 | - Front end development
127 | - Vue.Js
128 | - UI Design
129 | - Technical weaknesses:
130 | - Software testing
131 | - Databases
132 |
133 | - **Alex Shang**:
134 | - Role: Full Stack
135 | - Components:
136 | - Serverside application
137 | - API design
138 | - Features: Register, Login verification
139 | - Technical strengths:
140 | - Languages
141 | - Python, Javascript, ReactJS, Java
142 | - Backend development and API design:
143 | - Flask
144 | - Databases
145 | - MongoDB
146 | - Front end development
147 | - HTML, CSS, ANT Design
148 | - Technical weaknesses:
149 | - UI design
150 | - Software testing
151 | - SQL database
152 |
153 | - **Mozammil Khan**:
154 | - Role: Full Stack Developer
155 | - Components:
156 | - Application Architecture and Implementation
157 | - Front-End Design and Implementation
158 | - Technical strengths:
159 | - Languages
160 | - Python, JavaScript, Java
161 | - Backend development and API design:
162 | - Node.js/Express.js
163 | - Databases
164 | - PostgresSQL, MongoDB
165 | - Front end development
166 | - React.js/Redux
167 | - Vanilla Javascript
168 | - Technical weaknesses:
169 | - UI Design
170 |
171 | - **Michael Katilevsky**:
172 | - Role: Full Stack
173 | - Components:
174 | - UX Design
175 | - Front-End Implementation
176 | - Back-End API and Databases
177 | - Features: User Data, Grades Overview
178 | - Technical strengths:
179 | - Languages
180 | - Java, Python, TypeScript, JavaScript, HTML, CSS
181 | - Backend development and API design:
182 | - Express.js, Node.js, Flask
183 | - Databases
184 | - MongoDB, PostreSQL
185 | - Front end development
186 | - Angular, React.js, UI/UX Design
187 | - Technical weaknesses:
188 | - Software Testing
189 |
190 |
191 | #### Team Rules
192 |
193 |
194 |
195 | Communications:
196 |
198 | * Communication between team members will be conducted in Facebook messenger in our Team's group chat. A discussion will take place with almost everyone present whenever any project-wide decision needed to be made. Communication frequency will be on a per-need basis. Whenever the whole group or a subset of the group decides to work on a certain task or feature, it is expected to get quick responses within a few minutes to ensure accurate and efficient exchange of information.
199 |
200 | * Project partner meetings were not as common anymore as we had been given the necessary information to continue with the development. We, however, did email the project partner with frequent updates such as after mockups were done for comments and review, and the update on beginning the actual implementation of the product. However, the project partner's responses were not frequent at all, even with the numerous attempts at emails, most often not getting replies. These communications were done mostly through emails, and in person meetings are being planned.
201 |
202 | Meetings:
203 |
204 | * Team meetings were had mostly in the Facebook Messenger group due to the busy and hectic schedule of everyone in the team. We had short meetings every few days to report our progress, what we were going to tackle next, and brought up any issues if we were stuck on anything. This was expected of each member and the project trello was updated accordingly. The team's project manager is in charge of ensuring that everyone reported to the chat with moderate frequency. Once each task was completed, other team members in charge of similar parts of the overall application were tasked with conducting code reviews to ensure optimal and quality code.
205 |
206 | Conflict Resolution:
207 |
208 | - Indecisions will be tackled with group discussions, outlining the pros and cons of certain choices. We will discuss through which discussions will yield the highest quality with the limited time we have.
209 | - Non-responsiveness will be dealt by initially attempting to reach the teammate ourselves through their contact information. If that is not possible, we will try to allocate some of the tasks to other members who have completed their own work. If the absence is for too long of a period of time, it will be notified to the TA.
210 | - If a team member is stuck because of a technical issue, they will immediately make it known what the issue is and why they are having it. Team members who are free will attempt to aid them if they have any knowledge regarding the issue, as soon as they are able to.
211 |
212 |
213 | #### Events
214 |
215 |
216 |
219 | * Meetings will take place in person for the first two initial planning meetings. They will take place on Friday, October 25th and November 1st. These will primarily be breaking down the product into components as well as the assignments of group members to certain tasks. The second meeting will be with an update on the tasks as well as confirming a front and backend design after reviewing and deciding on completed mockups.
220 | * Coding sessions and code reviews mainly be decided by the sub-groups before and after they finish features and tasks.
221 | * If members are entirely not able to make it, they are expected to notify the group within 12 hours and ask about the meetings to stay up-to-date.
222 |
223 |
224 | #### Partner Meetings
225 |
226 |
228 | - The first partner meeting will take place after the mockups for the front end are complete so we may understand what exactly the vision is for the application. We will also have the partner pick a design that they prefer and think will suit their purpose the best. This will go hand in hand with the planning we will do about the features and other details such as the priority of the tasks, so we may ascertain which needs to be completed first. This will allow us to create a timeline for our sprints.
229 |
230 | - The second partner meeting will include review and validation to ensure that the team is headed in the right direction. We will have the initial demo of what we implemented so far. This will also give the project partner an idea of where the product will be headed and what the end product might look like.
231 |
232 | #### Artifacts
233 |
234 |
235 | - We will be following the traditional agile methodology using a trello board as our primary task board. Here, we will update tasks that are added as needing to be done, those in development, those that are being tested, as well as the tasks we have completed.
236 | - Overview of Tasks can be found on Trello: https://trello.com/invite/b/68RfNTky/7bf7c72f2b6a52990927cfb8dc48d44c/term-project
237 |
238 | - We have divided our group into developers that specialize in back-end, front-end, and databases according to our strengths and previous experience. Although we will primarily stick to these parts of the project, we will definitely be more fluid with these roles and move around to get tasks done and help teammates when they need it.
239 |
240 | - Teammates will discuss with everyone and pick tasks to complete by assigning it to themselves on the trello board. Tasks will be prioritized with regards to how crucial they are to getting the base application and the MVP running and functioning properly to meet the basic requirements set forth by TDSB.
241 |
242 | - Our primary source of communication for discussing matters about the project and tasks will be through our facebook messenger group. We answer questions, discuss tasks, and schedule meetings through it. Our group also has scheduling features and reminders which will prove to be useful in ensuring we get tasks done on time.
243 |
244 |
245 |
246 | #### Deployment and Github Workflow
247 |
248 |
255 |
256 | We will have the basic application set up initially on the master branch. Once that is complete, each task and feature will have its own separate branch to ensure that conflicts are at a minimum, promoting modularity. This will ensure that if the code from any feature does cause problems, we will easily able to revert changes and quickly fix problems. Each branch will be named by the feature that will be implemented in it. This will allow easy identification of what the use of the branch is.
257 |
258 | Once features are done, we will have pull requests that will be followed by code reviews of the code written in the branch with the pull request. If the code is seen to be good with no issues, it will then be merged to the master branch.
259 |
260 | Once a working prototype is functioning with the minimum number of high priority requested features, we will have a discussion with the project partners about preferred cloud providers, whether or not they already have resources, and whether they would give us options to pay for specific cloud providers; we would then host it to that preferred place. A likely solution could be hosting it using Google Cloud as we are provided with free credits by the CSC301 class and opening an account with the Google Cloud platform provides $300 of free credits. We would utilize Docker in the hosting of the application. We would build our app to host it. Once our build has been finished, we would create a docker image for it and test out to see if it can be run locally. Once this verification is complete, we will push a tag of our docker image to the Google Container Registry which is a built-in registry support for images in the Google Cloud. Once this is done, we will then deploy our image to a Google Cloud GCE (Google Compute Engine) VM.
261 |
262 |
263 |
264 |
265 | ## Product
266 |
267 | #### Goals and tasks
268 |
273 |
274 | Overview of Tasks can be found on Trello: https://trello.com/invite/b/68RfNTky/7bf7c72f2b6a52990927cfb8dc48d44c/term-project
275 |
276 | For this iteration, we aim to get most of the main pages for the website done as well as set up a preliminary server and database for user registration.
277 |
278 | Concisely, for the front-end, we have the task of replicating the mock-ups for web-pages such as the home-screen, log-in, addTask screen, and the calendar screen. For the back-end, we have the task of proper user registration from the log-in page and storing vital information about the users in the database.
279 |
280 | 1. **Server and Database Set-Up (Priority: High)**
281 | Assigned to Anirudh Baskar, Alex Shang and Samin Khan
282 | * Initialize Flask app to run a server on localhost (for now)
283 | * Initialize an instance of MondoDB with the necessary URI and create static methods to control data (insert and modify)
284 |
285 |
286 |
287 | 2. **Basic Front-End Set-Up (Priority: High)**
288 | Assigned to Raiyan Rahman
289 | * Integrate basic Vue.js template to include the main window, navigation bar, account menu and background.
290 |
291 | 3. **Home-Screen (Priority: High)**
292 | Assigned to Raiyan Rahman, Gazi Jarin, Anusha Fazal
293 | * Replicate basic mock-up of home screen to create a static webpage.
294 | * Features include: static toolbar (Home, Profile, ourses, Tasks, Gallery, Tools), overview window to store recent activity, side calendar and task-list.
295 |
296 | 4. **Log-in and Registration (Priority: High)**
297 | Assigned to Anirudh Baskar, Alex Shang, Samin Khan, and Michael Katilevsky
298 | * Replicate basic mock-up of log-in to create a static webpage.
299 | * Features include: form input (name, password) and the ability to log-in with a Google account.
300 | * Create APIs to insert, modify and update student information such as courses, name, and user id.
301 |
302 | 5. **AddTask Screen (Priority: Medium)**
303 | Assigned to Gazi Jarin
304 | * Replicate basic mock-up of addTask to create a static modal using Bootstrap elements (b-button and b-modal) in the Tasks page.
305 | * Features include: form input (title), date and time picker, description text editor box, and attachment box.
306 |
307 | 6. **Calendar Integration (Priority: Medium)**
308 | Assigned to Anusha Fazal
309 | * Display Calendar in the Tasks page where the tasks will appear as they are added in.
310 | * Get tasks from user's Google Calendar via the Google API and display it on the Calendar in the Tasks page.
311 |
312 | 7. **Graphing Software (Priority: Low)**
313 | Assigned to Gazi Jarin, Anusha Fazal
314 | * Display the static webpage of graphing software under the Tools/Progress section.
315 | * The user will be able to log in completed tasks related to an assignment in a course
316 | * The user will be able to see their progress in percentage of each assignment yet to be finished/due
317 | * The user will see a list of all completed projects under each course
318 | * The user will see a graphical demonstration of their progress: # of completions over time.
319 |
320 | 8. **Dictionary/Thesaurus Integration (Priority: Low)**
321 | Assigned to Alex Shang, Gazi Jarin
322 | * Display a dictionary window under the Tools section.
323 | * Fetch data from an open-source dictionary API to display results.
324 | * User will be able to type in a word in a form input, and get the corresponding meaning, synonyms and word usage.
325 |
326 |
327 |
328 |
329 |
330 | #### Artifacts
331 |
332 |
338 |
339 | 1. Mock-Ups (Done)
340 | Purpose: Ensure the right kind of user experience and usability when it comes to interacting with the web application. This gives us a preliminary plan on what to base the actual front-end on.
341 | * Home Screen
342 | * Header: Title (TDSB App)
343 | * Navigation Bar: Hyperlinks to Home, Courses, Tasks, Tools
344 | * Profile Drop-Down: Hyperlinks to Logout, Account Settings
345 | * Activity Section: Recent updates on adding tasks, update on completing or starting new assignments, etc.
346 | * Calendar Section: Displays tasks, assignments and deadlines
347 | * Deadline Section: Displays upcoming due dates for all courses and the corresponding progress
348 |
349 | 
350 |
351 |
352 | * Log-in
353 | * Header: Title (TDSB App)
354 | * Form Input: Username and Password
355 | * Links: Forgot Password, sign in with Google
356 |
357 | 
358 |
359 | * AddTask
360 | * Header: Title (TDSB App)
361 | * Navigation Bar: Hyperlinks to Home, Courses, Tasks, Tools
362 | * Profile Drop-Down: Hyperlinks to Logout, Account Settings
363 | * Form Input: Title
364 | * Options Menu: Courses
365 | * Date and Time Picker
366 | * Text Editor: Description Box
367 | * Upload Attachment
368 |
369 | 
370 |
371 | * Account Settings
372 | * Header: Title (TDSB App)
373 | * Navigation Bar: Hyperlinks to Home, Courses, Tasks, Tools
374 | * Profile Drop-Down: Hyperlinks to Logout, Account Settings
375 | * Profile Avatar
376 | * Edit Container: Name, Username, Language, Timezone
377 |
378 | 
379 |
380 | * Calendar Screen
381 | * Header: Title (TDSB App)
382 | * Navigation Bar: Hyperlinks to Home, Courses, Tasks, Tools
383 | * Profile Drop-Down: Hyperlinks to Logout, Account Settings
384 | * Calendar: Display current month, scheduled tasks, deadlines
385 |
386 | 
387 |
388 |
389 | * Graphing Software
390 | * Header: Title (TDSB App)
391 | * Navigation Bar: Hyperlinks to Home, Courses, Tasks, Tools
392 | * Profile Drop-Down: Hyperlinks to Logout, Account Settings
393 | * In-Progress Window: Displays the current assignments in progress and the percentage of completion
394 | * Completed Window: Displays the courses and the projects completed for each
395 | * Graph: Displays a graph showing the # of completed assignments over time
396 |
397 | 
398 |
399 |
400 |
401 | 2. Front-end Prototype
402 | Purpose: Ensure final touches to the web application design and have a preliminary set-up so that the user can actually use the application to get a feel of what the end product is.
403 | * Static Home Screen with Mock Data
404 | * Log-in Registration to Static Home Page
405 | * Static AddTask
406 | * Static Calendar Screen with Mock Data
407 |
408 | 3. Code
409 | Purpose: Ensure the proper foundation for the back-end with MongoDB and Google Classroom API and Google Calendar API.
410 | * Database set-up
411 | * Create database schemas modelling the student accounts, their events, and calendars to properly store them.
412 | * Google API Integration
413 | * Allow the use of Google Classrooms and Google Calendars for students to utilize for their task tracking.
414 |
--------------------------------------------------------------------------------
/d1/product-and-planning.md:
--------------------------------------------------------------------------------
1 | # Team 12
2 | > _Note:_ This document is meant to evolve throughout the planning phase of your project.
3 | > That is, it makes sense for you commit regularly to this file while working on the project (especially edits/additions/deletions to the _Highlights_ section).
4 | > Most importantly, it is a reflection of all the planning you work you've done in the first iteration.
5 | > **This document will serve as an agreement between your team and your partner.**
6 |
7 | ## Product Details
8 |
9 | #### Q1: What are you planning to build?
10 |
11 |
21 |
22 | The product is a **homework management software** that is accessible via desktop and mobile. It is a **web application** integrable with Google Classroom such that tools like Google Calendar are utilized to maximize student organization.
23 |
24 | The problem that the product is trying to solve is the disorganization of middle to high school students when it comes to schoolwork management. The product aims to motivate the students to create their own form of coordination in order to encourage self-fulfilment and self-learning from a young age.
25 |
26 | The main use case for this product would generally be the same as how Quercus is for students at the University of Toronto. Instead of the aim being at students enrolled in a specific university, this product would serve as a more hands-on version of school management, aiming at all students enrolled under the Toronto District School Board. The product will be an online, multi-functional agenda which holistically combines key functionalities.
27 |
28 | Students who use the product will be able to track their own homework progress, set deadlines, and deconstruct large assignments into smaller tasks to complete.
29 |
30 | In addition to the features of scheduling and setting tasks, the student will also have resources built-in to help facilitate learning. These built-ins include a graphing software, a chatbox to discuss with other peers, an image gallery to store useful snippets and a thesaurus.
31 |
32 | Tentative, basic mock-ups:
33 | **Log-in Screen**
34 | 
35 | **Home Screen**
36 | 
37 |
38 |
39 |
40 | #### Q2: Who are your target users?
41 |
42 |
46 |
47 | The target users for our product would be students from grade 6-8 as well as their parents and their teachers. The users would in the future expand to all students in the school district (Elementary to High School students)
48 |
49 | #### Q3: Why would your users choose your product? What are they using today to solve their problem/need?
50 |
51 |
59 |
60 | Currently, TDSB students utilize Google Classroom integrated with Google Calendar, as well as agendas distributed by the schools themselves. The Google Classrooms and Calendars are populated with information from the teachers while the agendas are left to be used by the students to plan out and organize their time and work efficiently. This has proved to be a difficult task, especially for young students, as they often simply forget to use these. Many students even choose not to due to the extra hassle of having to further write everything down. They also do not have the added benefit of reminders and integration with the Google Classroom technology so as to easily access the information that is already there to be used.
61 |
62 | While there are already an abundance of apps that help with time management, there are very few from the schoolboard itself, making them non-integratable with their Google Classrooms. This added integration will allow students to leverage information already uploaded by teachers, making the process of them organizing tasks more efficient. This will cut down all the time students would otherwise waste on copying information to their scheduling apps, also ensuring that they have the most accurate and up-to-date information, such as grades and due dates. They will have the added benefit of reminders as well as helpful guides to break up large assignments into sizable portions which not many apps provide an interface for. This will make the act of organizing and chunking up assignments into a learning experience that they will be able to apply to other aspects of life, making this product align with the vision that TDSB has for this project.
63 |
64 | The most important aspect of our app that differentiates it from other similar applications is the fact that our application promotes learning, and self reflection. It allows students to collaborate with other students, teaches them about organization techniques with how it will guide them in organizing their tasks, and it will also be a platform that enables students to ask themselves and answer self-reflective questions about their progress in school and life, promoting them to aim high and feel proud of their accomplishments.
65 |
66 |
67 |
68 | #### Q4: How will you build it?
69 |
75 |
76 | We will be utilizing a microservice architecture for the project. This will add modularity to the application as well as scalabality and maintainability. An example of the planned design can be seen below:
77 | 
78 |
79 | We will be using the VueJs framework for the front-end and the flask microframework for the back-end, as well as MongoDB for the databases. To integrate with Google Classroom and Google Calendar, we will also make use of the Classroom API and Calendar API. We will deploy the application using the cloud service resources that will be provided by TDSB.
80 |
81 | Our development will be very focused on test-driven development. We will ensure that every back-end microservice we write will be properly documented and tested, with the addition of any new features. We will have unit tests and integration tests.
82 |
83 |
84 | #### Q5: What are the user stories that make up the MVP?
85 |
89 |
90 | 1. As a student, I want to be able to add my tasks in the app, so I can stay more organized in school.
91 | Acceptance Criteria:
92 | * Title of task
93 | * Class of task
94 | * Description of task
95 | * Able to attach picture to task
96 | * Progress bar of completion
97 | * Input grade for task
98 | * Reflection questions for task
99 | * Able to pull task from Google Classroom
100 |
101 |
106 |
107 | 2. As a student, I want to set deadlines for schoolwork, so I can plan ahead by seeing when my projects are due on the calendar.
108 | Acceptance Criteria:
109 | * Title of project
110 | * Date of project deadline
111 | * Time of project deadline
112 | * Calendar
113 | 1. Display current year
114 | 2. Display current month
115 | 3. Display weeks of current month
116 | 4. Display days per week
117 | 5. Button to click and set deadline
118 |
119 |
120 |
121 | 3. As a student, I want to chat with my classmates in the app, so we can collaborate on how to do our group projects together.
122 | Acceptance Criteria:
123 | * Chat box for two users
124 | * Profile picture in chat
125 | * Name in chat
126 | * Textbox to enter message to user
127 | * History of messages sent to each other
128 | * Users must add each other before they can chat
129 |
130 |
131 | 4. As a parent, I want to track homework progress of my child so I can know how my child performs in studies.
132 | Acceptance Criteria:
133 | * Ability to register and log in as a parent.
134 | * Ability to connect the parent account to a student account.
135 | * Ability to browse all existing projects, both completed and in-progress ones, in the connected student account.
136 | * For each project, provide following information:
137 | 1. Title of the project
138 | 2. Class of the project
139 | 3. Description of the project
140 | 4. All attached pictures of the project
141 | 5. For an in-progress project, show the progress bar
142 | 6. For a completed project, show the grade
143 |
144 | 5. As a student, I want to track my homework and exam grades so that I can easily assess my academic performance and adjust accordingly.
145 | Acceptance Criteria:
146 | * Allow students to enter any kind of grade into the system.
147 | * Any grade must have an accompanying title.
148 | * Any grade must be in relation to some course.
149 | * Allow students to add description to grades.
150 | * Showcase all grades for a course in one pane so it is easy to see all grades in a glance.
151 | * Incorporate grade weighting feature to calculate predicted final grade.
152 | * Potential feature: Display graph to showcase grade performance over time for a course.
153 |
154 | 6. As a student, I want to update existing projects so I can keep track of my progress.
155 | Acceptance Criteria:
156 | * Ability to show all existing projects.
157 | * Ability to delete selected project.
158 | * Ability to modify the project information, including title, class, description, etc.
159 | * Ability to upload pictures for existing projects.
160 | * Ability to set milestones for each project.
161 | * Ability to change the status of each milestone: in progress/completed
162 | * Ability to change the status of each project: in progress/completed.
163 | * Ability to input a grade for the project
164 | * Ability to add/modify a progress bar for each project
165 |
166 | 7. As a teacher, I want to moderate the student inbox so that the students can engage respectfully in a safe environment.
167 | Acceptance Criteria:
168 | * Search bar
169 | 1. Search a student by their email
170 | 2. Click on student to redirect to their profile
171 | * Access student inbox
172 | 1. Display their interactions inside inbox
173 |
174 | 8. As a student, I want to visualize my completion on specific projects, so I can track and assess my growth in work completion throughout the year.
175 | Acceptance Criteria:
176 | * Ability to specify the project.
177 | * Ability to choose the type of graph.
178 | * Ability to generate a graph based on existing project information (e.g. number of finished/unfinished milestones, grade, average, update frequency, etc.)
179 | * Ability to change the graph when the information it based on changes.
180 | * Ability to attach the graph to the project
181 |
182 |
183 | ----
184 |
185 | ## Process Details
186 |
187 |
188 |
189 | ### Roles & responsibilities
190 |
191 |
193 | #### General Roles
194 |
195 | - UX designer:
196 | - Will design detailed prototypes of the application
197 |
198 | - Front End:
199 | - Will develop the UI and client side of the application
200 |
201 | - Back End (API design):
202 | - Handles the server side of the application and primarily focuses on API design and middleware
203 |
204 | - Back End (Database and Dev ops):
205 | - Primarily focuses on designing and integrating the database. Writing queries for the middleware team
206 | - Responsible for maintaining the production environment
207 |
208 | - Product Manager:
209 | - Responsible for ensuring the project as a whole is meeting client needs
210 | - Responsible for setting team and client meetings
211 |
212 |
213 | #### Team Member and their Roles
214 |
216 |
218 |
219 | - **Anirudh Baskar**:
220 | - Role: Back-end (primarily API design)
221 | - Components:
222 | - Server-side and databases
223 | - Features: Setting deadlines, Thesaurus, Notfication Systems
224 | - Technical strengths:
225 | - Languages
226 | - Python, Java, Javascript
227 | - Backend development and API design:
228 | - Flask and Node.js
229 | - Databases
230 | - MySQL and Firebase
231 | - Front end development
232 | - Vue.Js
233 | - Technical weaknesses:
234 | - UI design
235 | - React.JS
236 | - Software Testing
237 |
238 | - **Gazi Jarin**:
239 | - Role: Full-Stack, Product Management
240 | - Components
241 | - Server-side and app design
242 | - Features: Chatbox, Calendar
243 | - Technical strengths:
244 | - Languages
245 | - Python, Javascript, Java
246 | - Backend development:
247 | - Flask, Node.js
248 | - Front end development
249 | - Vue.js, HTML, CSS
250 | - Other
251 | - Google Services (Firebase, Dialogflow), AWS server deployment, UI/UX design
252 | - Technical weaknesses:
253 | - Software Testing
254 | - Databases
255 |
256 | - **Raiyan Rahman**:
257 | - Role: Full Stack, Product Management
258 | - Components:
259 | - API Design and Implementation
260 | - UX Design
261 | - Front-End Design and Implementation
262 | - Features: Home screen, Google Calendar/Classroom integration
263 | - Technical strengths:
264 | - Languages
265 | - Python, JavaScript, VueJs, Java
266 | - Backend development and API design:
267 | - Microservice design
268 | - Flask
269 | - Databases
270 | - Flask's SQLAlchemy, SQL
271 | - Front end development
272 | - VueJs
273 | - Wireframes and Mockups
274 | - UI/UX Design
275 | - Technical weaknesses:
276 | - Databases
277 | - Integration Testing
278 |
279 | - **Anusha Fazal**:
280 | - Role: Full Stack
281 | - Components:
282 | - UX Design
283 | - Front-End Work
284 | - Back-End API Integration
285 | - Features: Homework submission, Graphing
286 | - Technical strengths:
287 | - Languages
288 | - HTML, CSS, Javascript, Python
289 | - Backend development and API design:
290 | - Flask and NodeJS
291 | - Databases
292 | - SQL, MongoDb (noSQL)
293 | - Front end development
294 | - Vue.Js
295 | - UI Design
296 | - Technical weaknesses:
297 | - Software testing
298 |
299 | - **Alex Shang**:
300 | - Role: Full Stack
301 | - Components:
302 | - Serverside application
303 | - API design
304 | - Features: Register, Login verification
305 | - Technical strengths:
306 | - Languages
307 | - Python, Javascript, ReactJS, Java
308 | - Backend development and API design:
309 | - Flask
310 | - Front end development
311 | - HTML, CSS
312 | - Technical weaknesses:
313 | - UI design
314 |
315 | - **Mozammil Khan**:
316 | - Role: Full Stack Developer
317 | - Components:
318 | - Application Architecture and Implementation
319 | - Front-End Design and Implementation
320 | - Technical strengths:
321 | - Languages
322 | - Python, JavaScript, Java
323 | - Backend development and API design:
324 | - Node.js/Express.js
325 | - Databases
326 | - PostgresSQL, MongoDB
327 | - Front end development
328 | - React.js/Redux
329 | - Vanilla Javascript
330 | - Technical weaknesses:
331 | - UI Design
332 |
333 | - **Michael Katilevsky**:
334 | - Role: Full Stack
335 | - Components:
336 | - UX Design
337 | - Front-End Implementation
338 | - Back-End API and Databases
339 | - Features: User Data, Grades Overview
340 | - Technical strengths:
341 | - Languages
342 | - Java, Python, TypeScript, JavaScript, HTML, CSS
343 | - Backend development and API design:
344 | - Express.js, Node.js, Flask
345 | - Databases
346 | - MongoDB, PostreSQL
347 | - Front end development
348 | - Angular, React.js, UI/UX Design
349 | - Technical weaknesses:
350 | - Software Testing
351 | #### Team Rules
352 |
353 |
354 |
355 | Communications:
356 |
358 |
359 | - Members are expected to provide weekly updates on their progress on Sunday through Messenger group chat.
360 | - Members are to respond to questions/concerns directed at them within 24 hours
361 | - We will primarily communicate to the partner through email. We have obtained the phone number of our patner and will use it if the partner does not respond within 48 hours
362 | - In addition to our immediate supervisor (Veronica), we have also obtained the email of a TDSB IT department worker and will use that for technical inquiries
363 | - Extra: We have the emails of all the students in the other group who are also working with us. We will use that to communicate the division of work and ensure that none of our work overlaps, and if it does, to make it very clear so there are no misunderstandings.
364 |
365 |
366 | Meetings:
367 |
368 | - Members are expected to show up to general meetings set through Messenger group chat. They also have the option of joining in through Skype or Zoom. If they are entirely not able to, they are expected to notify the group within 12 hours and ask about the meetings to stay up-to-date.
369 | - Every week, every member should provide a brief overview about what they have done so far and what they are going to do the next week (online "stand-up" meetings).
370 | - In addition to the brief overview, they are expected to stay active on Trello and manage their tasks individually. If they are done a specific task within a deadline, they should mark it completed on the taskboard. If not, they should make an issue on the taskboard and try to resolve it by discussing with the group.
371 |
372 | Conflict Resolution:
373 |
374 |
375 | Scenario 1: Non-responsive team members
376 | - If a member fails to respond to questions directed at them within 24 hours or is absent in team meetings without notice, we would call them on their personal phone number and try to approach them in class if possible. If there is no response for a prolonged period (over 5 days), their task will be assigned to other sub team members on a voluntary basis and the TA will be notified.
377 |
378 | Scenario 2: Indecision on how to approach a problem/feature
379 | - We would employ the strategy discussed in tutorial where each member would rate the difficulty/feasibility of aproaching the problem in a certain way. If everyone's rating is similar, we would move forward with the approach. If not, each member will discuss their viewpoints and we will hold the vote again untill a consensus is reached.
380 |
381 | Scenario 3: A member not meeting their assigned requirements
382 | - In this case, we will ask the member to reassess their strengths and weaknesses and move them to a feature/team they are more comfortable with working on. They may also be asked to take on more non technical responsibilities. Their role will be taken on by another member on a voluntary basis.
383 |
384 |
385 |
386 | #### Events
387 |
388 |
392 |
393 | The general meetings will take place at 4 pm Fridays in BA2270. The meetings are usually set every two weeks or so, to ensure everyone is on the right level of understanding. These meetings cover the current project progress, as well as resolve any team conflicts if there are any. These general meetings are not required to be in-person, and members can join in with Skype or Zoom if they are not able to in-person.
394 |
395 | The "stand up" meetings occur every week, through the Messenger group chat. Everyone in the team must message the group chat on Sunday about what they have done so far and what they are going to do the following week. Although the default setting of those meetings are online, they can also be set online if there is any delay in progress.
396 |
397 | In addition, there are also optional code-review meetings which take place during the tutorial timeslot, 12-1 PM Tuesdays in UC244. If the tutorial is not a free work session, then the code review would get moved to the hour after, 1-2 PM. These are only set up if there are outstanding problems with the code base or any small technical difficulties, which could be resolved with the insight and/or help from everyone in the team. Again, these sessions are not required to be in-person, and members can join in with Skype or Zoom if they are not able to in-person.
398 |
399 | #### Partner Meetings
400 |
404 |
405 | The meetings took place in Gerstein, room 1200, around 12-1 PM. During the meetings, we introduced ourselves and received feedback on how the product partner wants the web application to be done. The project partner shared her sentiments regarding the project need, which helped us gain understanding about the true nature behind the app. We learned that it is predominantly to motivate students to be administrators of their own academic success by organizing schoolwork in a multi-functional app, instead of mindlessly writing down notes on an agenda. Therefore, this meeting helped us understand *why* we are making the product and made a lot of high-level descriptions of the product clear.
406 |
407 | Secondly, the project partner also let us know how to proceed with the user stories. The project partner shared her experience with students and what their needs were. Those insights made us envision an image of the student and specific information regarding the functionality of the application, which helped in writing the user stories from different angles.
408 |
409 |
410 | #### Artifacts
411 |
418 |
419 | We will be following the traditional agile methodology using a trello board as our primary task board. Here, we will update tasks that are added as needing to be done, those in development, those that are being tested, as well as the tasks we have completed.
420 |
421 | We have divided our group into developers that specialize in back-end, front-end, and databases according to our strenghts and previous experience. Although we will primarily stick to these parts of the project, we will definitely be more fluid with these roles and move around to get tasks done and help teammates when they need it.
422 |
423 | Teammates will discuss with everyone and pick tasks to complete by assigning it to themselves on the trello board. Tasks will be prioritized with regards to how crucial they are to getting the base application and the MVP running and functioning properly to meet the basic requirements set forth by TDSB.
424 |
425 | Our primary source of communication for discussing matters about the project and tasks will be through our facebook messenger group. We answer questions, discuss tasks, and schedule meetings through it. Our group also has scheduling features and reminders which will prove to be useful in ensuring we get tasks done on time.
426 |
427 |
428 | ----
429 | ### Highlights
430 |
442 |
443 |
444 | We thought of appraching this project with a "feature-first" mindset where we would just implement and add whatever feature that the parters required. However, our group, through the meetings and discussions with TDSB and amongst ourselves, has decided on a plan to put our design and usability at the forefront. Our target audience for this project consists of students in middle school and high school. With a younger age group such as this, we know to take into account how young technology users are very prone to switching over to applications that are simpler to use and visually and aesthetically pleasing.
445 |
446 | We decided to spend extra time to create possible mockups of medium fidelity with wireframes, and conduct interviews with a set of students that would fall inside the group of potential users. We would then proceed with a very user-centric design, to ensure that our product would remain user friendly. Once we have the general layout of our design planned and tested, we would be able to speed up our development process to complete the features that are requred.
447 |
448 | We have planned a meeting with the IT head at TDSB to inquire about how much of their existing Google Classroom and Calendar information we would be able to leverage, as this would not only speed up our development but it would also enable us to fully utilize the existing information for the Google APIs to ensure that we are working with meaningful data when developing and testing our product.
449 |
450 | We will develop this project using the microservice architecture as it will be easy to scale and maintain. This will also allow us to easily test certain backend functionality and easily add on more functionalities as they become known. This will help us deal with the changing requirements of a project of this type. As our team members all have courses that they must also attend to, this will ensure that our tasks are easy to manage and module in nature. In this way, we will be able to still work separately while collaborating together to achieve the end product.
451 |
--------------------------------------------------------------------------------