Explanation on HHmm not found in Error message and UG

[hazzle23]

User might put t/Sunday-1100-0100 because they don't understand that HH means 24 hours formatting.
And the error message and UG is not clear enough on this.
Moreover, the error message state that the range is 0000-2359. That means the input is still considered valid because both 1100 and 0100 is within the range.

Suggestion: Explain in UG that HHmm means 24 hours formatting.

[soc-se-bot]

[IMPORTANT!: Please do not edit or reply to this comment using the GitHub UI. You can respond to it using CATcher during the next phase of the PE]

Team's Response

Hi, thank you for your input. We believe this is not in scope.

We believe HHmm is universally recognized as a time format.

We believe that the current error message is well rounded enough for the user to understand fully what exactly is a valid input for the t/ prefix.

Referring to the help message that our app shows:

Schedule should be in the format of DAY-START_TIME-END_TIME, and adhere to the following constraints:
1. DAY should be a valid day of the week:
Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday
2. START_TIME and END_TIME should be in the format of HHmm
3. START_TIME should be strictly before END_TIME
4. START_TIME and END_TIME should be within the range of 0000 to 2359
5. There should be only one '-' and no whitespace in between the DAY, START_TIME and END_TIME

We felt that this is comprehensive enough for our target user (university undergraduates) to understand the format of HHmm,
especially since we have already stated that 4. START_TIME and END_TIME should be within the range of 0000 to 2359.

We believe that the nitty gritty details of how the format of t/SCHEDULE should be can be excluded from the UG, since we have explained it clearly in the help message in our application.

We believe that the help message should be read as a whole, instead of interpreting them line by line and trying to fault any single points for being incomplete.

Moreover, the error message state that the range is 0000-2359. That means the input is still considered valid because both 1100 and 0100 is within the range.

To response to this, t/Sunday-1100-0100 is a invalid input, especially since we have stated clearly in our error message that the START_TIME must be strictly before END_TIME

Of course, your suggestion is valuable to our team in terms of improving the user experience for UGTeach, and we will consider improving this in the future iteration, by reminding user that it should be of (24h format).

Items for the Tester to Verify

❓ Issue response

Team chose [response.NotInScope]

• I disagree

Reason for disagreement: [replace this with your reason]

---