[view-expenses] Position of index hinders usage

[AndrewNguyen4]

Intuitively, the user would expect to find the index of each expense at the beginning of the line, e.g.

Category: Book
  1. Item: name, Amount: $10, Category: Book

The current layout of view-expenses hinders usage (it took me some time to figure out that these number are expense indices):

This is true especially if Category contains square brackets. For example, I may want to name some categories "book [1]" and "book [2]". In this case, the index number could easily be mistaken for part of the category.

[nus-pe-bot]

Team's Response

This issue is of very low severity instead of low severity because it is a cosmetic and layout issue. The flaw is purely related to formatting and presentation of the index numbers within the view-expenses output. It does not affect the actual functionality or data integrity of the application. The problem is about the placement of the index (at the end of the line) and its potential confusion with category names, especially if the category contains brackets. This is a cosmetic layout issue, not a functional one. There is also no impact on core operations Users are still able to correctly interpret the expenses, as all information is present. The indexes are visible, and the expenses can still be identified correctly. The user experience may involve minor inconvenience in understanding the format, but it does not hinder the user's ability to perform tasks such as viewing, editing, or deleting expenses. Moreover, there would only be minor and rare confusion. The confusion described (category names containing square brackets that might look similar to index notation) is a very specific and rare scenario. Most users do not name categories with square brackets, so this situation would not be commonly encountered. Even if this occurs, the user can still distinguish the indices from the categories by context. Therefore, given that this issue is unlikely to affect normal operations significantly and is mainly a formatting flaw, it aligns more closely with the definition of severity.VeryLow, which covers purely cosmetic problems that do not impact usage.

Items for the Tester to Verify

:question: Issue severity

Team chose [severity.VeryLow] Originally [severity.Low]

• [x] I disagree

Reason for disagreement: Definition of severity.Low : A flaw that is unlikely to affect normal operations of the product. Quote from your team's response: "Therefore, given that this issue is unlikely to affect normal operations significantly..."

Based on your response, I think your team acknowledges the nature of the problem, but is underestimating the severity of labels used in this course. If an issue causes any misunderstanding at all, it cannot be considered "purely cosmetic". My opinion is to keep the original severity.Low label of this issue.

---