jianyangg / pe Goto Github PK

Is there a missing "are" in this statement? For instance, "The .puml files are used to create diagrams in this document docs/diagrams folder."

Should this instead be java --version instead of java -version? There seems to be a missing hyphen. This seems to be a long hyphen instead. Tried copying and running this and it didn't work.

File name specified in UG is different from file names in the actual data folder.

I'm assuming this exporting of data file feature is such that someone else using Tran$act can launch the same data that I currently have with me. In that case, should it then be named the same as the data files in the data folder? This is also assuming the layman using the application isn't aware of the subtle differences in the data file name and isn't able to figure out why, when they get the exported data file from someone else, they aren't able to launch the files on Tran$act as well.

I note that your error message reflects that phone numbers should be at least 3 digits long. But suppose this app is to be used in Singapore and most other countries, phone numbers are longer than 3 digits (i.e., Singapore has 8-digit numbers). Allowing such a lax constraint for phone number might introduce typos when adding a staff, resulting in potentially flawed data that might slip past the notice of the user.

A more strict phone validation method will be good.

Input (note the phone number field):
addstaff n/John Doe p/932 e/[email protected] a/311, Clementi Ave 2, #02-25 t/friends t/owesMoney

I have scrolled to the bottom of the list, but not all details are shown. I can only see further by intentionally dragging down the command box sub-window to see the rest of the list. Not being able to scroll further was misleading in hinting that I'm at the end of the list when I in fact was not.

Medium severity because a long list is expected and users might think the list is shorter than it actually is.

Certain individuals may have non-alphanumeric characters in their names. The current application limits this by throwing an error message when i.e., John s/o Doe is used as the name in the addstaff command.

Command input:
addstaff n/John s/o Doe p/98765432 e/[email protected] a/311, Clementi Ave 2, #02-25 t/friends t/owesMoney

Output:
Names should only contain alphanumeric characters and spaces, and it should not be blank

No details provided by bug reporter.

Would adding a section to explain why references to "Person" still exists when it should be "Staff"? Might cause confusion to the Developer reading this as one might expect "Staff" and "Person" to be separate entities.

Staff shoudlnt be optional.
Transactions without a person tied to it should not be allowed in my opinion for better traceability. Missing money is a serious issue in startups so it's important to be able to tag a transaction to a staff.

![Screenshot 2023-11-17 at 5.09.31 PM.png](https://raw.githubusercontent.com/jianyangg/pe/main/files/7bf2b022-f871-42d5-a5ee-
5f16e0b31f5b.png)

There are occurences of missing codeblock throughout the UG, of which the following is one such example. This leads to inconsistencies in the UG, making it hard for the reader to determine if this is an actual command.

See the attached screenshot. Point 1 should have java --version in a codeblock instead of putting it as plain text.

I think this section was left from AB3. It still mentions the delete command that deletes a certain person from the addressbook when Tran$act is about deleting staffs and deleting transactions based off their IDs using delstaff and del. Might cause confusion to the reader. Same for add. This Proposed Implementation has outdated references to things from AB3 that are no longer relevant in your application.

Steps to reproduce:

1. Key in a wrong command
2. Key in a correct command

The messages returned are in the next immediate line and not separated clearly (i.e., with a newline). This affects the visibility of the error messages and messages in general as I'm unable to tell right away what the system is telling me about my most recent input.

Currently:

Invalid command format! 
addstaff: Adds a person to the address book. Parameters: n/NAME p/PHONE e/EMAIL a/ADDRESS [t/TAG]...
Example: addstaff n/John Doe p/98765432 e/[email protected] a/311, Clementi Ave 2, #02-25 t/friends t/owesMoney
New person added: Isaac; Phone: 92345678; Email: [email protected]; Address: Blk 456, Pasir Ris St 32; Tags: [marketing]

I would prefer if it was:

Error:
Invalid command format! 
addstaff: Adds a person to the address book. Parameters: n/NAME p/PHONE e/EMAIL a/ADDRESS [t/TAG]...
Example: addstaff n/John Doe p/98765432 e/[email protected] a/311, Clementi Ave 2, #02-25 t/friends t/owesMoney

Success:
New person added: Isaac; Phone: 92345678; Email: [email protected]; Address: Blk 456, Pasir Ris St 32; Tags: [marketing]

This FeatureFlaw might warrant a higher severity since it's quite a common issue to have error messages / for system to give feedback to users.

The error message when I input a date that doesn't exist is just Invalid Date. I did write it in the correct format and it might cause quite a big of confusion when the user doesn't know why exactly the input is wrong (i.e., date does not exist).

It'll be nice if you can annotate and draw boxes around the screenshots so that I know what exactly you are referring to. As it is right now, some inference is required for me to determine what the command box is, and what the output window is. May cause confusion to the reader.

Steps to reproduce:

1. Add a long name under the addstaff command.

Behaviour:
Name gets cut off when it got too long.

Explanation for flaw:
A long name will be cut off at the end of the UI. Sure, expanding the application window could help reveal more characters, but there's a limit to the screen size and a name long enough will still be cut off eventually.

Low because rare occurence of absurdly long names. Functionality because I'm suppose to be able to see the details of each staff if I want to but this issue is limiting me from that, especially if that piece of information has too many characters.

These commands, while intuitively, require a longer time to type and might introduce more typos in typing a command. Y'all can consider using shorter names such as clrtsc, short for cleartransactions or however you deem fit. If the screenshot doesn't render, look in UG under clearstaff and cleartransactions command.

As per title.

Was the file named wrongly? The UG specified 4. Double click transact.jar to start the app. The GUI below should appear in a few seconds.. But the actual file name was as shown in the screenshot attached. (We were told to run using java -jar during PE as well, so the UG deviates from the recommended way to launch the application).

In your UG, a key feature of exporting the data is such that one can do further analysis if needed. However, unlike your app which actually has more details such as name of staff, the exported csv file did not have the staff name, or the staff's details.

In the CSV file, there were references to "Person". What is a "Person"? Would it be a "Staff" instead?

Some ways of improving this will be to ensure that the naming convention in the csv file aligns with that used in your application, and that more details of each staff like their address, phone number etc can be exported likewise in a csv file as suggested by your User Guide.

It's definitely an interesting feature, but the implementation could be further improved.

Perhaps a minimum width for each column could be set such that the column doesn't disappear entirely from view.

Currently, I'm able to reduce the size of ID column such that ID data is completely obscured. An unknowing user may not realise why a column of data is suddenly "missing".

It says under Implementation that there are noteworthy details of features that are implemented. I only see Proposed features and no activity/sequence diagram of features that are actually implemented, which prevents me as a Developer from understand how you implemented the features currently existing in your application.

As per title. In my opinion, a table of content link should be at the bottom of each section minimally else a user will have to scroll quite a bit back to the top so that they can navigate to another section.

The format for date is unspecified in the UG and in the help message of the application.
For instance, I do not know if it's MM/DD/YY or DD/MM/YY. This might add confusion to the user. Since it's adding of transactions is quite a commonly used feature, I'm raising this as a Medium severity.

Some sections are in a darker shade of blue and it wasn't explained why that's the case. Are the deeper blue sections considered more significant than the rest? If so, should the rest then be in sub-headings instead? Might cause confusion to the reader of the UG.

Note the difference in colour between 2 and 3

The application did not have the actual transaction type data amongst other fields (as seen in the application screenshot, messages returned by the system) but the UG didn't reflect that. Did the UG mention more things than was supposed to be shown in the app?