nus-se-bot
commented
1 day ago Team's Response
The MMM in d MMM yyyy refers to a 3-letter representation for month (i.e. Jan, Feb, Mar). It is possible you were confused since the other MM month formats use digits. However, months cannot have 3 digits, so it is assumed that MMM must refer to the 3-letter representation.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: The User Guide specifies that the d MMM yyyy format is supported. However, this format is uncommon for date representations and can cause confusion to users, especially when they are not explicitly guided to use 3-letter months. The other date formats (yyyy-MM-dd, MM/dd/yyyy) are widely used and intuitive. However, the addition of d MMM yyyy without sufficient explanation or examples creates inconsistency in the feature's usability. If the format is meant to require a 3-letter month, this should be explicitly highlighted, possibly with examples like "1 Jan 2023". Apart from that, common date formats typically expect two-digit days (11, 12, etc). The ambiguity in this format leads to misinterpretation, as users naturally associate d MMM yyyy with dd MM yyyy which is a correct format.
The issue lies in the format not being intuitive enough for the target audience, resulting in users assuming it is a typo or misunderstanding the expected input. This is especially critical as date input is a fundamental aspect of adding an event.
When I attempted to use the feature, my natural interpretation of the provided format d MMM yyyy was dd MM yyyy because the dev team might have typo on the date format. My natural assumption was to input dates as dd MM yyyy (e.g., 01 08 2023) However, the system did not accept these inputs, causing me to think the feature was broken.This misunderstanding caused unnecessary trial and error before realizing the need for 3-letter month representation. This violates usability expectations for users, as the date format should be unambiguous and align with common date conventions. The mismatch between user expectations and actual implementation makes this a Feature Flaw, as the feature does not adequately solve the problem for users expecting a more standard or flexible date format.
This issue causes confusion, hinders user adoption, and wastes time due to trial and error. It can lead to users believing the feature is broken or poorly designed, which significantly impacts the application's perceived reliability. This is not a documentation issue or user misunderstanding but a Feature Flaw, as the feature fails to meet user expectations and causes confusion. The inclusion of a clearer explanation or additional flexibility would enhance usability and better align the feature with user needs.
I have followed what written in ug they should accept d MMM yyyy but eventually I can't do that.
