soc-se-bot
commented
11 months ago Team's Response
As indicated in the duplicate issue, setting 0 as the index yields an invalid format since it is indicated that the index must be positive. Only after that condition is met, then the application check for valid values, in this case index of 100 is invalid.
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
Error message could be more specific for index 0
When index 0 is used it shows invalid command when instead it should probably show invalid index.
Invalid command:
Invalid index:
[original: nus-cs2103-AY2324S1/pe-interim#240] [original labels: severity.Low type.FeatureFlaw]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
Hi tester. It is indicated in the output that the index must be a positive integer. Hence, the formatting error raised in the first screenshot is valid since 0 is not a positive integer. As per the UG under Features notes, the app checks for format first before checking the validity of values:
For your second screenshot, since the format is accurate (13 is a positive integer), the application does not raise a formatting error. Since the index is out of range, an invalid index error is raised. As such, the output that you observe is intended.
Items for the Tester to Verify
:question: Issue duplicate status
Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)
- [x] I disagree
Reason for disagreement: The original bug deals with the spec command.
This issue deals with edit command.
Since one can be fixed independently of the other (since you're dealing with 2 different commands and different command parsers), they are not duplicates (as per the module website).
Prof has also justified this in the forum that this should not be duplicates as fixing one does not automatically fix the other.
## :question: Issue response Team chose [`response.Rejected`] - [x] I disagree **Reason for disagreement:** Dear Team, While I understand your explanation regarding the technical process of command validation, I believe that the inconsistency in error messaging for the edit command with different indices still presents a user experience issue that should be addressed. 1. User Understanding and Clarity: From a user's perspective, the distinction between an 'invalid command format' and an 'invalid index' is not always clear, especially when the only variable changing is the index number. Especially If I as a Com sci student wasn't aware even after reading your user guide, then i think its highly likely that Users such as head nurses may not be familiar with the underlying validation process and might expect consistent feedback regarding the nature of their error. 2. Intuitive Error Responses: For better user experience, error messages should be as intuitive and informative as possible. Even though the command is technically failing at the format check stage when index 0 is used, the message could still guide the user more directly. For instance, indicating that 'index 0 is invalid' provides clearer guidance and reduces potential confusion. 3. Consistency in User Interface: Consistency in the application's responses to user inputs is crucial for user-friendly interfaces. When a command fails due to an invalid index, whether it's 0 or 1000, the error message should ideally be consistent in informing the user about the nature of the mistake. This helps in setting the right expectations and aids in learning the correct usage of the application, esecially for non tech savvy users like head nurses and medical workers that have very little time to debug your application when on duty. 4. Aligning with User Expectations: As per the User Guide, while commands are first checked for their format before the validity of the inputs is considered, the error messaging should still align with common user expectations. In the case of index-based errors, users typically expect feedback related to the index itself, not the command format. Given these points, I suggest that the error messaging be revised to provide more consistent and user-friendly feedback. This would enhance the overall usability of the application by making it more intuitive and aligned with typical user expectations. Additionally, I'd like to highlight the guidance provided by the professor regarding the handling of bugs. A rejection of a bug should be reserved for cases where the bug is deemed irrelevant or unnecessary to address, both in the current context and in the foreseeable future. However, in this instance, the failure to provide accurate and contextually appropriate feedback directly impacts the user's ability to learn from their mistakes and hinders the user to understand the application (as more time is needed to understand the application).  Therefore, this issue is undeniably relevant and should not be rejected  Furthermore, in line with the professor's guidance on handling bugs, it's important to consider the practical implications of issues, rather than dismissing them based on technical correctness alone. The professor emphasizes that bugs should not be rejected unless they are clearly irrelevant or unnecessary to address in the product, both now and in the future. In this case, the issue at hand is directly relevant to the user experience. Providing accurate and contextually appropriate feedback is fundamental to software usability. It's not just about what the application technically achieves, but how it communicates its actions to the user. The discrepancy between the user's expectation and the application's feedback is a valid concern that affects the ease of use and overall user satisfaction with the product. Considering this perspective, **the issue should not be dismissed as inconsequential or irrelevant**. Instead, it should be acknowledged as a genuine area for improvement, in line with the goal of enhancing user experience and interface intuitiveness. Adjusting the feedback message to more accurately reflect the application's state is a straightforward yet impactful change that aligns with the principles of effective software design and user-centric development.
## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]
both commands have invalid index as error but inconsistent - confuses user