Journal

• Hand in summary – due the 6th,
• This just means that we need to update the website completely, put everything in the right place
• Such as hand off plan in deliverables
• We will have our personal report, where we allocate $100 across the team based on how much we think they contributed.
• Louis says that when he grades this, he will base it mainly on the handoff plan and how well the client can deploy our code.
• He would like it if we deployed for the client straight up (we’ll see if we can get the server space)
• Need to make sure documentation is very thorough, that seems like most of our grade.

• Keep testing on localhost, and try and test front end with backend on localhost.
• Jess – colorblind shapes on the dashboard
• Need to have final presentation – has to be a demo, we can do that on Jess or Alex laptop so we have a database up and running for us to demo.
• Do demo at the end, full software cycle before
• Need to focus on final presentation, and then the hand off plan for our client. send it to them as soon as possible so that they can give feedback on how that is.

• Tech talk – make sure we have clearly stated numbers on why npm is not that great, like how messy it is, how pnpm is faster
• hand off plan this week, get it done
• work on documentation for when we have final presentation, and for the hand off plan, clear description of everything installation for the hand off.

• Updated Louie on progress, just general progress mostly.
• We updated front end, backend, database.
• Tech talk – 5 minutes talking about what the topic is, then we go into the rest of the time doing a tutorial on how to use something.
• Don’t let them guess why they are doing the tutorial, talk about the main goal at first then coach them through it.

• On the dashboard – want a button to add a new user and to query the database so that they don’t have to deal with code.
• Sending out a survey – also have a button for that, we can figure that out in terms of creating a button that has that functionality.
• Separate UI for clicking on a patient to see their history and stuff like that
• If they have taken the survey great, if not, have a button to resend.
• Qualitrics message from Amy – shes building a simpler version in Qualtrics, but doesn’t know how to do the logic behind it in JS.
• We will give her the GitHub Repo
• We still need some stuff from them – they will have those soon and keep it the simplest as possible
• Buckets and the actual questions being asked are going to be the same
• One outcome that is most important to you, one that is least important to you
• Other surveys – how you are feeling 1-10, decisional regret, effort of provider, etc.
• This is on teams, but not as important as the main goal atm.
• HIPPA Compliance – he’s not worried about how well we do that, he likes the track that we are on.

• Next step is to integrate front end to the back end
• Get to a point where we can record answers
• Talk to client about Qualtrics, and see if it is feasible – if it is not, then make sure they know that it is not explicitly
• Get feedback from client – to see if they are happy with what we are giving them after we connect the database to the front end
• Look at functional requirements and make sure that we are meeting them
• Tech Talk – we are locked in, npm vs pnpm in mid April

Need to add script for DB into the ReadMe, as well as update the ReadMe in general.

Description should tell us why we want the separated file structure. That is, in the commit/PR description.

Capitalize first letter of commit message, and use present tense in commit messages. Also word choice i think. Can use git rebase reword to change commit messages.

Decide on a specific topic for the tech talk

• Fix Architecture diagram (under different deliverable with platform selection info) and finish ethics assignment
• for Friday the third
  • define JSON object for the survey results to show the client what the database will look like.
  • cleanup the UI, make the bottom numbers update as we go
  • make the radio buttons work
  • we can send a new short video on how to use the website to our client can distribute it
  • update README

• Survey questions matter as to which they are paried with. Most or least important only once per question
• each category is mapped to each outcome, and based on this outcome the patient will get guidance on what they might ask their healthcare provider after.
• we will get info on a landing page at some point in the future
• Both email and phone number can be used to message the patient
• Building in results over time could be a good thing to do for the healthcare provider, not so much the client
• if they ask for the longitudinal results, we can show them that but not a requirement
• more conversational tone in the responses
• we have freedom to figure out how this will interact with a patient, making it more engaging and interactive
• meetings fridays at 3:00 with R&D team, he would love to see us there.
• notification for the doctor, “hi doctor, so and so finished this survey, click the link for results”
• directly to provider with results – would you like to send your results to your provider, asking the patient.
• Friday March 3 – we will be meeting with his team and presenting so we need to make things look good/function pretty well.

---

We met instead of class to update each other on progress and set what to do next.

• Ask Louis about the architecture diagram and testing tomorrow to see what exactly we need to do.
• Ellis made a front end demo for us to show our client. Ellis and Andy think that making the website all in the front end makes more sense because of the simplicity of the app.
• Andy will work on adding functions that communicate with the SQL Database, as well as run the algorithm that takes answers from the user and quantifies them.
• Ellis will clean up the demo slightly (it looks good already) for us to show our client.
• Alex and Jess talked about how they will set up the tables in the database. Outlined the entire database and how it will look.

---

