nus-pe-bot
commented
4 years ago Team's Response
Dear tester, thanks for your comment.
However, I think no matter what platform we use, it is not fair to request it to handle all of our mistakes. Also, even if we use the parsing function as addressbook, it is still possible for us to press enter accidentally.
Moreover, the interactive command prompt is one of our main features. Hence according to:
response.Rejected: What tester treated as a bug is in fact the expected behavior. You can reject bugs that you inherited from AB3.
we reject this issue.
Thanks again.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: I think it's hard for me to say what is the expected behaviour and what's not.
However, based on what I feel is that the app should handle all invalid commands. In other words, in the example I gave in my bug report, "qui" + "enter" should tell me that "qui is a invalid command", rather than registering the "enter".
In addition, the "enter" should just be an "enter", i.e if the app is expecting an "enter" and only an "enter" (as per the screenshot in the bug report), it will only register "enter"s and nothing else. If something else were to be inputted with the "enter", say "1" + "enter", or "addite" + "enter", etc, it would be registered as an invalid command instead of registering the "enter"
Also, I think in this case it's not fair to say that it's been inherited from AB3. This is because AB3 handles the inputs very different. AB3 uses prefixes as a way of keeping the command a one-liner, e.g "edit 1 p/91234567 e/johndoe@example.com". However, Study Buddy wants to get rid of that prefix complication by having to enter ever single command based on the output returned. e.g "edit", "1", etc.
Moreover, the issue i'm highlighting here is not "accidentally" pressing enter. It's accidentally keying in the wrong / invalid command, coupled with an "enter", causing the app to register the "enter" and proceeding with the current command rather than informing the user that the command inputted is wrong. It's understandable that it's hard to handle accidental "enter"s. It's also not about "handling all your mistakes" but rather abstracting it out to have that mistake handled, e.g the example in my third paragraph.
As such, I think this bug cannot be rejected as it's even though the same parsing and interactive command prompt might be used as in AB3, the way it's being implemented and used is different for both applications and as such is not "inherited from AB3"
I understand that simply "entering" would be more intuitive for a user. However what I realised is that any input other than the desired command, coupled with an enter would register it as an "enter".
for example:
Here I realised that i'm marking the wrong task as done, so i type "quit". however i spell "quit" wrongly. Instead i input "qui" + "enter". this registers it as an "enter" and marks the task as done.