nus-pe-script
commented
1 year ago Team's Response
It is unlikely that any individual will have such a long email or name, moreover, for emails, there is a maximum character limit, in which case it will fit our UI. So we are left with the consideration of the name. From the user's standpoint, in the one in a million chance an individual is really named that way, the user can always abbreviate the client's name. This is the expected behaviour of a user, as firstly, a user already expects that a certain limit exists for name lengths, and secondly, the user who has this particular client probably is facing this issue in many other areas (e.g. saving their contact name for whatsapp / telegram/ virtually any other application) and will have already thought to abbreviate as a workaround. Furthermore, if the issue is with identification, suppose there is a 1/1000 chance the user has a client with such a long name (already very generous) the chance a user would have more than 1 client with such a name is easily as small as one in a million (we of course here assume names are chosen independently). Hence we consider this behaviour something as user would expect.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: Good reasoning. I do agree to a certain extent. However, since you say for emails, there is a maximum character limit, why not impose them onto your application as well? I would accept if the response is changed to NotInScope instead of Rejected as this is a valid issue and could be worked on in the future.
After adding a very long name and email, I noticed that the name and email is truncated in the UI. In this rare event of having a long name or email although unlikely, it will be hard to identify the full name or email address of the user.