UI Design - Renew

[Kaineatthelab]

• Include flow for all changes and amendments

Visual Design

Security Agreement and Repairers Lien Flows
https://projects.invisionapp.com/share/VH11K6AFRDTS#/screens?browse

Cancel Modal
https://invis.io/9C11MC4QXPFS#/457570426_00-Renew-Cancel_Modal

Wireframes

Scroll down to the Renew section for static mockups
https://app.uxpin.com/edit/8887562#?id_page=140340701

Interactive mockup used for sprint review July 27, 2021
https://preview.uxpin.com/1348a94271171ee8e283ecf65f50b9cb4d5f8af2#/pages/140603350/simulate/no-panels?mode=

[jinghualicgi]

Same as change ticket??
Overlap with amendment, depending on the design, on hold

[tlebedovich]

@yuisotozaki @janisrogers

Notes From Kevin

• you can not change Trust Indenture (read only)
• you can not renew an existing infinite registration (So we should we not show the "renew" button in the table for items with Infinite renewals) confirm @janisrogers @yuisotozaki

[yuisotozaki]

Confirmed both points during PPR Requirement meeting with business. UXPin updated with these points.

[yuisotozaki]

Decision log around "debtor name verification" is captured in the Discharge UI Design ticket comment here.

[yuisotozaki]

Back to In Progress for visual design.

[tlebedovich]

@yuisotozaki - Can you remove the secured party notification statement from the renew comps as per Kevin's comments this morning -

"Verification statement is sent after a discharge or amendment, not renewal for secured parties (the way it currently works)."

[yuisotozaki]

☝️ Done! Secured Party notification box removed from Renewal mocks for both main mock and interactive mock.

[yuisotozaki]

Capturing a summary around "Expiry Date" from policy and legislation point of view here.

TL;DR version is that technically, "Expiry Date" value should display 12:00 am of the first day the registration is expired.

Jul 29, 2021, 5:20 PM Kevin Bauer
In Tuesday’s bi-weekly demo – e.g. mockup within ticket 7560 – we saw Expiry Date values being displayed with timestamps, e.g.: January 12, 2025 at 11:59:59 pm Pacific time such as in the screen shot below and I thought I saw similar information in a confirmation page after completion of the renewal, i.e. showing the post-renewal Expiry Date.

There are regulatory problems/challenges with displaying Expiry Date timestamp information this way that will affect ticket 7560 and potentially throughout PPR UI and report designs:

Summary: It is my understanding – I am cc’ing Kim and Amber for confirmation, and we should check with others – that the Expiry Date is the first day that a registration is expired, not the last day the a registration is effective.
If a registration is not to be for infinity, the term (period of effectiveness) is expressed in whole numbers of years between 1 and 25. For new registration reference PPSR 4(b) and for renewals PPSR 33(1)(c).
For how to calculate the effective period we reference PPSR 55 (1):
Calculation of length of registration

55 (1) For the purpose of calculating the period of effectiveness of a registration, if the calculation is from the day of registration or from the anniversary of the day of registration, a year runs from the beginning of that day.

(2) For the purposes of subsection (1), if the anniversary were to fall on February 29, the anniversary date is deemed to be March 1.

Because we calculate “from the beginning of that day [of registration]” the end of the period of effectiveness is not the same calendar date, but that date less one. For example, a one-year registration on 1 Jan 2022 is effective through 31 Dec 2022, not through 1 Jan 2022.
We want to continue to be able to describe the Expiry Date as the same calendar date, e.g. a 1 Jan 2022 registration expires 1 Jan 2023. This is how the BC PPR reports Expiry Date today. It would be a material change to redefine the Expiry Date to the last day of effectiveness, e.g. 31 Dec 2022 at 11:59:59pm.
Registration date timestamps are helpful because registration are effective from the time of registration (see PPSA 43(2)), but Expiry Date timestamps are less useful: they would effectively all be 00:00am. Arguably the greatest value in showing the Expiry Date timestamp is to express that it is measured in Pacific Time. [Personally, I think it would be preferable to have a single statement that “all date and time values are expressed in Pacific Time” rather than repeating the time zone value everywhere, but this is a design decision.]
The interpretation of Expiry Date as the first day of expiry measured from the beginning of that day also affects various other calculations for information that we display and rules that we enforce. An example is the 30-day rule for when a PPSA 35(7) (PPSR 59) re-registration can be completed -- a registration that expired on 1 Jan 2023 must be re-registered by 30 Jan 2023 (before the end of 30 Jan 2023).

~ Kevin Bauer, PPR & MHR Policy Consultant, BC Registries and Online Services
~ kevin.bauer@gov.bc.ca
~ Mobile: 902-824-1011

Jul 30, 2021, 7:53 AM Patrick Heath
Hi Kevin!

The current PPR application allows activity against the registration on the date of expiry. Any activity attempted after that day will result in the error message “Base Registration has already expired”.

As a user, I would interpret an expiry date as the last day you can do something. If the expiry date in the system is to be the first day that you cannot act on the registration, should we adjust the expiry date displayed to be one day prior to what the calculation results in now, and still allow the client to act on the registration until the end of that expiry date?

When the display of the expiry timestamp was presented to the business peeps, they mentioned that defining exactly when the expiry happens makes it clearer for the client. (and will ultimately result in less questions to them)

Thanks,
Patrick

Jul 30, 2021, 10:46 AM Patrick Heath
Hi again!

I checked Name Requests and that application includes the time with the Expiry Date – 12:01 am Pacific time. (so a Name Request expires at the beginning of the Expiry Date)

Personally, I’ve always found 12 am and 12 pm confusing – is it noon or midnight?

If we are to have the application not allow any activity against a registration at the beginning of the Expiry Date, this method would work (but could be confusing to clients). However, it will be different from how the current PPR application works.

Thanks,
Patrick

[yuisotozaki]

Asset Grooming Meeting Decisions

• Remove "Review the information in this registration prior to total discharge." message from the top.
• Keep "Conduct search to ..."

[forgeuxGH5]

Note that Name Request is changing the way expiry is displayed to be the end of the last valid day (so 11:59:59) because having something expire at the beginning of the day was misleading users.

https://app.zenhub.com/workspaces/entity-5bf2f2164b5806bc2bf60531/issues/bcgov/entity/8178

[yuisotozaki]

The decision from the business is to continue using 11:59:59 on the UI.

[tlebedovich]

@forgeuxGH5 - Please do a final review of the design comps and Court order hints
c/c @Kaineatthelab (might want to run court order hints by Kevin)

[tlebedovich]

waiting to confirm 500 or 1000 character counter for Court - Effect of Order field form @PatrickAHeath

FInal Decision is 500 is per designs