Mark command: complicated format

[nus-pe-bot]

The mark command format is very long and unintuitive. It is difficult to remember the different specifics like marking suppliers and marking deliveries. Such inconvenience is also not reduced by the UG.

How it could have been avoided

1. Clearer section on UG: The UG could have had a table with mark -s and mark -d, with the status labels that can be used for each. Suppliers and Deliveries have different status labels and this is not very clear unless one reads each mark command separately. It is also unclear as to why the mark -s command uses and all-lowercase status field, while the mark-d command uses all uppercase, making it confusing between the two. It is also easy to forget since they use the same command word mark
2. Using name instead of index: The workflow becomes more complicated with use of index, making the mark command format very long and overzealously checked. It is more intuitive for users to mark suppliers by active state by their name
3. Making status case-insensitive
4. Replacing generic "mark" keyword with more specific command keywords which update various status. ( may not be in scope but improves user experience)

---

_{[original: nus-cs2103-AY2425S1/pe-interim#2469] [original labels: severity.Medium type.FeatureFlaw]}

[vinc3leong]

Team's Response

Hi, thank you for raising up this issue. However, we believe that the UG has stated clearly the difference between the mark commands in separate sections and their different use cases. Furthermore, we believe it makes sense to have different statuses for suppliers and deliveries as they represent different entities, hence sharing a fixed set of statuses would not make sense in this case.

Additionally, we believe that the command is concise enough such that fast typers will be able to use it efficiently without compromising on the clarity of the command.

While we acknowledge that we could have made both commands have case-insensitive statuses as a future improvement, the UG has clearly stated the limitations for each command to the user, hence we believe that this bug should be a NotInScope.

Screenshot 2024-11-18 at 9.34.48 PM

Screenshot 2024-11-18 at 9.35.36 PM

Duplicate status (if any):

--