Team's Response

It is mentioned in the UG that only the last prefix will be parsed if user passes the same prefix.

Obviously, you have to retype the name multiple time because you're adding a different person and they will have different name.

If tester is referring to retyping the same event name, the tester could copy and paste the command addPersonToEvent ev/EVENT_NAME n/ and repeatedly paste the command, or use our alias/chaining commands.

There are several benefits in only allowing 1 person to be added. Namely that it is easier for the user to debug if the user types in the wrong command/name. It is also more user friendly as the command is simplistic in nature.

Since there exist an alternative, which can achieve the same outcome with similar (or even lesser) number of keystrokes (using alias or chaining or control a control c control v), the only difference is the cosmetic looks in terms of the string the user inputs.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

Suggestion: Allow the adding of multiple students to an event with command.

Although the application is meant to be fast for typists, it can be tedius using the addToEvent command over and over again to add students. Other applications could be faster in doing so.

_{[original: nus-cs2103-AY2122S1/pe-interim#5661] [original labels: severity.Low type.FeatureFlaw]}

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

Accepted that it could be better. However, we do allow for alias, and chaining as well as control a, control c, control v, thus the severity downgrade. Essentially we can achieve the same result with control c control v (with similar or even less key strokes if we use aliasing), and the difference is only cosmetic in terms of the input commands

Items for the Tester to Verify

:question: Issue duplicate status

Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)

[x] I disagree

Reason for disagreement: The team is trying to downplay their poor design decisions by saying they allow copy / paste and a command which new users might not be familiar to, excel allows copy and paste too and I just need to enter each member's name once into excel and tick boxes for attendance instead of copy pasting a command, typing their name for each member for each event. "It is mentioned in the UG that only the last prefix will be parsed if user passes the same prefix." The team is also trying to gloss over poor parser design, this parser design makes sense for contact details as only one such detail per field is expected, but for event where multiple members can be added in, only accepting 1 field is poor design.

Command format is also unnecessarily long and cumbersome, needing caps for some letters and being 4 words long. This command forces user to use it multiple times (once for each student) due to its poorly designed parser, along with its unnecessarily long and cumbersome command word, causes a great deal of inconvenience for users and excel could achieve the same purpose (a name list with blank headers for event name) for a fraction of the work.

Solutions mentioned (aliasing, chaining copy/paste) serves to alleviate the problem but a better parser design would have solved the problem.

"There are several benefits in only allowing 1 person to be added. Namely that it is easier for the user to debug if the user types in the wrong command/name. It is also more user friendly as the command is simplistic in nature.", I believe this decision should be left to the user to choose between wasting time keying 1 member per command or just putting all member in 1 command.

Also, since this event feature is designed for taking attendance during meetings/CCA, it is even more unrealistic for the one in charge to be typing each attendees name one by one, wasting every other members name and not participating in the activity instead of ticking their name off a checklist.

:question: Issue severity

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

[x] I disagree

Reason for disagreement: This is obviously not just a cosmetic issue and should not be VeryLow. I believe this issue stems from poor parser design and poor empathy with users and poses great inconvenience for a command that is used frequently and serves a core purpose of the app, thus I would also like to upgrade the severity to High, as this flaw makes the app impossibly cumbersome to use and I would rather use excel to achieve the same purpose.

Ongzl / pe

Adding person to event is unnecessarily cumbersome #8