search

Quasant / pe

0 stars 0 forks source link

Unnecessary repetitions of prefix definitions #7

Open Quasant opened 1 week ago

Quasant commented 1 week ago

image.png

Across the student commands, attendance commands and assignment commands. There are certain prefixes that have been explained before and are duplicated. NAME, PHONE, STUDENT_NUMBER and DATES being some of them.

soc-se-bot commented 5 days ago

Team's Response

We thought this would enhance the user's experience since they would not need to scroll back and forth between tables to check the definitions of the prefixes. We apologize for the inconvenience.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: image.png

I appreciate the effort to enhance user experience. However, I am not convinced by the justification and wish to provide my reasons for why this might actually hinder the reader.

Firstly, your group separated the commands by Student, Attendance and Assignment, each followed by Student prefix, then Attendance prefix and finally Assignment prefix. This structure may lead a reader to assume that the prefixes are distinct for each category, rather than shared across them. For example, sn/ for students refers to student number while sn/ for assignments could refer to serial number of assignments. This would result in additional time spent by the reader to re-read the definitions of the prefix and perhaps even cross check between tables to see if there are any differences. Related to the hard to see what's similar and what's different point within CS2103 website.

Secondly, even if a reader already knows that the prefixes are shared, when new prefixes are introduced, there is a need for the reader to scan the prefix table again. In the screenshot of the UG provided in the original issue, the prefixes a/, d/ and g/ are new. Notice that a is actually in-between old prefixes. Without proper highlighting of new prefixes or a structured order to the prefixes, readers might miss out on new prefixes if they do not put in more effort to scrutinize the prefix table. This is also related to the last point within CS2103 website.

I believe the team should have considered alternative perspectives more thoroughly, especially given the acknowledgment of inconvenience within their justification. While the issue may not affect all users equally, it does pose a minor inconvenience for some, which is why I still maintain that this is a severity.Low issue.