Inconsistent output formats

[freshcabbage123]

Above screenshot is after executing find John

Whereas compareCalendars 1 3 5 gives the following:

Output formats differ across commands with some having punctuations and others not having any. It is very distracting to the user as I'm not sure if the output has been truncated or this is the end of the message. It is not just a documentation bug as it shows up within the application and i have to constantly refer back to UG if it truly does not have a punctuation or not.

[nus-pe-bot]

Team's Response

The lack of punctuation is a grammatical issue. This issue also does not hinder the user in any way, especially in the image shown where the user will be focused on the calendars that are being presented for comparison.

Additionally, as mentioned by the tester, the user can just refer back to the UG if they are unsure, which provides an abundance of screenshots for them to cross reference.

Nonetheless, the addition of the punctuation at the end of every command is a good suggestion that can be added in a future iteration of UniMate, but we believe there are enough resources provided to the user in the current iteration such that this was not the utmost priority for v1.4.0 compared to the other features that have been introduced in v1.4.0.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

• [x] I disagree

Reason for disagreement: The issue of inconsistent punctuation across command outputs is indeed within the scope of user interface and documentation quality. It directly pertains to the clarity and professionalism of the application. Inconsistencies in the user interface, including punctuation, can lead to user confusion about whether a message is complete or has been truncated. This interrupts the user experience and may cause unnecessary frustration, particularly if the user needs to repeatedly refer back to the user guide to understand the output.

While it may not technically hinder the functionality of the application, it affects the perceived reliability and can reduce user confidence in the application, which is significant from a user experience standpoint. As such, this was a design flaw by the developers in omitting the punctuation.

Moreover, stating that users can refer back to the user guide is not an optimal solution. The goal should be to provide a seamless experience where the need for such references is minimized, especially for something as fundamental as command outputs.

It could have been easily fixed, by just adding the correct punctuation which does not require much additional effort. You do not need to wait till the next iteration.

---

## :question: Issue severity Team chose [`severity.VeryLow`] Originally [`severity.Low`] - [x] I disagree **Reason for disagreement:** To demonstrate that the frequency of this punctuation inconsistency is high and justifies attention beyond a 'very low severity' classification, we can consider the following points: 1. User Interaction Frequency: If every command output potentially suffers from this inconsistency, it means the user is likely to encounter it every time they interact with the application. High interaction frequency with this issue amplifies its significance. 2. Documentation Reference Rate: The need for users to constantly refer back to the documentation to decipher command outputs suggests a high occurrence rate. This repetitive disruption can be detrimental to the user's efficiency and satisfaction. 3. Error Recognition: In the absence of consistent punctuation, users might repeatedly wonder if an output is complete or requires action, such as resizing the window to see if more text is hidden. If this question arises regularly, it indicates a pervasive issue. Since the issue of inconsistent output formats is prevalent throughout the UG, it is not just a bug of very low severity.

---