# Presentation Outline (:D)

# EV3

## Front End

### Restrospective

React is a good choice

Bootstrap is cool

### Evaluation
- Bulk Import
- Strengths: set up to display directly from the backend so changes only need to be made in the backend.
- Weaknesses: not a super intuitive workflow. Doesn't update error statuses while editing, you need to click validate. This choice was made because validation is slow so it would be annoying to have to validate the entire page every time you make a small change. Needs some css work still, we don't make the best use of white space.

## Deployment

### Restrospective
Docker continues to be a great choice,

It's still an

### Evaluation
Our production system takes a backup of itself and sends it to the backup system, and it'd be better if the backup system went into the production system and took a backup itself.

## Back End

### Retrospective

- Previously, instead of being handled as a boolean, the `Guardian` and `Administrator` user privileges were handled by groups instead of a boolean indicator. This proved to be a good choice for this evolution due to the introduction of the new user groups.
- `django-rest-authemail` was not a hindrance during this evolution.
- The browsable API was slightly less useful during this evolution due to lack of support for lists.

### Evaluation
- During this evaluation, user privileges were managed throough filtering querysets, custom permissions, and serializers.
- **Querysets:** control the objects that users can see (such as the parents that have students that attend the managed schools of a logged-in staff user).
- **Permissions:** control whether the CRUD permissions for objects.
- **Serializers:** control the visible fields of an object in operations.
-

---

# EV2

## Front End

### Retospective
- Bootstrap Integration: Previously, our website content consisted of self-styled components and CSS files, resulting in a lack of responsiveness and a unprofessional UI.
- This was clear on different screen sizes where our pages did not dynamically resize.
- There was a mix of CSS files floating around that made it hard to edit and style pages
- In the context of current evolution requirements, newer interfaces such as a stop planner portal, email portal, would be poorly styled as well.
- To make the website more professional, dynamic, and clean up our frontend, we integrated react-bootstrap and Boostrap to style our webpages.

- Map based interfaces
- Full utilization of a map-based interface to make and edit routes. Previous interface featuring many click-to-add tables were becoming very cluttered and confusing, especially for expansion into this evolution.
- Similar implementation of a cleaner map-based stop planner interface that is more intuitive and uncluttered.

- Component Remakes: We redid our interface to plan routes and generalized many components (such as tables) to be generic and reusable.
- Better planning of route planner interface to be more intuitive
- Generic components such as a table component that would be reused accross many pages, eliminating excess repeated code
- Integration of feedback from EV1: Clickable tables, distinct legend, more intuitive features/functionality, accessability (color-blindness), thematic accross the webpage

- Redux
- We implemented redux in order to have a global state that we could access across the application. Whenever we make backend API calls we send dispatches to update the global state with this information. This is the main way that we use redux and it comes with benefits and drawbacks.
- Pros
- We can render pages and as the global state updates the pages fill the components with information. This makes it so the user is not waiting for the page to load after making changes to the data on the page.
- All backend API calls are moved out of the component files and into an actions folder. Helps with debugging and readability.
- Cons
- Making decision based on success or failure of calls is difficult. Currently struggling with this. Chose to keep code clean rather than fix.
- Async nature of dispatch means that the global state can be set incorrectly. For example, 2 calls are made to update the same thing, call 1 is incorrect and call 2 is correct. Call 1 takes longer, so call 2's result updates state first, then call 1 finishes and sets the values to the wrong thing.

### Evaluation
- File Structure
- Frontend have duplicate files due to rewrites and combination of features. The names of the files are also inconsistent with each other, with some files having prefixes such as "General", "Admin", and multiple other files without. They

- Bootstrap
- Strength: Very expandable into future evolutions to utilize pre-styled components to expand our current pages without having to worry about varying screen sizes or hardcore CSS work
- Weaknesses: Not *as customizable*, if we were CSS pros we could ideally style anything however we want, and it's a bit tricky to use bootstrap components and then have to overrride default styling to our own
- Tradeoffs: We would've kept styling components with our own CSS files. While it's possible, it gets very messy and time consuming.

- Map based interfaces
- Strengths: Very customizable, and easy to change different actions on the map. Very expandable, and easy to add new features as necessary for future evolutions within the map.
- Weaknesses: Could possibly be limited by the API based on custom inputs we want to do on the map in the future. Ex: what if we want keyboard inputs on the map? May not be possible if the API doesn't support it
- Tradeoffs: Use a static map with supporting components such as clickable tables for actions, however this is cluttered and sometimes confusing with so many tables.

## Backend
### Retrospective
- Previously, we had to override the default user class. With the introduction of `django-rest-authemail`, we had to migrate to their email user class.
- Django Rest Framework has still been a good choice for development, but less due to the amount of code that it simplifies (we only included one new model this time). We were able to reactivate the browsable API by also enabling session authentication This allows for quick sanity checks, easier debugging.
- Including new filter fields was straightforward, and this time, we did not encounter duplicate and non-deterministic query results.
### Evaluation
- Emails was done via `django-rest-authemail` which expedited the process. A migration process did occur to their custom authentication user class, but afterwards, changing passwords via email was plug-and-play. Inviting users was a custom workflow, but heavily inspired by the verification workflow in the original code.
- Strengths: after switching to the new user class, emails were very straightforward and utilized templates for formatting.
- Weaknesses: because the `reset-password` endpoint was directly added from their code, adding additional template variables would require rewriting the methods. However, the invite and change password emails are expected to be simple, and the templates can be directly edited to include additional instructions. Rich email formats can be deferred to the announcements feature.
- Announcements were handled by customizing the email methods of `django-rest-authemail` and also providing the ability to specify additional template context information (such as nested objects for student information).
- Strengths: the frontend is able to specify which templates are used, and the variables that are sent to it because we accept arbitrary JSON data in the payload field. We do monitor the templates that are used, because they're stored in the backend so a client is not able to execut arbitrary code. This enables frontend developers (with access to templates) to customize announcement emails in any way.
- Weaknesses: the defaults are already pretty good and we have tables. Accepting arbitrary JSON in the `context` field may make rendering template variables difficult to debug.