[JN-1088] Admin form UX improvements + new task type #922
Conversation
| meta: { | ||
| columnType: 'string' | ||
| } | ||
| }, { | ||
| id: 'givenName', | ||
| header: 'Given name', | ||
| accessorKey: 'profile.givenName', | ||
| accessorFn: row => row.profile?.givenName, |
There was a problem hiding this comment.
driveby fixes for browser console warning console.js:273 "lastLogin" in deeply nested key "participantUser.lastLogin" returned undefined.
| @@ -90,7 +93,7 @@ export function LoadedEnrolleeView({ enrollee, studyEnvContext, onUpdate }: | |||
| <div style={navDivStyle}> | |||
| <ul className="list-unstyled"> | |||
| <li style={navListItemStyle} className="ps-3"> | |||
| <NavLink to="." className={getLinkCssClasses}>Overview</NavLink> | |||
| <NavLink end to="." className={getLinkCssClasses}>Overview</NavLink> | |||
There was a problem hiding this comment.
driveby fix for "Overview" navlink always having the "selected" CSS applied to it
MatthewBemis
changed the title
There was a problem hiding this comment.
I ran into a couple strange bugs.
First, I wasn't able to save a response for a user when saving an admin form:
Screen.Recording.2024-06-05.at.9.28.26.AM.mov
I can only get it to save if it I hit the complete button, but it doesn't save in progress surveys.
Second, I could not replicate it, but I somehow saved a new version of an admin form and it ended up as a research form. I tried creating new admin surveys and creating new versions, but none of them exhibited the same behavior. Very strange...
| {/* @ts-ignore Link to type also supports numbers for back operations */} | ||
| <Link className="btn btn-secondary" to={-1}>Done</Link> |
There was a problem hiding this comment.
curious: is there a behavior difference b/w '..' and -1?
There was a problem hiding this comment.
.. navigates up one level in the route, -1 just goes to the previous page, wherever that may be. I had to change this because taskId is specified in the URL query params now, and .. causes those params to be stripped out, whereas -1 preserves them. I could have also kept using .. by grabbing the query params and passing them back in as a prop
There was a problem hiding this comment.
Ahh, very interesting. Thanks
|
DESCRIPTION (include screenshots, and mobile screenshots for participant UX)
From talking with Erin and based on feedback from demos, it feels like the initial v0 UX for admin form editing was trying to do two separate things:
As a result, this PR breaks the UX into two distinct flavors. To solve for the first use-case, participant-facing forms have the option to additionally be completed/edited by study-staff. For the second use-case, study staff have the option to create a "study staff" form which has the new survey type
ADMIN. These are displayed separately from the research surveys so they don't live in the same bucket of forms as the participant-facing forms. ADMIN forms have ADMIN tasks associated with them, which do not show up on the participant dashboard.This PR also adds an autosave indicator and adds an improved toggle for entering view/edit/print modes.
TO TEST: (simple manual steps for confirming core behavior -- used for pre-release checks)