-
Notifications
You must be signed in to change notification settings - Fork 1
[MPDX-7828] Fix several UX issues with task modals #851
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
This pull request is automatically being deployed by Amplify Hosting (learn more). |
8c3d47e to
ef339b8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great! It adds a layer of simplicity to our fields. I had a few questions. The UI/UX looked great, but with a PR of this size, it's easy for me to miss something while reviewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're missing the activity === 'DONT_CHANGE' functionality at src/components/Task/MassActions/EditTasks/MassActionsEditTasksModal.tsx on line 188 - 191
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know the Don't change functioanilty is only used when editing items already set, but we will lose this functionailty. Maybe we can have a isUpdatingField prop which allows for the don't change functionailty.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing the "Don't change" option is intentional because Autocomplete already lets you click an X to clear the selection. If the user clears their selection, the autocomplete will be blank again and MassActionsEditTasksModal won't change the tasks' activity type. But let me know if there's a bug.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason I mentioned it is that I liked the don't change as it's clear what it does. It's fine to leave it out. Something which could be good further down the road, making the edit modals list out the changes the user is making. To ensure the user knows what is about to happen.
Changing title to "new title"
Updating action to "Call"
src/components/Task/Modal/Form/Inputs/ActivityTypeAutocomplete/ActivityTypeAutocomplete.tsx
Outdated
Show resolved
Hide resolved
src/components/Task/Modal/Form/Inputs/TagsAutocomplete/TagsAutocomplete.tsx
Outdated
Show resolved
Hide resolved
src/components/Task/Modal/Form/Inputs/TagsAutocomplete/TagsAutocomplete.graphql
Outdated
Show resolved
Hide resolved
|
The error is with the file |
Are you getting a test failure? I get that error locally occasionally. It probably needs a higher timeout. It usually works when testing just that file. |
This can be a different PR, could it be worth changing how it's testing the autocomplete address, so it doesn't need a 20-second timeout? such as mocking the predictions |
It will probably be in a different PR. I have an approved BC item for it. I believe that some of the tests are slow because jsdom emulating the DOM is slow, but I agree that speeding up the tests if possible is preferable to increasing the timeout. |
|
Awesome work! |
|
@dr-bizz Can I get a re-review on this? I added some more commits to address Scott's feedback in this comment. I didn't love having to patch the autocomplete dependency, but it was the only way I could get it to work since autocomplete doesn't expose anything about controlling the highlight. If Scott likes the date picker improvements, I'll modify the rest of the modals in the app, probably in a follow-up PR. Also, if you test, do it locally because I'm still trying to get staging to update. |
ed50bd6 to
ca57344
Compare
dr-bizz
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's looking great. I found some issues with it while testing it locally.
src/components/Task/MassActions/EditTasks/MassActionsEditTasksModal.tsx
Outdated
Show resolved
Hide resolved
src/components/Dashboard/ThisWeek/NewsletterMenu/MenuItems/LogNewsLetter/LogNewsletter.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this will be fine, as users will know to click outside of the popup, but we might have to revert this if users complain about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't love this change either, but Scott wants it to not close after selecting the minutes because he chooses AM/PM after choosing the minutes. If he chose AM/PM, then hours, then minutes, we could keep closeOnSelect enabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unless I'm mistaken, that example is from the v6 page. We'd have to upgrade @mui/x-date-pickers from v5 to v6 to use that component. I'm not saying we can't or shouldn't upgrade, just pointing that out that it will be a little more work. I think that new picker is a better interface though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I didn't see that
...ls/ContactDonationsTab/PartnershipInfo/EditPartnershipInfoModal/EditPartnershipInfoModal.tsx
Outdated
Show resolved
Hide resolved
|
@dr-bizz Could I get a re-review? I ended up reverting the changes that added support for year and time abbreviations because I couldn't get them working correctly. |
|
@dr-bizz OK this is now actually ready for review. Scott gave me permission to remove the calendar and clock dropdowns in the task modals so that we can add support for date and time shortcuts like "1/1/24" and "1pm". I was unable to get the shortcuts working with the desktop dropdowns. If he likes how it works, I'll refactor the other date and time components to use |
I think I'm a little confused. I feel like removing the Calendar date popups, removes a key part of the UX. Making it harder for users to enter the date. |
dr-bizz
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code looks great I had a few comments, but that is it.
src/components/Dashboard/ThisWeek/NewsletterMenu/MenuItems/LogNewsLetter/LogNewsletter.tsx
Outdated
Show resolved
Hide resolved
src/components/Task/Modal/Form/DateTimeFieldPair/DesktopTimeField.test.tsx
Outdated
Show resolved
Hide resolved
dr-bizz
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The fields and code look awesome! 🔥🔥🔥🔥🔥 I know how much effort you put into this. Great work.
I won't approve this until all input fields are updated, but overwise I would.
|
@dr-bizz The rest of the app uses the custom date/time pickers now. There will be one more to fix once Caleb A's preferences PR merges, but that will be trivial to add. |
|
@dr-bizz I migrated Caleb's new preferences date pickers. @caleballdrin In the most recent commit, I tweaked the preferences UI slightly when I migrated to my new custom date pickers. Can you look over that commit, run it locally, and make sure it still looks good? I mostly changed how we're doing the start and end date labels to be more Material-esque. |
dr-bizz
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You've used three different ways to verify if a value is correct or invalid and set it to null. Was that intentional?
src/components/Settings/preferences/accordions/MpdInfoAccordion/MpdInfoAccordion.tsx - L119
activeMpdStartAt: typeof activeMpdStartAt === 'string'
? DateTime.fromISO(activeMpdStartAt)
: null,
src/components/Task/Modal/Form/TaskModalForm.tsx - L115
completedAt: task.completedAt
? DateTime.fromISO(task.completedAt)
: null,
src/components/Task/Modal/Form/Complete/TaskModalCompleteForm.tsx - L95
completedAt: completedAt?.toISO()
src/components/Dashboard/ThisWeek/NewsletterMenu/MenuItems/LogNewsLetter/LogNewsletter.tsx
Outdated
Show resolved
Hide resolved
dr-bizz
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good on Local. Everything worked apart from the Newsletter completed on field
@dr-bizz The |
@canac The date pickers look great and work well! |
* Upgrade to @mui/x-date-pickers v6 * Support 2-digit years and omitted minutes * Use custom date and time pickers throughout the app


Description
There are other places that could use these new inputs, but that refactoring is part of a proposed tech debt item that will be addressed later.
Testing
Please specifically test keyboard usage for the task inputs and let me know if there's improvements to be made there. @caleballdrin I would love to get your feedback on that too.
https://jira.cru.org/browse/MPDX-7828
Checklist: