Tan Yikai - Project Portfolio

Instead of typing the standard command such as add, edit, etc, user can use a, e to execute the same commands.
---

To enable user to type in command at a faster rate, command shortcuts or command alias was introduced.

End of Extract

Start of Extract [from: User Guide]

The Sort command sorts the person list alphanumerically by person’s name, phone, email, address or remark.
It is useful when the addressbook has alot of entries and allows user the option to organize their addressbook for a more pleasant appearance of the data presented.

It is most useful in providing user with the overall content of the addressbook in an organised manner which groups those with similar names together.
Using it to sort Phone number allows user to see the numbers that are similar or the same to be grouped together.
Using it to sort Address enable one to see those who lives in the same place being place close together within the addressbook.

This feature is particularly useful to supplement the find command which although returns any person which contains certain substring that the user requested but in an order in which the person is being added.

End of Extract

Start of Extract [from: Developer Guide]

Aspect: Implementation of sort command
Alternative 1 (current choice): Integrate the various sort types ( by name, phone, email, address, remark) into a single command
Pros: Easier to implement and more straight forward for the user.
Cons: More standardised and less customizable sort since all the various sort types sorts by alphanumeric values in their corresponding ASCII values.
Alternative 2: Have a separate command for each sort types
Pros: More customizable sort as each different sort type can take in different parameters. For example, the address sort can request for parameters to sort by address number and street name.
Cons: More difficult to implement and less user friendly as user have to key in more parameters and remember more things before sorting.

End of Extract

Start of Extract [from: User Guide]

Enhanced Add Command

The original implementation of the add command requires the user to input every field (name, phone, email, address, tag) before enabling the person to be added to the addressbook.
This causes inconvenience to the user as the user needs to remember the long sequence of commands before able to successfully implement the add command.
In addition, during a practical use, the user may not always know all the fields related to a particular person but may wish to still put some information regarding the person into the addressbook.

Hence, the Enhanced add command was made which only made the name input of the add command compulsory.
The rationale behind deciding on at least a single compulsory field is so that it is more logical to have at least one information before adding into the addressbook and that an empty addressbook is still invalid.
Name was chosen as the compulsory field as a person’s name is the main information that will identify and distinguish one person input from another in the adressbook.

Integrated remark

Initially, the remark command was a separate command because the original purpose of remark is to add and edit a remark field on 2 person concurrently.
The initial idea for the remark field was for the user to put down a common relationship between 2 person in the form of sentences or words describing the relationship.
This feature was later made obsolete by the more comprehensive relationship feature and hence the remark command was removed.
The code of the previous RemarkCommand is still available under the collated folder in unused file.

However, we still want the user to be able to store sentences or notes regarding the person entries into the addressbook.
The remark could accommodate sentences and has no limitations which is a difference from the existing Tag feature which can only accept single words.
The Tag was also not modified as it will defeat the purpose of a tag which should be short and clear for user to remember.
Hence a new field which was remark was integrated into the whole addressbook system through the modification of existing add and edit command.

Start of Extract [from: Developer Guide]

Aspect: Implementation of enhanced addCommand
Alternative 1 (current choice): Add new parser methods parseAddPhone, parseAddEmail and parseAddAddress
Pros: Able to isolate the behaviour of the add command and the edit command so that editing an existing Person will not overwrite the fields that should not be edited.
Cons: More difficult to implement as more test cases has to be added for the new parser methods.
Alternative 2: Modify existing parser method parsePhone, parseEmail and parseAddress
Pros: Easier to implement as we can re-use existing tests and codes and just add minor modifications
Cons: The behaviour of edit command overlaps with the behaviour of the add command, causing unintended overwrite of other fields such as address when we don’t want to.

Aspect: Implement separate remark instead of modifying tag
Alternative 1 (current choice): Create a new separate remark command
Pros: Able to provide a cleaner user interface and experience. Also reduces complications in modifying existing working tag system.
Cons: More work has to be done in testing and creating a new command.
Alternative 2: update the tag to accept sentences for remarks
Pros: Easy to implement as we do not need to add a new command.
Cons: The Tag may be more difficult to find and more work is needed to change the find tag command. Additionally, the user interface of tag command also needs to be changed to accommodate long tags.

Aspect: Defining a valid remark input
Alternative 1 (current choice): No restrictions on the kind of remark input the user can put into the addressbook, i.e. the user can put in any characters in any format.
Pros: More freedom for the user as the user can type in anything for adding a remark. It is also easier to implement as the input string does not have to go through other checks.
Cons: Can get messy if the user is not consistent in the way they place in remarks. The sort command applied under remarks also does not sort the remark as well if the input is not consistent.
Alternative 2: Impose a restriction on remarks in the format [Remark Type] remark followed by restriction of only allowing alphabets.
Pros: . The sort remark command will be able to organise and sort the remark better since each remarks are predefined at the start in the [Remark Type].
Cons: . More difficult to implement as we need additional checks to be placed for the restrictions and also less freedom for the user as they need to follow stricter rules before putting in a remark entry.

End of Extract