nus-cs2113-AY2223S1 / pe-dev-response

0 stars 0 forks source link

Inconsistency in filter parameter #753

Open nus-pe-bot opened 1 year ago

nus-pe-bot commented 1 year ago

image.png

image.png

Although it was mentioned in the UG, similar functions having different searching behavior can be slightly confusing. I would expect the filter -id function to match at the beginning of the word too, similar to filter -address


[original: nus-cs2113-AY2223S1/pe-interim#729] [original labels: type.FeatureFlaw severity.Low]

malcolmang commented 1 year ago

Team's Response

Hello, thank you for your bug report!

As you mentioned, this is defined behaviour in the UG, with very clearly defined functionality differences.

For filter in address mode:

image.png

For filter in ID mode:

image.png

The differences are explained clearly in the DG:

image.png

In short, this behaviour is defined because address mode is used to narrow down filter results, as addresses can have multiple words. However, this behaviour for ID does not make any sense, because all IDs only have one word maximum and is already fairly restrictive, so it has a less relaxed matching logic.

The idea is that if you know you're travelling to Clementi Avenue 3, you can do filter clem ave 3 to get results closer to you, but if you were trying to look up a carpark ID you vaguely remember, you might think "It had an A somewhere inside...", in which point filter -id a is more useful than just matching a prefixing substring.

In conclusion, this is intended behaviour for the reasons mentioned above, as well as clearly labelled in the User and Developer guide.

Duplicate status (if any):

--