souluseless / pe Goto Github PK

Under the glossary, there is a grammar error or typo where there is a verb (predicated), when a noun (predicate) should be there instead.

In page 22, a sequence diagram was drawn for editAssignment. However, it is shown that something is returned from the Module class, even though there is no corresponding method (getter, modifier, etc) called of the Module class. It also appears that something is returned to the Model class from the UniqueModelList, despite Model not calling a method of UniqueModelList. This should not happen as returning from a function would indicate a returning of values to the original caller, not to another class.

No details provided.te

Using purely the name to uniquely identify a person may not be optimal, considering that there may be some people with a generic first name such as John, Alex.

This issue could be more pronounced for some users who might prefer not to store the person's surname inside RemindMe, which might cause a conflict earlier and much easier.

Commands used: add x2, with n/ parameter being the same, and different b/ parameters.

In page 11 of DG, the following was given:

The same was given in page 14:

The duplicate diagrams within the same section might cause some confusion for readers. Furthermore, the duplicate diagrams are unlikely to offer much value to help in the readers' understanding.

This is made worse by the mistaken labelling of the add command sequence diagram as the find command sequence diagram. Given that the "Find Feature" is directly underneath said diagram, the presence of this diagram, with its description directly above the header would cause significant disruption to the flow and understanding by the reader.

For the add command for the addition of an assignment, a past deadline can be added into RemindMe. This does not make sense for a reasonable user as it will be almost certain that a deadline of a past date would be an invalid input since users are highly unlikely to enter expired assignment.

Sequence of commands:

Prerequisites: have a module names CS2103; current date: 16/04/2021
Command run: add m/CS2103 a/test by/01/01/2020 0000
A reasonable user would expect this input to be rejected by the application.

Error message provided for an invalid command format might be slightly technical, given that the user profile indicated in the DG does not imply one with sufficient computing background to grasp the concept of an "unsigned integer" (DG only mentioned that the users are more comfortable with CLI over GUi - this may not necessarily mean that the user understands unsigned integer. For better clarity, it might be better to indicate that only positive integers are allowed.

In page 18, there is a sequence diagram for the delete operation, with the text so small that the reader has to zoom in significantly (>200% zoom) until the reader can effectively see the text on the sequence diagram. There could have been to much implementation detail as well, considering how UI-update methods and saving methods are also included even though the sequence diagram is mostly about the delete operation.

Furthermore, the Storage (I believe so) text in the light green box is in white. The contrast makes it nearly impossible for the reader to read, especially for colour-deficient people like me.

According the to the class definition of Storage.java linked in the Storage section, it appears that Storage extends RemindMeStorage and UserPrefsStorage. However, this inheritance is not shown in the class diagram. This could cause some maintenance issues should RemindMeStorage or UserPrefsStorage be changed in the future.

Given in the UG are multiple variants of the delete function. However, they are inconsistent in the parameters format, which could cause usability issues. For instance, deleting a user only requires the provision of an INDEX, while deleting a module requires the module name as an argument. This inconsistency could manifest into usability problems when users are on a separate tab (Module/Event), and thought that providing the index of a Module/Event would delete the Module/Event on that particular page when it deletes a Person in the Contact List when that list is not even visible at that point in time.

Furthermore, the error message of an invalid command format does not clearly indicate to the users of the multiple variants of the delete function. Users who might be too lazy to refer to the UG might mistakenly presume that delete is only able to take in an INDEX.

The lack of clarity of the error message might also lead to the aforementioned scenario to happen as well.

Currently, RemindMe accepts past dates as an argument for the exam date. However, for the typical user, this is usually not the case as the exam schedules would be provided ahead of time. Furthermore, a past date for an exam would indicate that the exam is already over. This makes the information entered moot. As such, a past date as an argument for the exam date should have been considered an invalid input.

Command Sequence:
Prerequisites: Presence of module named CS2103; current date is 16/04/2021
Command executed: add e/01/01/2020 0000

Given that a module might contain information about other important things (specific assignments), and how modules can be named very similarly to each other (e.g. SOC CS 210X mods), implementing a blanket delete of the module with the specified name might be dangerous for a user as a small typo error could cause the loss of the entirety of a module's information that the user might not have wanted to delete.

This could be improved by either adding a verification prior to the deletion operation, or include a check to verify if all assignments under that module is completed/deleted, in order to reduce the chances of accidental deletion

In the explanation for find feature (Step 6; page 16), the explanation for the checks done by the parse method is difficult for the user to understand. There appears to be a few contractions and/or missing information as well.

Given in the UG, the find command is able to take in 3 different prefixes (n/, m/, g/). However under Step 6, bullet point 1, sub-bullet point 1, it is written that the find command parser only checks for the 'm/' prefix, implying that the other 2 prefixes are not checked. This is clearly not the case.

The use of a negative predicate ("there isn't a PREFIX"), with a sub-bullets of positive sub-conditions such that the negative predicate is fulfilled is very difficult for the reader to follow along as well. It could be better if the positive predicate is listed instead (e.g. "PREFIX" must fulfill the following conditions).

There is also a minor grammar error in bullet 2 that relates to is-are after a plural verb.

In the NFR section, point 4, a single second was indicated as "one seconds" when it should be "one second".

I believe that this section of text is important to the understanding of how the add feature operates for a developer, as it indicates what is thrown when ArgumentMultimap fails. However, this section is cut off in the PDF, since that section of text is unable to scroll.

This issue also appears under the Find feature section (page 16). It can also be seen that there is a HTML tag present in the text box which appears to be mistakenly rendered.

This occurs a not insignificant amount of times throughout the DG.

In the add command, the a/ prefix was used to denote the assignment name.

However, in the edit command, the a/prefix was used to denote the assignment index, and d/ was used to denote the assignment name.

The same issue also appears under the done command, where the a/ denotes assignment index, but is given a completely different name (INDEX).

This would cause confusion to a typical user and cause unnecessary inconvenience as the user would have to take a moment to consider which prefixes to use given the command they wish to use. It might be better to have a unified prefix-to-parameter match across RemindMe.

This issue is made worse where the same parameter is denoted using a different names in different sections. The usage of NEW DESCRIPTION for an assignment under edit might cause confusion to the user. The typical user might be given the false impression that there was an additional description field available for then to add/edit for a given assignment. However, the DESCRIPTION (edit) and ASSIGNMENT (add) fields both point to the same thing under assignment