parth-io / pe Goto Github PK

Although the UG does state "Tip: You can create multiple tags at once by just separating the different tag names
with spaces.", this by itself does not tell the user what the accepted format for a tag is.

It would be good to warn users that any whitespace preceding the arguments to the parameter is trimmed, to prevent confusion.

Steps to reproduce

1. edit 7 t=t
2. edit 7 t= t <-- has whitespace

Both throw the same error message that "Tag(s) do not exist: t"

No details provided by bug reporter.

Pre-req: 1 message exists

To reproduce:
Type m d 11111111111111111111111

Expected:
The error message should read "The message index provided is invalid."

Edit 'reminders.json' to have an invalid date as shown below.

From the UG, "If your changes to the data file makes its format invalid, Rapportbook will discard all data and start with an empty data file at the next run." But it is not at all clear that edits to 'reminders.json' will only invalidate the data for reminders and not for all the data including client data.

Why should the user be notified of any parsing errors in reminders.json, or why should any parsing errors from reminders.json invalidate all data?
Because the user will continue to use the app as expected. If there are many reminders, and if just one of them has an invalid date but is a really important reminder, the user will not realise that this important reminder is missing.

The data file name in the UG read 'rapportbook.json', which is not created at all

"Implementation
This section describes some noteworthy details on how certain features are implemented.
UI Design
Proposed Implementation"

The above is taken from the DG.
But this is confusing, as the "UI Design" talks about three things: desired endstate of the UI, proposed alternatives, and the current choice.

Instead of mentioning all 3 under "Proposed Implementation", a separate subsection called "Current Implementation" should be created to talk about the current choice. Then another subsection called "Alternatives considered" can talk about the other alternatives considered. Then "Proposed Implementation" should only talk about the desired endstate - the use of Material Design.

This will help reduce confusion on what is implemented, what are the alternatives possible, and what is the ideal implementation.

To reproduce, simply type help or press the 'Help' button.
In either case, on my computer, the Help window does not show up at all. Please view the screenshot and the screen recording for details.
Details of my set-up:
Linux parth 5.15.0-52-generic #58-Ubuntu SMP Thu Oct 13 08:03:55 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

video:https://raw.githubusercontent.com/parth-io/pe/main/files/13e2edeb-8678-49e9-9dab-1acdc20dd68f.mp4

30 Feb is an invalid date

1. Type reminder 5 d=Zoom meeting dt=22-30-20 11:00

Expected:
An error message to be thrown, as the user should at least be warned that he's making a mistake and that this date is not a valid one

Steps to reproduce:

1. Type add n=Laufey p=98980184 [email protected] a=123,Clementi r=

The parameter r= has no arguments, yet it is accepted. It is prudent to warn the user or throw an error message that this is meaningless input, and get the user to either remove the r= or add the remark.

Class diagrams are overused and hamper readability.

For example, for the "Show Command", it is not really clear why the inclusion of this class diagram is useful to the reader. The class diagram is not directly referenced in the description and is just left for the reader to read through without any full understanding of its significance. Furthermore, it does not even seem significant or useful, as I can just read the code to understand what methods are implemented.

Similar use cases such as create tag and delete tag.

Delete tag should reference create tag for clarity to reduce duplication.

Some context about the acceptable syntax should be provided in the UG.

For example, the requirement for clients' names is "Names should only contain alphanumeric characters and spaces, and it should not be blank" from the app itself.

But this is not stated in the UG

Steps to reproduce:

1. Edit the colleagues tag in 'data/addressbook.json' to be colleagsssues
   

2. Launch the app

3. 'Roy Balakrishnan' still has the `colleagues' tag even though it does not exist.

There are too many images in the UG for the tag commands. Each message shows a lot of detail about the other clients which is unnecessary and hampers the ability of the reader to scroll quickly in the UG.

What can be done better:
Each tag command has a different success message - perhaps just this message itself can be replicated in the UG instead of a screenshot of the entire UI.

For commands like tag remove 3 bff, the UI does get updated in such commands. But as we cannot see the previous UI, showing the updated UI for any comparisons is meaningless. Furthermore, the UI has details of other clients. It's best to just display the success message only in the UG.

I typoed when typing tag 10 tag-name and typed tag 0 tag-name instead but the error message is incorrect.

s