aditig0305 / pe

0 stars 0 forks source link

Unable to add a valid name input #8

Open aditig0305 opened 2 weeks ago

aditig0305 commented 2 weeks ago

It is a common standard for some names to have entries such as "s/o" and "d/o". It means son of and daughter of. However, both of these inputs are not allowed due to various reasons, one being that "s/" is a valid parameter prefix. "d/o" is not allowed because the name parameter itself does not accept such inputs.

Screenshot 2024-11-15 at 4.47.21 PM.png

Screenshot 2024-11-15 at 4.49.35 PM.png

nus-se-bot commented 2 weeks ago

Team's Response

Thank you for your feedback! We appreciate your understanding of our design choices.

In our application, we have chosen to restrict names to alphabets and spaces for simplicity and to ensure consistent functionality. While we understand that some cultures or countries may have special characters in names (e.g., hyphens, apostrophes, and tildes), introducing these exceptions could complicate the system and create inconsistencies in behavior.

If we were to allow the slash (/) as an exception, we would need to account for other commonly used special characters in names across different countries. For instance:

  1. Hyphen (-): Used in many French and Chinese names (e.g., José-Luis), and in some cases, it’s also a part of compound surnames or first names.

image.png

  1. Apostrophe ('): Common in Irish names (e.g., O'Connor) and some French or Spanish names.

  2. Comma (,): Seen in names like José~Miguel in Spanish or Portuguese cultures.

Allowing the slash (/) would create the need to permit these characters as well, which could increase complexity both in terms of validation and compatibility with various naming conventions.

We aim for simplicity and uniformity in the user experience at this stage of development, and by restricting input to only letters and spaces, we maintain consistency while avoiding potential errors or inconsistencies caused by different cultural norms around special characters. And most importantly, it ensures simplicity.

We hope this explanation provides clarity. Thank you for understanding, and please feel free to reach out with any further feedback or suggestions!

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

Incorrect handling of input for edit name of an existing contact to include the symbol

Describe: When trying to edit the name of an existing contact to include like s/o.

Steps: Edit the name of an index with a name input including the / symbol.

Expected: An error message on invalid input for name as it is disallowed.

Actual: image.png

Potential issue: Disallowing s/o in a person name because / is used as a command delimiter can cause a major problem if the input is expected to match the legal name of the person.


[original: nus-cs2103-AY2425S1/pe-interim#3318] [original labels: severity.Medium type.FeatureFlaw]

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

Thank you for your feedback! We appreciate your understanding of our design choices.

In our application, we have chosen to restrict names to alphabets and spaces for simplicity and to ensure consistent functionality. While we understand that some cultures or countries may have special characters in names (e.g., hyphens, apostrophes, and tildes), introducing these exceptions could complicate the system and create inconsistencies in behavior.

If we were to allow the slash (/) as an exception, we would need to account for other commonly used special characters in names across different countries. For instance:

  1. Hyphen (-): Used in many French and Chinese names (e.g., José-Luis), and in some cases, it’s also a part of compound surnames or first names.

image.png

  1. Apostrophe ('): Common in Irish names (e.g., O'Connor) and some French or Spanish names.

  2. Comma (,): Seen in names like José~Miguel in Spanish or Portuguese cultures.

Allowing the slash (/) would create the need to permit these characters as well, which could increase complexity both in terms of validation and compatibility with various naming conventions.

We aim for simplicity and uniformity in the user experience at this stage of development, and by restricting input to only letters and spaces, we maintain consistency while avoiding potential errors or inconsistencies caused by different cultural norms around special characters. And most importantly, it ensures simplicity.

We hope this explanation provides clarity. Thank you for understanding, and please feel free to reach out with any further feedback or suggestions!

Items for the Tester to Verify

:question: Issue duplicate status

Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)

Reason for disagreement: [replace this with your explanation]


## :question: Issue response Team chose [`response.NotInScope`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]