Names that include non-alphanumeric characters are not accepted.

[yooplo]

Expected: Names like "Muthu s/o Richard" are expected to be accepted, as in the real world, there are many Indian people who has the "s/o" in their names

Actual: An error message was displayed and the name was not accepted.

To reproduce:
input this command "add n/Muthu s/o Richard p/98456 e/jonny@gmail.com a/yishun r/brUdder m/bza"

Would be nice to consider this case as well.

[nus-pe-script]

Team's Response

Thank you for bringing up this issue. We are aware that this is an existing issue and will work on this in the future versions to rectify the restrictions on the name to allow for special characters.

However, since FindingbrUdders is a casual contact application that does not strictly require you to save legal names, we believe that there are many workarounds to still add the person as a contact in our app. Additionally, we mentioned that names should not contain non-alphanumeric characters (whitespaces are also considered non-alphanumeric characters according to online definitions) in our User Guide and the error message to prevent the user from inputting such inputs. Thank you for finding this bug and we hope you can find common ground with us on this!

The 'Original' Bug

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

Name field does not allow special characters

How to reproduce: add n/Xin-Yi p/333 e/a@gmail.com r/brUdder m/cs a/a
Actual: Error - Names should only contain alphanumeric characters and spaces, and it should not be blank
Problem: Special characters such as "-" should be allowed as there are definitely a number of people in SOC (target users) with names containing them.

---

_{[original: nus-cs2103-AY2425S1/pe-interim#3832] [original labels: type.FeatureFlaw severity.Low]}

Their Response to the 'Original' Bug

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

Thank you for bringing up this issue. We are aware that this is an existing issue and will work on this in the future versions to rectify the restrictions on the name to allow for special characters.

However, since FindingbrUdders is a casual contact application that does not strictly require you to save legal names, we believe that there are many workarounds to still add the person as a contact in our app. Additionally, we mentioned that names should not contain non-alphanumeric characters (whitespaces are also considered non-alphanumeric characters according to online definitions) in our User Guide and the error message to prevent the user from inputting such inputs. Thank you for finding this bug and we hope you can find common ground with us on this!

Items for the Tester to Verify

❓ Issue duplicate status

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

• I disagree

Reason for disagreement: [replace this with your explanation]

---

❓ Issue response

Team chose [response.NotInScope]

• I disagree

Reason for disagreement: [replace this with your explanation]

---

❓ Issue type

Team chose [type.FeatureFlaw]
Originally [type.FunctionalityBug]

• I disagree

Reason for disagreement:

I feel that this should be classified as a functionality bug for the following reasons:

1. Behavior Differs from the User Guide
   The User Guide specifies that names "should only contain alphanumeric characters and spaces" but does not explicitly disallow common non-alphanumeric characters used in real-world names (like slashes, apostrophes, or hyphens). The rejection of "s/o" deviates from normal user expectations since names with these characters are not uncommon and do not violate natural naming conventions. This mismatch creates confusion for users trying to adhere to the input rules.

2. Legitimate User Behavior Not Handled
   Names containing "s/o," "d/o," or other cultural indicators are part of legitimate user behavior. Rejecting such inputs implies the application is not designed to handle valid real-world scenarios, leading to frustration for users who must modify or abbreviate names unnaturally.

3. Behavior Differs from Normal Expectations
   Rejecting names with "s/o" is counterintuitive because users expect a contact management application to accept a wide range of name formats, reflecting the diversity of human naming conventions. The error message further compounds the issue by failing to clearly explain why the input is invalid, making this a mismatch with standard expectations for usability.

If it were considered a feature flaw, the argument would center around whether the feature of "adding names" is incomplete or poorly designed for the target audience.
However:

1. The name input feature generally works and does not fail to achieve its primary goal.
2. The restriction on special characters is an edge case rather than a fundamental flaw in solving the stated problem.

As such I strongly feel that this issue is better classified as a functionality bug because:

1. It arises from unexpected behavior within an implemented feature.
2. It impacts the user experience negatively by rejecting real-world valid inputs.
3. It contradicts the app's intent of fostering meaningful and authentic connections.

---