nus-pe-script
commented
7 months ago Team's Response
Our find function was designed so that users could more accurately find the contact they were looking for. If the user was bad at names and does not remember the contact's name as mentioned, searching the substring and producing a long list of contacts may not help as well as the user will not be able to remember which contact is the one he or she is looking for.
As the issue states, "This is in the case where the user can only recall partial name of a contact and may not be sure about the exact wordings of the contact's name. Searching "DAV" to find "DAVID" or "DAVE"".
However, we feel this argument can backfire as well as what if the user has many contacts that starts with dav, or even multiple davids or daves. Searching with DAV would give a long list of contacts, in which the user will similarly not be able to narrow it down to the contact the user wants to find. Justifying with the case where "the user forgets the name of the contact" would also not render the change effective.
Hence, we believe this issue should be rejected.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: [Thank you for your response. In real-life phone contacts, finding people with keywords to match substring is widely implemented. It appears to me that the team's find function is narrowing down too much on the search area. Consider the case where we have:
- Davian Ang Kee Wee
- David Zhuang
- Mr Dave Lommen
- Pagador John David Balboa (Among other contacts in the app)
Suppose the user wants to find the information on the 3rd contact (Which is a real person's name), but the user only remembers that this person's name contained sounds like "dav" when pronounced. The current find/Dav would not produce any persons. The user has to keep figuring out the exact name of the contact, or have to list all persons and find one by one, or simply conclude that the 3rd contact is not in his/her contact list which is not the case. Contrastingly, if we can find contacts whose name contains "Dav" substring (case-insensitive), then the search area is focused to include the above contact list, which appears to be more user-friendly and streamlines the process of finding the right contact to check.
Therefore, I would be more inclined to believe that the team should consider implementing such a functionality. If the team wishes to maintain the current functionality of find command, then perhaps an additional command can be created to separate between searching Exact String matches and searching substrings matches. This would serve well for bring out the value proposition of the app and granting flexibility for users on how they would like to search for the contacts.
I hope this has provided more perspectives from a user's point of view. Thank you for your kind consideration and understanding.]
With the preloaded contact list, the following command is entered:
find n/DavThis is in the case where the user can only recall partial name of a contact and may not be sure about the exact wordings of the contact's name.
Expected: An error message saying that there is no such contact called "Dav" OR A list of contacts with name containing the "dav" as the substring (case-insensitive)
Actual: A message of "0 persons listed!". This might appear confusing to users who may have recalled wrongly the contact they are searching for, or could simply have made a typo. For example, "Daviid" or "Dave"
This may become frustrating for people who are not good at remembering names, especially in contexts where similar names are possible like "Jesslyn", "Jeslyn", "Jacelyn" "Jessline" and so on.