Open GuanpengR opened 1 week ago
Users are unlikely to get the wrong idea because maintaining the order of the characters follows the intuitive way of searching. If order of the characters are not maintained, that would overly clutter the results and further confuse the user instead. For example, if users intend to look for the tag CS1231S
and enter 123
it doesn't make sense for tags like CS2103T
to appear. Likewise, users are unlikely to search for Amy
but are actually hoping to get the results Myra
and Mary
. A non-random search order is more intuitive for the user and is unlikely to cause any major issues.
Hence, we decided to reject the bug as it is the expected and correct behaviour from the user's point of view.
Team chose [response.Rejected
]
Reason for disagreement: The phrasing of the UG is in such a way that:
armin
so searching an
returns armin
These combined will give the impression that the order of the characters do not matter as well. It would be much clearer to the user if it is stated that a
and n
are present in order in armin
.
A counter example:
If the user were to search for a name or tag that they could not spell correctly in the middle, where if they were to want to find Christopher
.
User enters Christhp
or Chhp
because they remembered the spelling wrongly and would like to use this character match function to help them find the correct person because they know the characters are present but cannot recall accurately the order.
The User will not be returned with Christopher
but may only be returned with other names.
For the find command, the given example of find an returns armin (characters a and n are present in armin) gives the user the wrong idea that as long as the characters I search for are in the name, the name will be returned. However, the order of the characters matter where find na will not return armin as a must be before n.