UI Design - Renew / Resubmit / Upgrade / Retry NR as staff

[sienna-oldaccountdontuse]

Visual Design Comps

https://invis.io/RE11CKWXCZ2K

Design Notes

• Modal box size increased so that when the user navigates to the next "screen" the sliding animation overall is smooth.
• Moved the primary action button as the right most button in a set (As a result, Confirm Name Request screen's button order should also change; see updated comp in the link.)
• Updated Confirm Name Request window design so that the affirmative action button as the right most button in a set.
• Staff Payment step now has a context as to what the staff is trying to accomplish: I.e. Priority Upgrade, Request Renewal, or Name Request Resubmission.
• Staff Payment step primary action button label is now "Submit thing" where "thing" is one of Priority Upgrade, Renewal, or Name Request.
• Since Retry Payment flow applies to all three types of actions, both the Staff Payment step title context and the button label should reflect the action being retried.
• Resubmit screens now has "Make this a Priority Request ($100)" checkbox so that there is both visibility and control over the priority flag at the time of resubmission consideration. This part is covered exclusively in #8204, but mentioning here as it is related.

[forgeuxGH5]

Is this for Renew or Resubmit? Title and blocking UX ticket mismatch...

[sienna-oldaccountdontuse]

I think this is just the design for staff to pay for a renew. 2 weeks before the NR expires, you can pay $30 to extend the expiry date. @forgeuxGH5

[forgeuxGH5]

Can staff "Resubmit"? I'm wondering if we should consolidate all of the staff payment tickets into one. We noticed there was at least one other staff payment place when looking at the priority upgrade payment flow (Retry payment)

[yuisotozaki]

• NR Renew should be available 14 days before expiry date and the user keeps the same NR number. NR Renew should not be available ahead of 14 days before expiry or on or past expiry date. [EDIT: Updated with Sienna's input re #8092]
• NR Resubmit should available within 30 days of expiry and the user gets a new NR number. NR Resubmit should not be available before expiry or beyond 30 days after expiry. UI Design for this part was completed in #7951.

[sienna-oldaccountdontuse]

@yuisotozaki I have an update, we just defined 8092 which will change the window to "renew" from 5 days to 2 weeks before expiry.

Just noticed @lmcclung moved it back to "new issues", are we moving forward with this or are we waiting for staff to approve?

[severinbeauvais]

@forgeuxGH5 @tlebedovich

As I have started work on 7811 and 7828, can I get an inkling of the design ASAP? (Final design can proceed concurrently.)

Sliding tab as in the payment modal?

[yuisotozaki]

Attaching the Upgrade modal here for review @forgeuxGH5 @tlebedovich Design is based on existing Confirm Name Request modal.

[screenshot removed]

I'd like to chat again about how quick review processes for my deliverables until I'm up to speed with being able to deliver what dev team needs. I'd like to use this ticket as a good spot to course correct output before diving into other screens.

[tlebedovich]

hi @yuisotozaki - there is any existing redesigned Upgrade to Priority modal I had already created - should be in that Sketch file I gave you if it's not, let me know), looks like this:

Then for Staff, when they click the Continue to Payment, the screen would slide sideways and show the Staff Payment model (also in that Sketch file), which looks like this - except the "Submit Name Request" button would be specific to the request, aka "Upgrade to Priority" versus "Submit Name Request" and we'd need to decide if we'd keep the "Exit Payment" (which takes users back to the first screen - which doesn't seem super helpful in this flow), or if it's just a "Cancel" button which cancels the upgrade and closes the modal:

[yuisotozaki]

@tlebedovich Forgot about the sketch file. Thanks! Removing screenshot from my previous comment.

[tlebedovich]

@yuisotozaki - To note: the upgrade payment modal I included above is a revised one for regulars users (with intro text geared towards users) - but I don't think it's been implemented yet, and that text isn't needed for Staff, so the Staff version could use that modal same design, but just remove the instructional text (since it's not implemented yet anyway). So basically, you just have to final these little details and the flow between these two modals for the staff "Upgrade Priority" part of this ticket. And then do the same for the other parts.

[severinbeauvais]

NR Renew should be available 14 days before expiry date and the user keeps the same NR number. NR Renew should not be available ahead of 14 days before expiry or on or past expiry date. [EDIT: Updated with Sienna's input re #8092]

NR Resubmit should available within 30 days of expiry and the user gets a new NR number. NR Resubmit should not be available before expiry or beyond 30 days after expiry. UI Design for this part was completed in #7951.

Both of these are business rules that the namex API needs to (or already does?) implement, ie, the API specifies which action buttons to display.

Question: do these 2 items affect any text in the UI?

[tlebedovich]

@severinbeauvais - those two items are in separate tickets so I assume would be sorted out outside of this UI Design ticket for Yui.

[yuisotozaki]

@severinbeauvais I hope this gives you a direction for now - I'll attach the updated mockups when the button labels are figured out.

The two bus rules I mentioned controls the visibility of the "Renew Name Request" and "Resubmit Name Request" buttons. As such, the effect to text would be titles of the modals and the final button to indicate to the staff user whether or not they're renewing or resubmitting.

Thanks for bearing with me as I onboard to the design process!

[severinbeauvais]

Thank you very much, Yui and Tracey!

I now have the bulk of the pages/functionality implemented. Let me know any final title/button/wording changes. I will pass it by you (Yui) before I commit the changes.

PS I am implementing tickets 7811 and 7828 -- neither of these refer to "reapply" -- is that a separate issue then?

Cheers, Severin

[tlebedovich]

@severinbeauvais Design is not finished for these (7811 and 7828 all fall under this UI design ticket which Yui was just assigned and needs some time to get up to speed with his first ticket). So Yui will be posting his designs here for all when done. ps also tag me on the UX Assurance when any are ready to review.

[yuisotozaki]

Take 2 for the designs for Upgrade Priority, Renew Request, Resubmit Request, and Retry Payment. For quick review: @tlebedovich @forgeuxGH5 @janisrogers

Take note that in case of Retry Payment flow, right now the user is taken directly to PayBC, but we want to intercept that with the Staff Payment screen to give options to the staff. Does this sound right @Sienna-Blumstengel ? TL that is correct @yuisotozaki

The affirmative action button (e.g. Submit this, and Renew that) should be placed on the left hand side of the secondary actions (e.g. Close/Exit Payment) in this set of screens. The button set are centred horizontally unless there is a destructive option (e.g. Cancel Name Request) in which case affirmative and secondary buttons are grouped and right justified while the destructive option is left justified.

Upgrade Priority - @yuisotozaki there will be a staff and non-staff version of this upgrade priority screen, so please also include the staff version which should have that instructional text hidden (staff doesn't need it, only regular users do).

- @yuisotozaki - the button for staff payment screen here should say "Upgrade Priority"

• The background UI screen for the for upgrade priority and staff payment should be the same summary screen view that has the upgrade priority button (or if its easier, just crop out the background so its not confusing)

Renew Request

• @yuisotozaki The background UI screen for the for renew request and staff payment should be the same summary screen view that has the Renew button (or if its easier, just crop out the background so its not confusing)

Resubmit Request

• @yuisotozaki - for the Resubmit Name Request text - please add a comma before ", for a fee" and start the next sentence "This will generate..." on that same line, versus starting it on a new line. So its all one paragraph.
• In the background UI summary screen behind the modal, there it should only show three blue outline buttons stacked, which will be - "Resubmit Name Request ($30)" then "Download Receipts" and then "Download Results".
• The background UI screen for the for resubmit payment and staff payment should be the same summary screen view (or if its easier, just crop out the background so its not confusing)

Retry Payment

• @yuisotozaki - I think the blue button for this last staff payment modal here could be "Submit Payment", since at this point the name request has already been created.
• The background UI screen for the for retry payment and staff payment should be the summary screen view that has the Retry payment button (or if its easier, just crop out the background so its not confusing)

[severinbeauvais]

~Do you really want the Staff Payment secondary action text to be Exit Payment? Atm it is "Back" (to go the previous tab). This is consistent across all 4 or 5 similar dialogs.~

Update: This is answered below.

[severinbeauvais]

~Do you really want the first tab secondary action text to be Cancel? Atm it is "Close" so that it is consistent across all 4 or 5 similar dialogs. This is so there are not 2 cancel actions in this dialog:~

Update: This question is asked again below (on July 13).

[yuisotozaki]

@severinbeauvais Good questions. I'm moving the designs to an Invision board where the design team has a chance to review and align design directions before causing dev fishtailing.

[yuisotozaki]

Design set shared with UX team in Invision - awaiting team review. Once review is complete, I'll share the Invision link at the top of this issue.

[severinbeauvais]

Update: Resolved by comment below.

~Has anyone thought about what the Priority Request flag should be for a renew? I assume False since the client already has the NR and just wants to extend it.~

~What about the Priority Request flag for a resubmit -- should this be the same value as the original NR? Or False, since the old NR still exists (sort of)? Or does it need to be prompted, and if, how?~

[yuisotozaki]

I presume Priority Request flag for Renew should be false also since there is no staff member interaction.

For Resubmit, I presume false also since it's a new request. The user has the option to then press the "Upgrade Priority" if they want it prioritized again.

@severinbeauvais Please see Invision link at the very top. Design was peer reviewed and revised based on feedback.

[severinbeauvais]

~Depending on what is decided for "resubmit name request"priority, I may not be able to include the correct amount ($30 vs $130) in the action button, since I don't know the fees at that point in time.~

Update: Linda said to display $30 for now. The UI will display an updated amount if the user subsequently selects Priority.

[severinbeauvais]

For Resubmit, I presume false also since it's a new request. The user has the option to then press the "Upgrade Priority" if they want it prioritized again.

Yes but they will be charged a second service fee if they do it this way.

[yuisotozaki]

Ahh, good point. Additional buck fifty. @lmcclung ? Do we want to let user/staff "Resubmit as Priority"?

The resubmit screen should have "Make this a Priority" checkbox like the first time the name request is being created. Invision design to be updated.

[severinbeauvais]

~cc: @kialj876 @vysakh-menon-aot~

~... And what do we want done with the existing payment on retry, if the user is staff?~

~Currently the code does this:~ https://github.com/bcgov/namerequest/blob/ae1da6cd7e7aa9dda104ce524fbbc9e7d865c135/src/components/existing-request/existing-request-display.vue#L613

~But more to the point, on retry, the SBC Payment object has been created, and I don't think I (NR UI) can change it. So if a regular user tried to pay, "isPaymentActionRequired" is true. But if a staff is now trying to retry payment, what do we do?~

~And specifically, how does the Namex API know to handle this as a staff payment? Should this.createPayment() be called?~ https://github.com/bcgov/namerequest/blob/ae1da6cd7e7aa9dda104ce524fbbc9e7d865c135/src/components/dialogs/payment.vue#L234

Update: Per Linda, for now don't add staff payment to the Retry dialog. It is expected that staff will not retry payments on behalf of users; in this case, it is believed that staff would just enter a new NR.

[severinbeauvais]

Update: Resolved by comment below.

~What do you mean by "Exit Payment" here?~

~Note that, when creating a NR, this staff payment page secondary action is "Back", which takes you back to the payment details page. Shouldn't it be the same here?~

[severinbeauvais]

Retry Payment just got more complicated (due to payment handling, and updated UI designs). I was going to do it as part of 7811/7828 but now the change is too large, so I created #8197 to implement it.

[yuisotozaki]

@severinbeauvais That's supposed to be 'Back'. Thanks for catching that! Invision updated!

[severinbeauvais]

Update: Resolved by comment below.

~@yuisotozaki Should the first tab secondary action text be Close (instead of Cancel), to be consistent with the Confirm Name Request (ie, create NR) dialog? Eg,~

[severinbeauvais]

@yuisotozaki wrote:

The resubmit screen should have "Make this a Priority" checkbox like the first time the name request is being created. Invision design to be updated.

I created UX/UI design ticket #8204 to work through the reapply flow.

[yuisotozaki]

@severinbeauvais The Confirm Name Request page is considered a special case. The design team discussed this previously and landed on using "Close" as secondary button label for this screen since it already has the "Cancel Name Request" button.

[severinbeauvais]

Thanks for the explanation. I will update accordingly.

[severinbeauvais]

Modal box size increased so that when the user navigates to the next "screen" the sliding animation overall is smooth.

This doesn't work. Probably the animation should be disabled, but I haven't figured out how to do this.

[yuisotozaki]

Does the modal container simply accommodate to the content?

[severinbeauvais]

Does the modal container simply accommodate to the content?

Yes, but I can add a min-height to the content to make it taller.

But that's not the problem here. The problem is that Vuetify adds (in the background) an animation between tabs, which in this case is undesirable, and which I already spent time trying to disable but was unsuccessful.

[yuisotozaki]

If it's the sliding transition animation between tabs just like what we see now in testing between Confirm Name Request and Staff Payment in new Name Request creation, I think we want that. Can you confirm @forgeuxGH5 .

[forgeuxGH5]

yep - for staff payments we want it just like staff payment for an NR - slide to the payment options

[severinbeauvais]

Yes, the new dialogs use the same sliding tab animations.

The issue is that these animations appear to shrink the source tab and expand the destination tab, which makes the dialog appear to bounce/flicker. This appears unacceptable but I have not been able to disable that.

[yuisotozaki]

Oh yes - I've seen the bounce effect.

[severinbeauvais]

I entered 8239 to possibly investigate and fix this issue.