ella-e / ped Goto Github PK

Command Involved
clear

Observation and Suggestions:
The clear command will erase all the data entries in the application immediately without any confirmation. This could be a very dangerous attempt as there is also no way to undo the command or retrieve all the datas if there is no copy of the data file are preserved before. Therefore, how do you think of adding more warnings and notices about the behaviour and result of this command? I feel that it would make the user more cautious when using this command.

Just a side note on the wording of the description of this command (as I don't think it's worth opening another issue): It says clear all the entries from the contacts. However, throughout the whole UG, the data entries are referring as persons. There might be a potential inconsistency issue.

Steps to reproduce:

Command Involved
add

Observation and Rationale behind:
Currently, the add command contain a lot of required fields, including name, phone, email, module, faculty, and venue. As a student, I feel like it is very common that I don't know the venue of the tutor (sometimes they may even not have one if they are students also), and the phone number of tutor and professor, as these information are not necessary for me to contact them. In most cases, email is the primary method for communication. Moreover, sometimes it is quite weird to ask for certain informations, such as asking the phone number of a professor. Encountering this situation, as a user, the only thing I could do is to use some place holder values for certain fields, which increases the amount of works I need to do for adding a person.

Another potential downside for having a large number of required fields is that users may not be able to remember that much prefixes. Personally, when the number of prefix required in one command exceeds 3, I would be struggling remembering all the prefixes. As this is the feeling of me, it might not be representative of others. But there is a potential negative effect on the users when they are required to remember and enter a lot of fields correctly in one-shot.

Suggestions:
I feel like one possible enhancement would be to elaborate more in the UG on why those required fields are truly required.

Command Involved
add

Observation:
Contact with the same name but difference personal contact information are considered duplicated and the new one is not allowed to add.

Steps to reproduce:

1. Add a contact with name John Doe to the list.
2. Add another contact with name John Doe to the list, but this time with different personal information, such as the phone number and the email.
3. The result is shown in the screenshot.
   

Rationale behind:
Since multiple person could have same name but they can be differentiated with their contact information, would it be more reasonable to allow person with the same name to exist in the database and use a combination way of duplicated person checking? For example, use the combination of name + phone number + email to identify the uniqueness of a person.

Command Involved
add

Observation:
If I try to add a person with name including German letters, it will throw an error message.

Steps to reproduce:
The command used is: add n/Höäßü p/98765432 e/[email protected] m/CS2103 f/Computing v/311, Clementi t/frients

Rationale behind:
Since we are living in a multi-culture context, it is common to expect users with name containing letters in their own language. Moreover, since the target usage of StaffConnect is to manage contacts of professors and tutors, it would be more reasonable to consider the case when their name contains foreign letters.

Command Involved
add

Observation:
If I include " t/ #29-02" in the venue entry for the add command, the parser will think the t/ in the venue address be an actual prefix and parse it wrongly.

Steps to reproduce:

1. Include " t/ #29-02" in the venue part and ensuring all other entries are correct.
   

Rationale behind:
Since the current address doesn't prevent user from using predefined prefixes values, it is reasonable to think that users may accidentally enter a predefined prefix value in the long text entries, or they really need to do so. It would be better if more explanations about this situation could be added in the UG.

Command Involved
edit

Observation:
After editing a person, the app will refresh and the person in focus will be changed to the first person no matter which person I am actually editing.

Steps to reproduce:
Here is a video to illustrate the refreshing effect.

video:https://raw.githubusercontent.com/Ella-e/ped/main/files/6486a07a-a0d3-4851-a171-9f2a8c6710bf.mov

Rationale behind:
As a user, it would be a bit distracting for me if I am not able to see the change immediately after editing it.

Command Involved
Potential affected commands includes: add, edit, meeting-add. They are potentially affected because they requires the user to enter a lot of information or long texts without max character limitation.

Observation:
When the command entered is very long, the command enter panel can not be scrolled horizontally, making the modifications of specific part of the command very hard.

Steps to reproduce:
For example, if I paste the example "add" instruction into the command input panel, the cursor will be automatically moved to the end of the command. If I want to change the person's name now, I need to keep clicking the left arrow key on keyboard to move left, which is quite inconvenient and slow.

video:https://raw.githubusercontent.com/Ella-e/ped/main/files/9798d3d0-c2a1-4cc6-bc78-0c773b1e75db.mov

Rationale behind:
As by the designed of command, it is very possible that the user need to enter a very long text for address or meeting descriptions, and they might want to change some part in the front sometimes, such as fixing some mistypings. Therefore, it would be more natural if they could return to the front part of the command quickly.

Observation:
After trying out all the features, I feel that it would be better if the part for managing meetings could also be added into the one-line sentence describing the purpose of StaffConnect in the UG. Currently, in the opening sentence for the UG, it is stated that StaffConnect is a "desktop app for managing contacts of Professors and Tutors". I feel that the phrase managing contacts does not describe the current purpose very accurately. It is okay to use, but would not describe your application very well. Specifically, you have a lot of amazing features, such as managing meetings, add available times and tags, and much more. If those functionalities could be included in the one-line description of the app, it would improve the first impression of the users on the app.

Here is a screenshot of the current sentence in the UG:

Command Involved
meeting-add

Observation:
It is possible to add meeting date and time in the past.

Steps to reproduce:

1. Ensure there is at least 1 person in the list.
2. Run command: meeting-add 1 s/02/02/2023 0100 d/description
3. The meeting could be added while the time is in the past.
   Here is a screenshot showing the meeting in the list.
   

Rationale behind:
Based on the current interpretation of the meeting-add command in the UG, it makes one feel that the intention of the meeting-add command is to add new meetings for the user. And when we think of new meetings, it is prone to interpret it as "upcoming meetings". Therefore, allowing adding meetings in the past seems in contradiction with the purpose of this command. However, after reading the "Known limitations" in the "refresh" section of the UG, I find this section "...sometimes the user would like to retain old meetings for bookkeeping purposes." It points out that users may want to record past meetings, so in this case allowing inputs of meetings in the past is reasonable. Therefore, how do you think adding this part of explanation to the meeting-add command section as it would help the users better understand your feature.

Command Involved
meeting-add

Observation:
The checking for description is case-sensitive. If the user change the description of a meeting at same time from lower case letters to upper case letters and add again, it is allowed.

Steps to reproduce:



Rationale behind:
Since description are only texts to describe the meeting, if their only difference is the letter cases, they are most likely to convey the same meaning. Therefore, it would be more reasonable to consider descriptions with the only difference in letter cases the same.

Command Involved
add

Observation:
The content for the tag is case-sensitive and multiple tags with same word but different letter cases are considered different tags.

Steps to reproduce:


Rationale behind:
Since the case difference doesn't affect the meaning of the tag, would it be more reasonable to prevent multiple tags with same word but different letter cases to be added to the system?

Command Involved
sort

Detail:
In the user guide's sort command section, the [ATTRIBUTE] parameter allows multiple appearances. Since the UG mentioned that items with “...” can be used for multiple times, it would be better if this [ATTRIBUTE] is also followed by "..." for consistency. And additional notes could be added for the case that [ATTRIBUTE] should appear at least once.

Illustration:



Command Involved
fav

Observation:
As a proficient user, I would like to design my own data file using json directly. For the "Favourite" entry, if I use "favourite" instead of "Favourite", the whole data file could not be parsed and crash.

Steps to reproduce:

Rationale behind:
Since I could only favourite or not favourite a person, would it be better if the "Favourite" entry could be stored as boolean? Another more intuitive way for users would be to make the entry not sensitive to the case of the letters, as "favourite" and "Favourite" basically means the same thing for the users.