soc-pe-bot
commented
5 months ago Team's Response
autocomplete suggestions is still from the full contact list and is not filtered according to the find result.
It is stated in the UG that autocomplete works by using all the data stored in the app:
The autocomplete feature autocompletes a parameter or command, based on the current command box input and the current data in TAPro.
The UG did not claim that autocomplete will narrow down its autocompletion based on previously executed find commands, or the currently displayed contact list.
Furthermore, the user is suggested to use the find command to identify the nusnet id of the student, which you have. However, in most realistic scenarios, a TA will rarely have more than 3 students with the same name. Hence, this fails outside of normal use case.
This issue only inconveniences a small group of TAs wanting to autocomplete based on the currently displayed contact list.
Consider the other case in which the user finds by name and wants to autocomplete based on the full data available, your implementation would result in inconvience for the user, as this is another valid use case.
I believe that if autocomplete filters by what is shown, it would be also inconsistent in it's use, and could lead to greater confusion and unintuitiveness for the user. So, your statement that "This makes the product less convenient to use" is not entirely correct due to this reason.
Implementation and documentation wise is not easy, as we also need to consider this alternative use cases when implementing this, and being clear and concise in our explanations in our documentations due to the unintuitiveness of this, which takes a lot of effort, for low value, so not in scope.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement: After more thought, I would like to raise the severity of this feature flaw to Low instead of just VeryLow. My reasons are below:
The bug report is not about what the ug claims to do, but what the current implementation might be lacking (feature flaw).
Suppose the TA wants to search contacts using Chinese surnames, this would then be a valid use case. (command Chinese surnames such as Tan, Tay, Toh, Chan...)
this listed use case, in my opinion, is the actual rare use case. If the user is narrowing down the search space, why would he still want to auto complete from the full data, which can potentially consist of much larger amount of info than what he is looking for.
The team could have placed this in the future dev plan.
Thus I disagree with the dev team's decision to place the bug report in NotInScope given the bug report points out a valid concern.
This makes the product less convenient to use but still useable, thus very low severity.