Errpr message when prefix/ is used as body of text

[shotnothing]

Reproduction:

1. addTxn 1 amt/12.3 desc/John owes me for our date/catchup tonight.

This fails as a date error. It would be better if there was a warning that made sure the user knows not to use prefix/ (v.s. the misleading bad date format) or even better, handle text around quotes.

[nus-pe-bot]

Team's Response

Thank you for your feedback!

As outlined in the User Guide, there is a clear section explaining how to handle the collision of different input parameters. Specifically, it recommends escaping slashes (/) in the input to avoid misinterpretation of parameters.

For example, the input provided by the tester: addTxn 1 amt/12.3 desc/John owes me for our date/catchup tonight

Should instead be written as: addTxn 1 amt/12.3 desc/John owes me for our date\/catchup tonight

We encourage users to follow the guidelines in the User Guide to ensure their inputs are processed correctly. If there are any further concerns or clarifications required, feel free to reach out. We’re always here to help!

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [x] I disagree

Reason for disagreement: Hi! Thank you for the response!

My apologies I have overlooked that point, I missed it out in the wall of text in that section.

However, I believe that this is a FeatureFlaw:

I believe that the error message is misleading and that this caveat being buried in a wall of text rather than being handled in the app or explained in the help text of each command is a flaw. This is something that I would expect to confuse the average user and potentially cause a lot of frustration.

The average user should not be expected to read through every point in the command format note (that isn't even adjacent to where the add, addTxn or edit, editTxn commands are in the UG) to find out about this behavior (or lack thereof). This behavior is particularly misleading as it is not obvious what the problem is, or where they should look.

My suggested fix would be any of the following:

• Put this down in the help text of each command where it is relevant (within the app and in the UG)
• Provide a warning that date/ is there
• Escape text bodies in quotes
• Disallow /

Any of these options would make this far clearer for the user, thus absolving the FeatureFlaw

severity.Low : A flaw that is unlikely to affect normal operations of the product. Appears only in very rare situations and causes a minor inconvenience only.

severity.Low has two components:

• Appears only in very rare situations
• Causes a minor inconvenience only

I believe that it is very easy for the average user to miss out this point in the UG due to how hidden it is, and that it is not seen anywhere else, not in the app command result itself nor the documentation for the individual commands. As such, I believe it more than satisfies the first component.

This error will also be frustrating as the user has a good chance of not knowing what causes the error due to the wrong/misleading error message, especially if the body of text they entered is long. As such, I believe it satisfies the second component.

As such, I believe that severity.Low is warranted as a FeatureFlaw. This feels like a planned enhancement buried as a caveat in a wall of text in the UG.

---