UX/UI - SPIKE: Field Validation Issues

[dimak1]

Find opportunities for field validation

Review what we have and meet with us to define what validations should be in place.
1) Formatting validations 2) Required field validation 3) Document upload - we aren't checking or validating that they uploading the correct documents.

Spreadsheet with validations create a POC and then Design to meet with PO BA

Group those validations by page And then move them to refinement

[mbertucci]

Roland also has a list @rstens to add to this ticket

[rstens]

1. Is the general screen background the correct color?
2. Are the field prompts the correct color?
3. Are the field backgrounds the correct color?
4. In read-only mode, are the field prompts the correct color?
5. In read-only mode, are the field backgrounds the correct color?
6. Are all the screen prompts specified in the correct screen font?
7. Is the text in all fields specified in the correct screen font?
8. Are all the field prompts aligned perfectly on the screen?
9. Are all the field edit boxes aligned perfectly on the screen?
10. Are all group boxes aligned correctly on the screen?
11. Should the screen be resizable?
12. Should the screen be able to be minimized?
13. Are all the field prompts spelt correctly?
14. Are all character or alphanumeric fields left justified? This is the default unless otherwise specified.
15. Are all numeric fields right justified? This is the default unless otherwise specified.
16. Is all the micro-help text spelt correctly on this screen?
17. Is all the error message text spelt correctly on this screen?
18. Is all user input captured in UPPER case or lower case consistently?
19. Where the database requires a value (other than null) then this should be defaulted into the fields. The user must either enter an alternative valid value or leave the default value intact.
20. Assure that all windows have a consistent look and feel.
21. Assure that all dialog boxes have a consistent look and feel.

Screen Validation Check Points related to Validation Conditions

1. Does a failure of validation on every field cause a sensible user error message?
2. Is the user required to fix entries, which have failed validation tests?
3. Have any fields got multiple validation rules and if so are all rules being applied?
4. If the user enters an invalid value and clicks on the OK button (i.e. does not TAB off the field) is the invalid entry identified and highlighted correctly with an error message?
5. Is validation consistently applied at screen level unless specifically required at field level?
6. For all numeric fields check whether negative numbers can and should be able to be entered.
7. For all numeric fields check the minimum and maximum values and also some mid-range values allowable?
8. For all character/alphanumeric fields check the field to ensure that there is a character limit specified and that this limit is exactly correct for the specified database size?
9. Do all mandatory fields require user input?
10. If any of the database columns don’t allow null values then the corresponding screen fields must be mandatory. (If any field which initially was mandatory has become optional then check whether null values are allowed in this field.)

Screen Validation Check Points related to Navigation Conditions

1. Can the screen be accessed correctly from the menu?
2. Can the screen be accessed correctly from the toolbar?
3. Can the screen be accessed correctly by double clicking on a list control on the previous screen?
4. Can all screens accessible via buttons on this screen be accessed correctly?
5. Can all screens accessible by double clicking on a list control be accessed correctly?
6. Is the screen modal. I.e. Is the user prevented from accessing other functions when this screen is active and is this correct?
7. Can a number of instances of this screen be opened at the same time and is this correct?

Screen Validation Check Points related to Usability Conditions

1. Are all the dropdowns on this screen sorted correctly? Alphabetic sorting is the default unless otherwise specified.
2. Is all date entry required in the correct format?
3. Have all pushbuttons on the screen been given appropriate Shortcut keys?
4. Do the Shortcut keys work correctly?
5. Have the menu options which apply to your screen got fast keys associated and should they have?
6. Does the Tab Order specified on the screen go in sequence from Top Left to bottom right? This is the default unless otherwise specified.
7. Are all read-only fields avoided in the TAB sequence?
8. Are all disabled fields avoided in the TAB sequence?
9. Can the cursor be placed in the microhelp text box by clicking on the text box with the Can the cursor be placed in read-only fields by clicking in the field with the mouse? mouse?
10. Is the cursor positioned in the first input field or control when the screen is opened?
11. Is there a default button specified on the screen?
12. Does the default button work correctly?
13. When an error message occurs does the focus return to the field in error when the user cancels it?
14. When the user Alt+Tab’s to another application does this have any impact on the screen upon return to The application?
15. Do all the fields edit boxes indicate the number of characters they will hold by there length? e.g. a 30 character field should be a lot longer

Screen Validation Check Points related to Data Integrity Conditions

