Find Feature is flawed

[Mahidharah]

Find feature should not be a OR find, instead should be an AND find especially for name

Step 1. Added several John Names Step 2. Added a new John name (John Durairaj) step 3. Used the find command to specifically find John Durairaj step 4. Got results of all 5 john names, and john durairaj was not even the first one to appear, instead the last one

In this case, identifying attribute is name, since all other attributes allow duplicates among different persons.

Searching specifically will be done by name, and will be a major inconvinience to find an exact name when the first results are generic results.

[nus-se-bot]

Team's Response

No details provided by team.

The 'Original' Bug

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

find command resulting in many names appearing

I am trying to find a person called Roy Balakrishnan. I typed roy b to save time. But what i got is people with name roy or people whose name consist of the word b. if there are thousands of users, it will be very confusing. Or if i want to find a person called jake peter. There are thousands of people whose name consist of jake or peter. Instead of getting one person called jake peter, i get hundreds of people.

---

_{[original: nus-cs2103-AY2324S1/pe-interim#5536] [original labels: type.FeatureFlaw severity.Medium]}

Their Response to the 'Original' Bug

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

The behaviour of the find command is already specified in the UG. The expected behaviour could be achieved using find -sp n/roy, the feature flaw is not as severe as indicated. We agree the expected behaviour is may increase user experience and could be considered to be implemented in the future.

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)

• [ ] I disagree

Reason for disagreement: [replace this with your explanation]

---

## :question: Issue response Team chose [`response.NotInScope`] - [x] I disagree **Reason for disagreement:** The purpose of a find feature is to find a patient with an exact match to the name provided, unlike the find that has been implemented, making the find command flawed. For instance, we want to find a patient with the name C H Tan Aaron (as per name on NRIC). This will result in search results with names with C, names with H, Names with Tan and names with Aaron. Given that surnames such as Tan are very common and names like Aaron are also very common, this is problematic Moreover, it is intuitive for a user to type in details like names in more detail to find a closer match. Having fewer results by searching by the name Aaron, instead of the full name, C H Tan Aaron, is very counterintuitive. If such logic is implemented, staff will have to guess which is the least common part of the name, search according to that result, and scroll through to find the patient they are looking for. As such, a guide on how to search for a specific name should be provided in the user guide for this counterintuitive method of searching. Even then, I still believe the flaw will not be fixed, and the more intuitive AND find should be used, because users are better off not typing in an extra keyword to search, as it will only give them more results, resulting in a harder time to find a specific patient/specialist. The only use case for a OR find is for other unary attributes, such as age, locality, ect. For primary/identifying attributes (name in this case as only duplicate names are detected), an OR search for name. There are also performance implications to this search if there is a lot of data, and a OR search will have much more overhead in terms of time and space complexity compared to and AND seatch. The severity of this flaw should be medium in hindsight, and low is already lenient, in my opinion, due to the accuracy and precision issues, performance implications and user experience complications.

---