• Alex asked about what kind of ID will go into the database.
• They will be hashed IDs, but Daniel doesn’t know too much about it quite yet.
• Scratch that – secure database actually – cause they want their name, email, and general info in the database. Can figure out the security later
• Emailed us the packets of questions – all the surveys, etc.
• He sent us more mach-ups in a powerpoint. We can go off of that, but it does have a sign in, which we don’t need to have (just the link in, link out).
• For each attribute, we add one for when it is most important, and subtract one for least important.

---

• Our user stories and project concept are good for this week.
• Need to finish specifications, not much work at all left on that.
• Need to create a working/clickable version of the concept that he gave us in the next two weeks. Today, get the list of questions from him, then me and Ellis can work on backend/frontend stuff in meantime.
• Finally, look at midterm presentations how-to, and look at ethics assignment.

---

Met after class

• ToDo – User stories – edit them from the document
• ToDo – Proof of concept/project concept – compile images that Daniel gave us, and write a short summary on what it does
• Get the flowchart from Daniel
• Do some research into our roles
• Roles – Front End (Ellis), Back End (Andy), Database (Jess and Alex)
• Create GitHub repository

---

We met with our client for the first time on Tuesday. We met for ~1 hour and went over big picture ideas about the project.

Links: PDF1, PDF2

• After introductions, Daniel gave us an overview of PRIME
• It is a survey application, one that is focused on narrowing down a patient’s preferences on what type of medicine they would like to take in response to leukemia.
• He emphasized that UX is a top priority, mentioning that the software needs to be easy to navigate, use, and most importantly to get started.
• He prefers we have 1 link into the website and 1 link, and to “containerize” the web app so that in the future, it can be moved from server to server very easily without losing security.
• He gave us 2 PDFs (see top of post) that explain the prototypes/mach ups that he and his team already have on hand for us to reference.
• One of these PDFs has a diagram that shows the entire lifecycle of the program, very helpful.
• Some smaller things he mentioned: Assistive technologies, white labelling everything, we can pitch things to him whenever we want to.

---

Link: https://unc.zoom.us/my/louielu

• Talked about our meeting with the client.
• Louie liked our questions, but wants us to focus on getting a proof of concept/user stories ASAP so that we can actually start putting something together.
• Read HIPPA Compliance from UNC for like 5 minutes soon.
• Need to have our proof of concept on the front page of the website by this weekend.
• Also need user stories in deliverable by this weekend.

---

We reached out to our client to set up a meeting. We got a reply back after a few days, and are hoping to meet Tuesday 01/31/2023 at 10:30 AM.

---

link: https://unc.zoom.us/j/5893679107
code: 589 367 9107

• We want to do a website – but the client mentions APP. App may be more difficult, but we have to stay open to it if thats what he wants.
• There is a prototype mentioned, so we need to ask the client about the prototype and to what extent the prototype.
• REACT is what we want to use, and to pair it with typescript, maybe ESLint and Husky (for Linting and GitHooks).
• We may want to use A.W.S towards the end with HIPPA compliance.
• We have a wide range of experience, and all open to learning new things.
• Questions for client. We have some written on our google doc, but we also want to ask about the 5 points (really 4 without HIPPA guidelines).
• When we talk to the client, we should think about the definite, perhaps, improbable. HIPPA may be something that’s required for the app to be used at all.
• Stotts possibly said that HIPPA compliance isn’t as important.
• May need 2 sign ins, one for provider and one for patient. However, we need to keep in mind that older folks may be using the app and to keep that as simple as possible (maybe look at existing systems).
• Coach mentioned concurrency (and functional questions) – how quick the app works and communications, how many people are going to use the app at a time, general speed. need questions for that.
• Structuring meeting with the client – introductions, general questions, user stories, functional specs.
• Regular meetings with team – Wednesdays after class (in person if we have class, Zoom meetings if we do not).
• Roles – figure it out more when we meet the client.

---

We had our first Coach Meeting today with Louie. Here’s what we went over

• Went over agile, and what Louie will be doing for us each meeting and each week as our coach
• First order of business is to schedule a meeting with our client in the next week and a half
• We need a project description, project proposal/plan by the end of next week
• From Louie’s perspective, HIPPA compliance will be our biggest challenge
• He says to ask about the 5 points with the client (what does real-time mean, what is BWS and how should we research it, etc.), as well as UI questions. Focus on the first 4 in the first meeting.
• In the proof of concept, thinking about HIPPA may not be critical, but the final product would need to be (in other words, HIPPA isn’t something we need to discuss with them early).
• We need to discuss when we will deploy the software and how, if it is on our side or their side in the deploying process.
• Louie’s final suggestion: play with Trello to keep organized, maintain a Kanban Board. Up to us whether we use GitHub, Bitbucket, etc. Linting and GitHooks can also help us keep our code clean.

---

Our weekly coaching meetings will be held on Tuesdays from 9:30 AM to 10:00 AM here.

---

Our team was given a project – PRIME. The description can be found here.