1. Is the data saved when the window is closed by double clicking on the close box?
2. Check the maximum field lengths to ensure that there are no truncated characters?
3. Where the database requires a value (other than null) then this should be defaulted into fields.
4. The user must either enter an alternative valid value or leave the default value intact.
5. Check maximum and minimum field values for numeric fields?
6. If numeric fields accept negative values can these be stored correctly on the database and does it make sense for the field to accept negative numbers?
7. If a set of radio buttons represent a fixed set of values such as A, B and C then what happens if a blank value is retrieved from the database? (In some situations rows can be created on the database by other functions which are not screen based and thus the required initial values can be incorrect.)
8. If a particular set of data is saved to the database check that each value gets saved fully to the database. I.e. Beware of truncation (of strings) and rounding of numeric values.

Screen Validation Check Points related to Modes (Editable Read-only) Conditions

1. Are the screen and field colors adjusted correctly for read-only mode?
2. Should a read-only mode be provided for this screen?
3. Are all fields and controls disabled in read-only mode?
4. Can the screen be accessed from the previous screen / menu / toolbar in read-only mode?
5. Can all screens available from this screen be accessed in read-only mode?
6. Check that no validation is performed in read-only mode.

[mbertucci]

Alexis working on a spreadsheet for field validations

[rstens]

The Social Insurance Number (SIN) was created in 1964 to serve as a client account number in the administration of the Canada Pension Plan (CPP) and Canada's varied employment insurance programs. In 1967, Revenue Canada, now called Canada Customs and Revenue Agency (CCRA) Canada Revenue Agency (CRA), co-opted the SIN and started using it for tax reporting purposes.

The only legislated uses of the SIN are: Canada Revenue Agency, your employer for Income Tax reporting, banks (with some exceptions), Social Assistance programs, and a few other government and/or tax related agencies.

Algorithm Social Insurance Numbers and Business Numbers are validated via a simple checksum process. This SIN algorithm is commonly known as the LUHN algorithm or the mod-10 algorithm. It also happens to be used to validate Credit Card numbers among other things.

Let's use this fictitious SIN to demonstrate:

925 545 212

9 2 5 5 4 5 2 1 2 Multiply each top number by the number below it 1 2 1 2 1 2 1 2 1
9 4 5 1 4 1 2 2 2
Notice here that 5*2=10, add 1 and 0 together and get 1. If you get a 2 digit # add the digits together.

Add all of these digits together.

9+4+5+1+4+1+2+2+2=30

If the SIN is valid this # will be evenly divisible by 10.

30/10 = 3 so this is a valid SIN.

The SIN algorithm can be arranged to generate as well as validate.

Province first digit usage

The first digit of a SIN indicates province of registration.

1 = NB, NF, NS, PE (1 is also used for Business Numbers BN) 2 = QC 3 = Not Used? QC? 4 = ON 5 = ON 6 = AB, MB, SK, NT, NU? 7 = BC, YU 8 = Used for Business Numbers (BN) 9 = Immigrants & other temp SIN's 0 = Not Used

BN

Is identical to SIN but only starts with an 1 or an 8.

Or in code:

function validateSIN(sin) {
  // Remove non-digit characters
  sin = sin.replace(/\D/g, '');

  // Ensure SIN is exactly 9 digits long
  if (sin.length !== 9) {
    console.log("SIN must be 9 digits.");
    return false;
  }

  // Convert SIN to an array of numbers
  const digits = Array.from(sin, Number);
  let total = 0;

  // Loop through each digit
  digits.forEach((digit, index) => {
    if (index % 2 === 0) {
      total += digit;
    } else {
      const doubled = digit * 2;
      total += doubled > 9 ? doubled - 9 : doubled;
    }
  });

  // Check if the total is divisible by 10
  const isValid = total % 10 === 0;
  console.log(`Total: ${total}`);
  console.log(`Is SIN valid? ${isValid}`);
  return isValid;
}

// Example usage:
let str = "430-837-013";
validateSIN(str);

[atronse]

Here's the spreadsheet (draft) with validation rules- https://bcgov.sharepoint.com/:x:/r/teams/09399/Shared%20Documents/Product%20Team%20Chat/Field%20validation.xlsx?d=wd73427566b6148b48776b7c8682de8e9&csf=1&web=1&e=hstBhY Have a few questions for the product team, and I want to check in with design team tomorrow to check if address if captured anywhere else

[mbertucci]

what is our next step?