Closed mountiny closed 4 weeks ago
Current assignee @dubielzyk-expensify is eligible for the Design assigner, not assigning anyone new.
It looks like in some parts of the app we allow for it to be changed, but then once the value has changed we fade the push input (presumably to save the value on next available save opportunity). If this is a deliberate pattern, let's use that:
If not, we could also just fade and disable the push input until they're online again:
Keen to hear which behavior @Expensify/design think is right here.
The first option is Pattern B, we take the action optimistically and assume it succeeded only to show error if not.
But in this case we do Not want to allow user to take action on editing the type.
I think that we might want to let them navigate to the page but inform them they cannot take the action there. I think that would be cleaner
If we're using Pattern C here, this is what I see from the original design doc:
Pattern C - Blocked Form What: This pattern greys out the submit button on a form and does not allow the form to be submitted, and notifies the user of their offline status. Importantly, we do let the user fill out the form fields. That data gets saved locally so they don’t have to fill it out again once online. When: This should be used when we cannot allow the user to submit the form while offline. Example: SetPassword/ChangePassword
So maybe we just need to make all of the options on this page grayed out:
Also, that mock is slightly confusing - it shouldn't need a Save button if you access a list selection outside of a flow, right? So in that case, I think we'd just gray out all of the options and use the offline message at the bottom?
Yes that is right I think the Confirmation button should not be there in this flow
Agreed it doesn't need a confirmation button here. I like Shawn's suggestion to grey out the select list values.
Sound good to me.
Thanks team. Just to clarify for my understanding, if this mock is what we want:
...then doesn't that violate the rule in Pattern C?
Importantly, we do let the user fill out the form fields. That data gets saved locally so they don’t have to fill it out again once online.
Wouldn't we allow them to change it and grey out the push input which would become un-greyed when it's saved later?
Oh, actually.. isn't the whole point of why we have to use Pattern C here because we don't know which options to show in this select list without an API call?
We need to use the Pattern C when changing the card limit type page as to knwo what options can be shown, we need to know unapproved and total spend on the card.
So with that, why are we opening this select list? Rather, greying out the menu item like shown here but removing the right carets from the applicable rows:
Alternatively, we'd need to push to a full page blocking form with the "You appear to be offline" message, which might be the most consistent tbf.
Ahh, yeah that also seems fair. I don't mind if we have a full offline screen or fade the push input. Both should be clear either way though the latter saves them a click.
we'd need to push to a full page blocking form with the "You appear to be offline" message, which might be the most consistent tbf.
That does seem like the most consistent option... like for example, when you are offline, we don't disable the button to add a bank account, we just give you the full page "we can't do this while you are offline" screen once you actually get there after pressing the button to add the account.
But when you go to Workspaces -> Categories -> and change any value, we do what I described above where we fade/disable the push input once the value is saved locally. Which I think is a closer example than starting a new flow (e.g. bank account)
Right, but that's different from Tom's point here:
Oh, actually.. isn't the whole point of why we have to use Pattern C here because we don't know which options to show in this select list without an API call?
As in, we need online connectivity to even know which options we can show to the user for the limit type. Does that sound right @trjExpensify ?
Right, I see. Then that would make more sense then 👍
As in, we need online connectivity to even know which options we can show to the user for the limit type. Does that sound right @trjExpensify ?
Yep, exactly. That's why we're using Pattern C and not Pattern B.
So cool, we just need to use the standard "You appear to be offline" full page form here, @mountiny.
Ok sounds fair and safe option, thanks everyone 🙇 cc @koko57 @allgandalf @DylanDylann @VickyStash for visibility, the API is not ready for this one yet but we will need to use pattern D
Not overdue, Sir Melvin
Any update? Should this still be daily?
Any updates?
Problem
We need to use the Pattern C when changing the card limit type page as to knwo what options can be shown, we need to know unapproved and total spend on the card. More details here.
This means we cannot really let to user change the limit type when they are offline. We will create a new API command that will fetch the relevant data when this page is opened to decide what options to show. This however means we cannot let the user make a change until this data is fetched.
Solution
Should we update how this page is shown when user is offline, ideally letting them know that the they can change the type only when they are online?