Ambiguity in indexing for certain commands

[hyc17003]

For filter command, it is explicitly stated that the filter command will always filter from the full list of companies.

However, there is no explanation for delete or edit, and readers may assume that the same applies for those, as it was not said explicitly. The opposite, however, is true, where delete and edit command takes the indices of the current filtered list, instead of the full list. For edit, it does say displayed list, but there could be greater consistency as readers may still wonder whether it is the main, unfiltered list that is displayed when list is performed, or the filtered list.

Hence, there is some ambiguity, which may lead readers to do a command for the wrong company that may be difficult to rectify.

[nus-pe-bot]

Team's Response

In our UG, we categorised our commands into Company Management Features and Company List Features as shown below:

The notes in find and filter are used to highlight that these are exception cases; to point out that those 2 commands cannot be used in conjunction with each other when managing the Company List. However, for edit and delete, they are Company Management Features that are understood to work on the displayed list. Furthermore, notes are used for additional information. If we were to put notes throughout the UG for the various commands to indicate whether they work on the filtered or unfiltered list, it would be too overwhelming for readers and the note section will no longer stand out, so that will confuse the readers even more as they can't identify the difference between all the notes.

As for the part on whether the user may be confused about whether the unfiltered list or the filtered list is displayed when list is performed, it was clearly stated that the full list of companies will be displayed.

Hence, there is some ambiguity, which may lead readers to do a command for the wrong company that may be difficult to rectify.

It is designed to be intuitive that edit and delete commands will work on the displayed list since these commands work based on indexes. Thus, there is no ambiguity, and we will be rejecting this documentation bug.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [x] I disagree

Reason for disagreement: I believe the team misunderstood my bringing up of list command - I was not implying the list command was ambiguous in what it returned, but rather referring to the 'main, unfiltered list that is displayed when list is performed' in pointing out the ambiguity of other commands. The aim was to enhance clarity of my report, so there would be no confusion about which list I was referring to.

I understand that these notes are to highlight the exception cases. However, they also stated that 'for edit and delete, they are Company Management Features that are understood to work on the displayed list.'. I believe that while this may be understood for them, but it may not necessarily be understood by users. I think it is indeed plausible for the company management feature commands to still operate on the main, unfiltered list, as is the case for other apps I have tested. Additionally, this was a design decision, and is not necessarily intuitive for all users, which would be the target. If users misunderstand and unintentionally make a change to the wrong company, deleting it or editing it and not being able to remember what the previous data was, it could prove to be challenging to rectify.

As such, I do believe this remains as a documentation bug. It does cause quite a major inconvenience, if it affects the user. However, upon further reflection, I think this lapse in documentation could affect less users than I believed. Thus, I am considering this documentation bug as low, instead of medium.

---