soc-pe-bot
commented
4 days ago Team's Response
It is stated that not every nitty-gritty details need to be included. For users putting in "S/O" or "D/O", they are expected to know how "S/O" and "D/O" roughly work in names, or at least be able to refer to the customer's name when inputting the name. Choosing to put an example for all these specific types of names (e.g. S/O, -, ') may end up resulting in a lot of examples due to the large range of types of names.
Hence, no example was included for such specific cases.
Users can interpret from our UG how S/O and D/O can be used and should be in upper case as per how "S/O" and "D/O" normally operates in real-world scenario, which is naturally capitalized. (also, as stated earlier, they are expected to know how "S/O" and "D/O" roughly works)
Hence, this response is rejected.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: While I understand that users are expected to understand "S/O" and "D/O" conventions from common usage, providing an example would not only enhance clarity but also improve the usability of the UG. Users should not have to rely on assumptions about real-world norms when inputting data, especially when "S/O" and "D/O" are exceptions to the general rules for NAME. Including an example would preempt any potential user errors or confusion, ensuring a smoother user experience.
Additionally, while not every detail needs to be specified in the UG, exceptions to constraints, such as "S/O" and "D/O," warrant clear guidance because they deviate from the standard alphanumeric rules. This can be achieved without overloading the UG by including a concise example.
Lastly, regarding case sensitivity, the current UG does not explicitly specify whether it is enforced. Without clear documentation, users may not know if lowercased entries like s/o or d/o would be accepted. Clarifying this explicitly in the UG would eliminate ambiguity and ensure alignment between user expectations and application behavior.
User is only made aware of case sensitivity based upon incorrect input.
States "S/O" or "D/O" is accepted,