bingsen0806
commented
2 years ago Team's Response
This feature is very opinion-based as there is no one correct design choice for such a feature. Our team is rejecting this issue because we have considered your suggestion previously and deliberately chose this feature design due to the reasons mentioned below.
Firstly, we have already restricted the month to 3 characters so you only type 3 characters (1 more character when comparing “dec” and “12”). Furthermore, tP constraint is that the product's target user is a fast typist. Fast typists are expected to know how to type with all 10 fingers simultaneously. Unless the tester types with 2 fingers, then typing an alphabet then a number would be slower, but if that’s the case whatever you type will be slow anyways, and the use of alphabets in dates would not affect you much.
Also, the intention of designing the feature this way is to reduce the chance of more serious errors (e.g. a librarian intends to type 10-11-2022 but types 11-10-2022 and both dates are valid so the system accepts it and the librarian didn’t notice because she’s typing fast). This is a more serious error because this error is silent (e.g. it fails without the user noticing). When designing features, there is always a tradeoff to make and in this case our team prioritize the prevention of silent errors because their have larger consequences (e.g. entering a wrong borrow date and resulting in the book loan much longer or shorter than usual, as compared to just typing one more character).
Duplicate status (if any):
--
The date input for borrow command is a Mix of numbers (dd, yyyy) and letters (MMM) which adds unnecessary complexity to the input. Months could have accepted numbers instead.
[original: nus-cs2103-AY2122S2/pe-interim#1475] [original labels: severity.Medium type.FeatureFlaw]