nus-se-script
commented
9 months ago Team's Response
While it's true that searching for a common surname might yield a large number of results, it's essential to understand that the current feature was designed to allow for flexibility in case a user doesn't have the exact spelling, or wants to see a broader list of tutors with a similar surname. This flexibility can be beneficial in scenarios where users might not be sure of the complete name or want to explore options.
Additionally, the app was created with the intention of serving a tution coordinator handling 20-50 tutors. As such, the likelihood of encountering 1000 tutors with the same surname or name keyword will be very low.
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
find-t command does not work correctly
In my addressbook, I have 2 tutors named Lee Jun Hong and Lee Jun Ming. Inputting
find-t Lee Jun Hongreturns both of these tutors
While I understand that it was stated in the UG that this is intentional, I believe that this may cause future inconveniences for the user. For instance, if we have 1000 tutors with surname Lee, and I only wish to look for the particulars of Lee Jun Hong specifically. it would mean that I still have to sieve through 1000 different tutors to find his particulars.
Moreover, if a specific name was keyed in, I would believe that the user is intending to search for that exact matching name
[original: nus-cs2103-AY2324S1/pe-interim#4452] [original labels: type.FeatureFlaw severity.Medium]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
The search behaviour is designed as such for a few reasons (bolded in the explanation below).
While it's true that searching for a common surname might yield a large number of results, it's essential to understand that the current feature was designed to allow for flexibility in case a user wants to see a broader list of tutors. The search behaviour is designed to show the most number of results as possible, such that there is no chance that the person the user is searching for does not appear in the filtered list shown.
Additionally, users can leverage this behaviour to include more keywords in just one command. In a scenario where a tuition centre coordinator wants to find all tutors whose surnames are Tan and Lee,
find-t Lee Tanwould work. In your proposed implementation, this search result is impossible.Regarding your concern, the search behaviour was clearly documented in the UG as you pointed out. As such, advanced users in this case who are searching specifically for Lee Jun Hong can understand from the search behaviour documentation that inputting 'Hong' as the keyword would be more beneficial to them (fewer keywords, more narrow search). Thus, with current implementation of search behaviour, it is not impossible to return Lee Jun Hong.
The severity of this issue should also be lowered to Low, since it is rare that there will be 1000 tutors with the surname Lee.
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`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** For a bug to be considered low severity, I believe that it has to cause only minor inconveniences to the user and only happen in rare occasions.  However, I believe that the usage of the find feature should happen quite frequently. While the example stated in the original report (1000 cases of tutors with the surname Lee) is not likely to happen given the intended target user. However, I believe that the issue raised arises regardless of the number of tutors there is. Even for a tuition centre with 50 tutors (which is the target user group you have claimed it to be, although this was not reflected in the DG or the UG) **Taken from DG**
 **Taken from UG**
 it would not be improbable for it to have say, 20-30 tutors, whose surnames are Tan (given that that is a very very common surname in Singapore). Given this scenario, it still causes users inconvenience when trying to look for a specific tutor. Moreover, since it is likely that users will be trying to look for a specific tutor, and that most users will likely require this feature, the severity of this bug should be medium given how frequently users will use it, and how most users using this app should adopt the use of the `find` command. The inconvenience that this bug will pose is not "rare", as per the severity guidelines, nor is it a "minor inconvenience" for tuition centres with larger databases. Also, as stated earlier, it is likely that a user using the find command to search the full name of the tutor is indeed intending to search for that specific tutor. At the very least, I believe that there should be a feature that considers allowing users to search for specific tutors by their full name. The current implementation of `find` works more as a `filter`. However, since this is how you have defined that the feature `find` should work, I did not consider it a functionality bug but more as a "feature flaw".
Similar to find-t, find-s also displays all the tutors with Lee when I am looking for only Lee Jun Hong
In this case, there are only 8 schedules. However, in a larger set of data, there may be thousands of schedules to sieve through although I only want to see Lee Jun Hong's schedule
It would also be inefficient to use list-s [INDEX] to find that tutor's schedule if I have thousands of tutors to look through before being able to find his index.