nichyjt / pe

0 stars 0 forks source link

Editing the notes file does not seem to be possible #9

Open nichyjt opened 1 year ago

nichyjt commented 1 year ago

Description

As per the course program constraint, data should be human editable.

However, when editing a clean (empty) notes.txt file with proper syntax input, the data will always be 'corrupted'.

Reproduction

I first created a bunch of valid notes data and exited the application.

For reference, this was what was on my file:

image.png

Following the syntax, I created a foo4 notes entry. No padding was added to the end of line 5

image.png

Upon load of the file, the program warns that it has been corrupted.

nus-se-bot commented 1 year ago

Team's Response

Thank you for your feedback regarding editing the notes.txt file.

I have carefully reviewed your feedback and would like to clarify that the issues you encountered were due to a misunderstanding of the behavior of the text editor you used. Upon attempting to reproduce the issue, I found that the foo4 note entry you created was not following the syntax, although it may appear to be the same as the previous entries.

The differences between foo4 note entry and other note entries can be seen in the provided screenshot.

Screenshot 2023-04-15 at 9.31.50 PM.png

You may also wish to view the screen recording for more details.

Reproduction: You can clearly spotted that the foo4 note entry does not follow the syntax, hence, corruption is detected.


video:https://raw.githubusercontent.com/nus-cs2113-AY2223S2/pe/master/files/f8f8ef73-39b2-4e58-b771-4604296e9781.mp4

The expected behavior provided your modifications adhere to the correct syntax:


video:https://raw.githubusercontent.com/nus-cs2113-AY2223S2/pe/master/files/0b21d03a-50f7-45f2-b13d-8059e5155594.mp4

I would like to point out that if you had followed the recommended steps and used a proper text editor, you may not have encountered this issue. It is important to ensure that the note entries are formatted correctly and meet the requirements specified in the program documentation.

Regarding the warning that the file is corrupted, please note that this is the expected behavior when the program detects that a note file is not formatted correctly. This indicates that the program is functioning properly and is designed to prevent data loss or other issues that may occur due to invalid note files.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: Thank you for the detailed response.

Unfortunately, there are a few issues with the response. Ultimately, the problem still falls in scope.

There is no human-editability guide in the User Guide

The team claims that:

if you had followed the recommended steps and used a proper text editor, you may not have encountered this issue.

I re-read the user guide carefully. There is no 'recommended steps' provided to edit the file. The 'tab' character constraint was only mentioned in the developer guide.

We cannot expect a user to know this since they are not developers. This will definitely cause problems when a normal user tries to edit the file.

Program weakly adheres to human editability constraint

It is not obvious that the spaces are tabs to the average user, even when using proper text editors like vim. Since no documentation was given in the UG, it is assumed that any reasonable user would know how to edit the file at a glance. This is not the case.

Some text editors also replace tabs with spaces - which was likely the source of bug in my case. I think it is reasonable to expect the user to use text editors that replace tab characters (like intellij). The different size of tabs (as shown by the team's examples in their 'proper text editor') is also misleading. I think it is reasonable that a typical user would be confused by the ambiguousness of the format.

Yes, it is possible for the user to correctly edit the file (I managed to do it after learning about the tab), but we cannot reasonably expect the average user to understand this intuitively due to the lack of documentation and ambiguousness of the tab format in proper text editors.

If the team had documented this in the user guide or used a less ambiguous delimiter (both are in scope for v2.1), this confusion could have easily been avoided and wont cause occasional inconvenience to the typical user, making this a medium severity bug which is in-scope.

I hope this clarifies. Thank you!