Project: People.connect - Level 4

People.connect is a desktop address book application. This application is catered to meet the requirements of a
businessman who wants to keep his business contacts at the same place and then access them quickly and efficiently. It
has a GUI but most of the user interactions happen using a CLI (Command Line Interface).

Code contributed: [Functional code] [Test code] [Unused code]

Enhancement Added: list by tag

External behavior


Start of Extract [from: User Guide]

Listing persons : list

Shows a list of all persons in the address book.
If tags are supplied, then shows the list of all persons with that tag in the address book. The tags are case-sensitive.
Format: list [t/TAG]

Examples:

  • list
    Shows the list of all persons in the address book

  • list t/friends
    Shows the list of only those persons in the address book that are tagged as friends

End of Extract


Justification

Sometimes the user may require to find people that belong to a certain category. An example can be a student trying to
find fellow contacts with tag 'CS2103' in the app. In this case, using a find command will not be feasible since it
uses name as its arguments but students can have different names in our case. Hence, using list command makes more
sense. Hence, instead of listing the entire address book, I have implemented the list feature by tag.

Implementation


Start of Extract [from: Developer Guide]

List mechanism

The list mechanism is assisted by two classes ListCommandParser residing in parser and PersonContainsKeywordsPredicate residing in person.
It supports the listing of contacts which do not modify the addressbook(e.g. Exit, Find). Such commands inherit from Command, unlike commands inheriting from UndoableCommand which modify the state of the address book.

The following sequence diagram shows how the list operation works:

ListCommandSequenceDiagram

The following activity diagram shows what happens when a user executes a new list command:

ListCommandActivityDiagram

Design Considerations

Aspect: Implementation of ListCommand
Alternative 1 (current choice): Add a new class ListCommandParser
Pros: We will be able to provide arguments to list only certain types of contacts
Cons: Hard for new developers to understand why we used list command instead of find to get contacts with certain tags.
Alternative 2: No parser class
Pros: Easier for new developers to understand
Cons: All contacts are listed every time which may be an issue if user is trying to filter contacts by tags

End of Extract


Enhancement Added: Phone attribute

External behavior


When the app shows the contact details, it displays the phone in the national convention.
However, when you enter the contact when adding a new person, there is no need to follow
the convention, rather enter the phone number as a single number.

Examples:

  • add n/John Doe p/98765432 e/johnd@example.com a/John street, block 123, #01-01 b/13/02/1998 pt/JohnDoe.jpg
    Adds new contact "John Doe" with 98765432 as its phone but displayed as 9876-5432 on the person card


Justification

From the name of the app itself, it is evident that connections are of utmost important and phone numbers are the most
important of them all. Displaying phone numbers in the formats that are similar to how we see in real life will make it
easier for user to interpret it.

Implementation


Start of Extract [from: Developer Guide]

Phone attribute

Person class consists of five different attributes: Name, Address, Phone, Email and Birthday. The Phone class
has implementation similar to other attribute classes. New instance of Phone is initialized through constructor. Important
thing to note here is the once the phone is validated to be only numbers, it is also followed by the conversion of phone
into the national convention format as well.

The conversion to national convention is done within the Phone class in the following way:

public Phone(String phone) throws IllegalValueException {
    // ... phone validation logic ...

    this.value = formatPhone(trimmedPhone);
}

public static String formatPhone(String trimmedPhone) {
    // ... variable declarations ...
    String formattedPhone = generateFormattedPhone(trimmedPhone, phoneLength);

    return formattedPhone;
}

Validation

The valid form of phone is xxxxxxxx with as many characters as the user want, but no less than 3. Every character must
be a digit and there should be no other character like +. This prevents the user to enter alphabets or other invalid
characters while entering phone numbers.

The example of valid phone numbers are:

  • 6596631234

  • 919911204422

  • 15671237070

The example of invalid phone numbers are:

  • 6596asd

  • +919911204422

  • 12

The current validation allows the user to enter as many digits as he/she wants which is not the case in real life. The
numbers must be restricted to certain number of digits based on the country. Such validation will be performed in the future
version of the tool. The validation for number of digits will be quite extensive since different countries have different
number of digits in their phone numbers, which is the reason it is noe done yet.

End of Extract


External Behaviour


Start of Extract [from: User Guide]

Setting password for the address book: password

Coming in v2.0
Sets password for the address book. After setting the password
you will be prompted the password when initializing the address book.

Format : password

Example :

  • password
    mypassword (sets the password to mypassword)
    mypassword (you are also asked to confirm the password)

End of Extract


Justification

Since the app has a feature of hiding certain fields about a person, if the addressbook is not locked, any person can
access those details using 'viewall' command which would leave the point of hiding details useless. Hence, adding a
level of security will be a good feature to implement.

External Behaviour


Start of Extract [from: User Guide]

Cleaner UI

Coming in v2.0
Give the user a better experience through a much cleaner UI. The person’s details will not be on the card, but on a
seperate panel on the side which makes the details much easier to look. The images are also shaped in the form a
circle so that it looks much elegant.

End of Extract


Justification

People.Connect is targeted for businessmen. So a simple yet elegant user interface will attract more users. The user
should not strain himself to lok at the details of the person and that’s why it is intended that we remove the details
from person card and add a separate pane where all the details can be shown with much larger size making it easier
for the user to se ethe data without any stress. The theme is not bright but dark with subtle mix of blue added
through google maps which complements the overall look of the app. Also, the image of the person is intended to be
shown in a circular shape rather than a square.

Other contributions

  • Found bugs in other team’s product (Issues #140, #138)

  • Suggested enhancement for another team’s product (Issues #139]