Sprint-by-sprint breakdown of Poolerz project tasks including full descriptions and subtasks.
New users are prompted to fill out the form, and then are given access to the application (will need to have a new field in the database that signals whether a user has properly signed up/filled out the form). This will include a general landing page, prompts to “sign up” instead of log in, the hiding of the form from the navbar, and the ability to only complete the form once before being given access to the full application.Subtasks:
Create refined Poolerz landing pages (one for not being logged in, one for not having completed the form, and one for being fully logged in AND signed up).Subtasks:
Ensure the flow & UI for the form, profile, and the central skeleton (header/footer) of the application is mobile responsive and is finalized before moving onto the optimization algorithm in the next sprint, which includes ensuring a consistent and preferred database scheme for user data.
Create an initial optimization algorithm, that given multiple users & their data (must decide on a standardized input), it outputs the optimal groups based on carpool specific factors (drop off time, location, etc.). This is the core of the application, so look into the best method prior and talk with Nandu along the way for advice.Subtasks:
Make JSON example inputs for the algorithm [each example should be one large JSON with multiple users’ data and carpool data], which will include ALL user parameters (per user) and carpool parameters (which we will request in the create carpool flow) necessary for the full completion of the algorithm.
Given a valid address, get the associated LAT/LONG coordinates (in JS/TS). Then find some distance functions that we can use with the coordinates (ex. haversine, preferably driving distance with an API). All of this must be in JS/TS.
The actual optimization algorithm with the inputs and distance functions using k-means (or DBSCAN) clustering, the hungarian algorithm, constraints, minimization, etc. Could be more naive at first by not addressing every constraint.
In parallel with the optimization algorithm, create a form & database connection (with minimal UI) that creates a carpool with necessary inputted/stored data (which will also be the input to the optimization algorithm) which also generates a unique carpool sharing code (which will be used in the next sprint for joining).Subtasks:
Create a basic create carpool flow and form that collects relevant carpool data needed for the algorithm and for displaying carpool data (referring to JSON input to algorithm could help here) and save all form state in proper format temporarily to later save into a new database table (the other part of this main task). Don’t forget to associate the creator of the carpool in the JSON schema.
Connect the form and data to the database for easy pulling and pushing (after submitting) of new and old carpool data. Pull and display all carpools that a user created to ensure this works after creating one (don’t worry about a good UI). Also, create a unique (MUST be UNIQUE) carpool ID (6 digits) associated to each carpool before pushing a new carpool to the database to prepare for the join step in the next sprint.
Create the flow to join a carpool given the connection string generated in the previous sprint.Subtasks:
Utilizing the unique join code functionality from the previous sprint, create a flow where a user can enter a unique join code, then enter their information regarding the carpool (availabilities, etc.), and then take this information and help the corresponding subtask “Join Carpool Database Connection” connect this data to the database in an intelligent way to handle members and member data accordingly. After submitting, they should be redirected the main carpool dashboard, where they can view their joined/created carpools like normal (note: in the next sprint we will be setting up unique pages for carpools, which can be navigated to from this main dashboard).
Connect the data collected from the user in the join flow process and store it effectively in the database (either in existing or new tables) to properly handle members and member data. You must consider intelligent ways of storing this data such that it will be easy to (1) receive ALL member data of a carpool [s.t. all member data can be found based on the carpool id] and (2) display UNIQUE user data of a carpool based on the user [s.t. a user can be corresponded with their data in a carpool]. Be mindful of the next sprint, where we will have user and owner views of the dashboard, where data will need to be fetched corresponding to users and carpools. Further, once a user joins by submitting their form data, ensure that their main dashboard reflects their newly joined carpool. Make sure to connect consistently with the person working on “Join Carpool Basic Form and Flow.”
Refine the minimum mockup for the create carpool UI & create a dashboard to show all created and joined carpools. For here, make sure to finalize the creation and joining aspects of carpooling, so in the next sprint we can focus on running the optimizing algorithm on the carpool.Subtasks:
Design a nice and practical UI for the main carpool dashboard that allows for creation, joining, and displaying of carpools related to the user at hand. Provide these mockups as a link in the comments of this activity to verify the accuracy in its implementation.
Enhance the overall UI design of the application to make it look more professional/user friendly/modern. Ensure that certain technical changes are being accounted for (e.g. no need for contact/mailing section [redesign without], no opt link at bottom [temporary], no need for availabilities in original form [remove], etc.).
Implement the UI design changes from the “Design New UI for Main Dashboard” and “Enhance UI Design of Application” tasks. This will have a focus on making the main carpool dashboard look good while redesigning our current UI to meet our technical and visual needs (e.g. no need for contact/mailing section [redesign without], no opt link at bottom [temporary], no need for availabilities in original form [remove], etc.).
Go through the entire application from start to finish and ensure that the form inputs, creation process, joining process, etc. work as desired and well, making changes as necessary. Proof of verification is necessary [make a small checklist of things changed] as we will assume our UI and implementation up to this point is perfect to allow for the connection of our optimizer and displaying of carpool data going forward.
Due to internal discussions with our client, we will be further refining our optimizer through this sprint (and likely many to come). Goals for this sprint are to (1) implement additional validation checks, (2) look into cluster and unclustered user corrections, and most importantly, (3) ensure a useable schedule-oriented output of the optimizer that can be used to later display carpool assignments.
Ensure different permission for owners and members of a carpool group, and allow owners optimize the carpool by running the optimizer. This will require the connection of the static optimization algorithm from sprint 2 along with the creation & joining of carpools from the previous sprint.Subtasks:
Populate test_data1.json, test_data2.json, test_data3.json, and test_data4.json into four different carpools. This will involve updating users, user-data, user-carpool-data, carpools, and accounts (all collections) to fit the proper schema as if the people signed up for accounts and joined carpools. In each of these carpools, make my account [_id: ObjectId(‘redacted’)] the owner so when permissions are involved I can run the optimizer. Feel free to duplicate carpools once everything is populated and make yourself owner of the duplicates if curious, but ensure at least four exist where I (Tyler) am owner.
Create a self-contained front-end page @ (/optimizer-input) that based solely on a carpoolID string input, if you press a button, it console.log’s a JSON of all of the associated data of the format of the optimizer’s input, that is, of the format of any of the test_data#.json files. This will be used to fully connect the optimizer.
Display the JSON output from running the optimizer in the dynamic carpool page for a carpool (done in another subtasks) in a user-friendly front-end format (consult Annie if need UI ideas) [HINDSIGHT NOTE: will have to store the result of the optimizer into the database to complete this task]. Also, ensure that only the owner of the carpool can run the optimizer (button will already be created), and ensure that everyone can see the result of the optimization.
Connect the formatted input from another subtask with the optimizer at a self-contained front-end page @ (/optimizer-run), where if given a carpoolID string input, when you press a button, it runs the output and console.log’s the JSON output of the algorithm. Then, integrate this into the dynamic carpool page files where if you are at the page of a carpool and press a button, the same thing happens for the specific carpool. Note: skipped the previous subtask and just implemented the latter. The first subtask is accomplished in lib/optimize.ts.
After connecting the optimizer, create and refine the dashboard that users see in their carpools before and after optimizing it. This will include calendar view, event editing (if owner), and filtering of certain kinds allow leaving of the carpool. This will be minimal functionalities with minimal UIs, which we will refine in our final sprint.Subtasks:
Create dynamic carpool pages (carpool dashboard) for each carpool. This is where members will see carpool information before and after optimizing (e.g. members, carpool info, schedules, etc.). Connect with the person working on [redacted] since they will be displaying the schedule output and implementing permissions, which will change what can be done/seen.
Within the dynamic carpool page(s), emboss the displaying of optimizer outputs (which should be already done at this point) by adding (not replacing) a calendar view of schedules. Allow editing of event information if you are the carpool owner (permission should already be set up), and allow a user to leave a carpool here (which should completely un-attach the user in the backend from the carpool; that is, they won’t be listed as a member or included in the optimization if it is re-run, nor will they be able to navigate to the carpool again). Work with the people implementing [redacted] and [redacted] to ensure no confusion and for help with these tasks if needed.
This will most likely be used for refining our overall flow, ensuring a great UI, and connecting anything that still needs to be connected. Our previous sprints are ambitious, so we will reserve this sprint for pushing back anything that hasn’t been done yet, and if there is nothing, we will perhaps work on implementing QR carpool invitations for an invitation dashboard.