438/hmis editing framework

[timbot1789]

This PR:

Resolves #438

**1. Adds a basic UI framework for adding HMIS forms. Right now it only contains placeholder forms to demonstrate how forms should function and how they can be tested. The forms themselves will come in later PRs.

This framework also contains very little styling. I wanted to keep things basic so UI/UX could style things as they see fit.

Screenshots (if applicable):

Screencast from 10-22-2023 05:09:08 PM.webm

Additional Context (optional):

I chose not to use the MUI steps component here because I imagine this to be a display of a large amount of information a person can fill out over several sessions (or never fill out at all). So it didn't make much sense to me to say "housing info must be filled out before financial info." I wanted a layout that could give a suggested progression, while still letting the user jump to any form they want.

Future Steps/PRs Needed to Finish This Work (optional):

In a follow up PR, we will need to tie these forms to the pod itself. That will involve creating a new document on the pod, and creating a hook on the front end to access it.

[timbot1789]

With regards to the wording of things, I think we could change "HMIS Profile" to something like "Personal Profile". While under the hood, everything involved in this profile will be HMIS-related, I think don't think we need to expose normal users to it, similar to how we're limiting exposure to Solid.

Sure that sounds fine to me. Renamed everything to "personal profile." We will need to make sure that users understand the difference between the "personal profile" here and the "public profile" that's stored on the web ID though. Maybe "civic profile?" We'll need to futz around with the wording, but that doesn't need to be done for a while.

[timbot1789]

I take it we're not planning on using modals for these forms? Not an issue at all, just wanting to be certain. Since there are multiple consecutive forms, it probably makes more sense to not have to deal with a series of modals anyway.

Correct, I don't think a series of modals makes sense for the workflow I'm imagining here. Same reason why I didn't use the stepper component Scott suggested in the issue description. I'm imagining 2 main use cases:

1. A user is filling out their profile for the first time, and needs to be guided through it
2. A user has filled out their profile before, and needs to reference or update a specific part of it

Modals work for use case 1, but don't really work for use case 2. This UI mostly targets use case 2, while still allowing for use case 1. I wanted to focus on case 2 to also make development/testing of the profile easier. A dev won't want to go through a progression of modals every time they need to update a single value if they don't have to.

If we find we need a better flow for first time users, we can definitely add a stepper or series of modals later.

[timbot1789]

Actually, I think I like the name "Civic Profile." I updated the PR to that name. Take a gander and let me know what you think.

[leekahung]

Sure that sounds fine to me. Renamed everything to "personal profile." We will need to make sure that users understand the difference between the "personal profile" here and the "public profile" that's stored on the web ID though. Maybe "civic profile?" We'll need to futz around with the wording, but that doesn't need to be done for a while.

Yeah, the naming stuff could get pretty messy.

Think we could have something like "Account Settings" for the public profile. That way, it's like a user setting up things in their gmail account related only to gmail stuff.

Then we could move "Date of Birth" back out and move it into the hmis profile, so it's like setting up the personal information within the system.

[leekahung]

Actually, thinking about it again. Why not have this under the existing /profile route. I think we could make that work.

We could use /profile as a base route for the tabs and include what we have now for profile as one of those tabs (maybe something like /profile/account or /profile/user). So we can get 4 links under /profile.

And we can reroute the contact profile links to /profile/account/<other_user_webId> or /profile/user/<other_user_webId>

[andycwilliams]

Actually, thinking about it again. Why not have this under the existing /profile route. I think we could make that work.

We could use /profile as a base route for the tabs and include what we have now for profile as one of those tabs (maybe something like /profile/account or /profile/user). So we can get 4 links under /profile.

And we can reroute the contact profile links to /profile/account/<other_user_webId> or /profile/user/<other_user_webId>

I like this. It makes sense to me to consolidate routes when we can.

[timbot1789]

Actually, thinking about it again. Why not have this under the existing /profile route. I think we could make that work.

We could use /profile as a base route for the tabs and include what we have now for profile as one of those tabs (maybe something like /profile/account or /profile/user). So we can get 4 links under /profile.

And we can reroute the contact profile links to /profile/account/<other_user_webId> or /profile/user/<other_user_webId>

I want to separate the private profile and public profile as much as possible. It will be confusing enough as is for users to have two separate profiles. I don't want to risk a situation where a person accidentally puts confidential information in their public profile. Having them as forms right next to each other would definitely do that.

I think having one flow to edit the public webId and separate, distinct flow to edit confidential information is a good way to communicate their difference.

[leekahung]

I think having one flow to edit the public webId and separate, distinct flow to edit confidential information is a good way to communicate their difference.

Think that should be good. We could keep them as separate pages (one with the tabs like what is shown here and one with our existing profile page) and have the routes consolidated under /profile.