Open rohit0718 opened 3 years ago
We do not think that the error message is misleading. Timings should indeed be in a HH:MM format. It is clear that 24 is not a valid input for HH. Furthermore, users should have learnt about the 24-hour format in school or at the very least be exposed to the 24-hour format in their clocks, phones or computers.
Team chose [response.Rejected
]
Reason for disagreement: "It is clear that 24 is not a valid input for HH." Not sure where exactly this is clear when there is no mention of valid inputs for the HH and MM terms in the User Guide or in the error description. In fact, the terms HH and MM themselves are not defined anywhere in the User Guide. It is likely that users not from a computing background do not understand these terms, causing inconvenience for them as they have to search up what these terms mean.
"users should have learnt about the 24-hour format in school or at the very least be exposed to the 24-hour format in their clocks, phones or computers.". I feel that this an unnecessary assumption to make about the users of the application. A short description of valid inputs for the HH and MM terms would suffice for the error message here. Furthermore, just because users are familiar with the 24 hour format also does not mean that they understand what HH:MM means.
Team chose [severity.VeryLow
]
Originally [severity.Low
]
Reason for disagreement: This is not a cosmetic bug and is very likely to affect usage the usage of the application. If a user who is unfamiliar with the HH:MM format uses the application, they will be confused by the error message. Not only are the HH and MM terms not defined anywhere in the application or User Guide, but the bounds for each of these values are also unspecified.
Although the timings are indeed provided in a HH:MM format, it states that it does not follow the format properly. Might want to consider instead telling the user that the provided timings are beyond the bounds supported (e.g. HH can only be 00 - 23)