You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Many equipment trainers are regular members with no special privileges besides equipment authorization. When they use the /membership command, they are greeted with a modal that asks "What do you want to do?" that has an empty select field. When they click on it, they see that they have one capability from which to choose.
This is suboptimal UX and unnecessary friction.
When we handle MembershipOptionsModal, we should check the options length before we post the view. It may be as simple as delegating the return value to the handle method of the modal associated with the only option. There may be some complexity there; I haven't explored that yet.
The text was updated successfully, but these errors were encountered:
It won't be delegated to the handle of the returned option, since that's what happens when you submit that option and at that point, we're at "what do we display". That's handled in this controller which really should be moved but I'll get to that later. It creates a new MembershipOptionsModal and then uses the trigger id of the request to open it. We can call getOptions on that modal and it'll get the valid options for the current user. If there's one return value, we can call that.
There are some caveats to this, though. I did have "Cancel my membership" enabled and then disabled it when we added the "cancellation reason" field request. We can remove that entirely, but just thinking through the logic if that was the only option available, we'd cancel their membership. We could and should have the basic UI/UX idea of "nothing changes without confirmation" (and wouldn't you know it, past me made CancelMembershipConfirmationModal). If we did have that still enabled as an option, a member would run that, see "Are you sure you want to cancel your membership" and conclude "I can only cancel my membership using this".
Here's what I think some good options are:
Have it pre-selected as the option you're going to go with so you just hit "submit". The benefit to this that I like is if you ever get a second item on that list, you won't be surprised to see the page AND you'll get the visual feedback of "I need to select something"
Add a training command directly. /train or something. Empty arguments brings up that form. If you at tag people in slack and give the names of equipment, maybe we can do some rough matching and auto fill those? Just a thought.
For just checking it off the list, I think the first option is best and it would benefit greatly from #42 .
Many equipment trainers are regular members with no special privileges besides equipment authorization. When they use the
/membership
command, they are greeted with a modal that asks "What do you want to do?" that has an empty select field. When they click on it, they see that they have one capability from which to choose.This is suboptimal UX and unnecessary friction.
When we handle
MembershipOptionsModal
, we should check the options length before we post the view. It may be as simple as delegating the return value to the handle method of the modal associated with the only option. There may be some complexity there; I haven't explored that yet.The text was updated successfully, but these errors were encountered: