ITC382 11255412 A2

From PeacockWiki

Revision as of 04:16, 21 October 2005; Trevorp (Talk | contribs)
(diff) ←Older revision | Current revision | Newer revision→ (diff)
Jump to: navigation, search



Contact Details

In todays fast paced world, travel, while it has brought the world together, it has become harder to keep in contact with friends and co-workers. People change address/phone number, switch email accounts, buy a new mobile phone, switch to a new/different IM account, change jobs, change partners. Due to human psychology and sociology, a single method of communication is not sufficient, you cant do everything with simply email/IM, different methods of communication suit different needs of communication. With this in mind, a single person can collect a sizable list of contact details, perhaps with multiple addresses, multiple phone numbers, email addresses etc. Details for at work, and at home.

Communication void

The ease of travel has another impact on sociology, the fact that people have the ability to travel widely and meet many people, sometimes getting to know someone very well. In such cases, people are likley to continue communicating through whatever means they deem suitable. The situation also arises where people may not become involved enough to continue regular communication, however they may still be interested in the lives of such aquaintances. This is an unfilled void in the communication market. The proposed system aims to provide a solution.

Product audience

This product is potentially geared towards two primary audiences. The first being groups of friends or aquaintances, and the second being a group of co-workers within an organisation.


Friends wish to maintain up to date contact details, and keep up to date on the movements and lives of their friends, whether they communicate with them frequently or not. This category covers the range of best friends who communicate almost every day, to aquaintances who may wish to communicate on rare occasions. The second is group is where the system becomes really useful. Such a group of people is likley to be large, and difficult for any person to manage. The system will allow people to "subscribe" to recieve updates made by another person.


Businesses may make use of the system, by creating an employee index, including employees home details, which are maintained accurately by the users. Some employees may wish to provide 'news' to other employees (for example, progress of a project).

Existing Partial Solutions

Many elements of the proposed system currently exist, Address books, collaborative environments, blogging sites. What this system proposes to do is combine them in a unique and functional way, to promote time efficient communication, and effective information management.

Address book

The on-line address book mirrors the manual address book. a list of names and details, including home and work address, phone numbers, email addresses, IM accounts and DOB. This is seen today in email clients such as outlook and thunderbird, and also in on-line messaging systems such MSN and ICQ. ICQ has always supported a comprehensive user details database, having this much data about a person is not always desirable however.

Privacy Mechanism

Some people may not wish to publicly distribute their mobile phone number for example, however they may be quite happy to publicly display their home phone number or email address to the world. As a remedy to this problem, the Invite/Authorise paradigm used in the IM world for allowing people to communicate, could be extended to allow/disallow people from viewing certain details.


The blog may be perceived in different ways to different users. Business users may wish to use such a feature as a notice board, or simple newsgroup mechanism, for communicating news and progress to co-workers, and for this information to be hidden to the rest of the world, while other users may use it to inform their friends/acquaintances of major news and events in their lives.

This is not intended to replace the classical blog, but to function as a simplified version for use within the system, and where the invite/authorise mechanism may also be used to alert "friends" or "co-workers" (people authorised or associated with the writer) whenever an update is written.



While this system combines features found in IM networks, email applicatons, and blogging systems, it is not designed to fully implement or replace these systems, which already have a place in modern communications. This system is intented to only provide very limited communication facilities, its primary goal however to provide an effective platform to support communication via other means.


Image:ITC382A2 ERD.png

  1. Person: Represents a person subscribed to the system. (Can also represent an organisation, see Organisation)
    1. ID: Unique identifier for the user
    2. DOB: Date of birth
    3. Visibility: See Note
    4. DOB_visibility: Visibility of DOB, See Note
    5. Password: Users Password
    6. Primary Email: The users primary email address, used to send alerts.
    7. Username: Users login name
    8. Authorisation: Do users require authorisation to add a user.
  2. Address: Represents a postal or residential address
    1. Person: The person to which the address belongs
    2. [Address]: A collection of fields, detailing the address.
    3. Visibility: See Note
    4. Description: A user description of the address, extra details, or how/when to use the address
    5. Current: is this a current address, or a previous address
  3. Phone: Represents a phone number
    1. Type: Mobile, fax, home, work etc.
    2. Description: A user description, eg. how/when to use this number
    3. Visibility: See Note
    4. Current: is this current, or old information
  4. Email: Represents an email address
    1. ID: Unique identifier
    2. Confirmed: Has this address been confirmed as owned by the user
    3. Description: A user description, eg. how often checked, etc.
    4. Visibility: See Note
    5. Current: Is this a current or expired address
  5. IM: Represents any type if Instant Messager Account
    1. Account: The username, screen name, or ID of the account
    2. Type: ICQ, MSN, AOL, Yahoo, GIM, Jabber, IRC, or Custom
    3. Description: A user description, explanation of usage, extra details.
    4. Custom_Type: Name of method if not supported by the Type field.
    5. Visibility: See Note
    6. Current: Is this account current, or expired
  6. Association: represents an association between two users.
    1. Requester: The who requested, or who has access.
    2. Requestee: The person whose details they have access to.
    3. Pending: Is this a request, or a confirmed/authorised association.
    4. Subscriptions: Flag representing if the requester subscribed to information from the requestee (IE, to recieve email updates, etc.)
  7. Organisation: Represents an organisation
    1. Maintainer: The person responsible for maintaining the list of people belonging to the organisation, and the details for the organisation.
    2. Person: A link to a person object, representing details of the organisation
  8. Organisation-association: Allows a person to become a member of an organisation
    1. Person: The person belonging to the organisation
    2. Orgainsation: The organisation to which the person belongs
    3. Pending: Is this a request by the person, a requested by the organisation (maintainer), or a comfirmed/authorised association.


Visibility: Visibility represents four states (with the exception of the Person table). These are:

  • Public: Anyone with access to the internet can view details without registration.
  • Registered: Only other registered users can view details.
  • Authorised: Only people the person has authorised can view details.
  • Private: No-one but the owner of the information can view it.

Person.Visibility only supports Public and Registered.


The gui must be simple and effective, suited to both personal, and business use. It must support several basic features (Use Cases):

  • Account Creation

Sign up for a new account, choosing a username and password, and validating an email address.

  • Email address validation

Send an email to the user with a validation code to ensure that that user owns that email account.

  • Login/Logout

Allow the user to securely login/out of the system

  • Addition of Emails, Addresses, Phones and IMs.

Addition of new details. The database structure allows for a potentially unlimited number of details. As well as entering details, the user may select a level of privacy for each piece of information.

  • Archival of Emails, Addresses, Phones, and IMs.

Allow the user to remove a contact detail from active view. The detail will remain in the system for searching based on outdated details. This is useful to inform people that they did have the correct address, but it is no longer valid.

  • Optional Deletion of Emails Addresses Phones and IMs.

If the user wishes to, they may permanently remove contact info from the system, rather than simply marking it non-active.

  • Searching for other users on public information (Current, or archived)

Allow users to find each other and to request authorisation.

  • Requesting authorisation for association with another person

Once a user has found another, they may send a request to that user, to add them to a list of contacts. If the other user has specified that their permission is not required, the contact may be added immediately.

  • Authorisation of request, and adding association to (optionally) both sides.

After another user has requested authorisation, the recipient of the authorisation may accept or reject the request. If accepted, they may also choose to add that person to their own contact list.

  • Organisation registration

An existing user may create a new organisation.

  • Editing of details (as above) of the organisation by the maintainer.

Occurs in the same way as for a single user.

  • Requesting/authorising people in association with an organisation.

Operation should function similarly to authorisation above, although database structure differs. Organisation registration occurs between a user, and the maintainer of the organisation details. Once a user is added to an organisation, they may view the information of any other user in that organisation.

  • Viewing data of associated people (either personally, or through an organisation)
  • Edit/remove associations and subscribe to updates, blog.

For each user that any peson is associated with, they may choose to recieve updates when details change, or when a blog entry is posted.

  • Posting Blog Entrys


To be truly effective the system must be efficient, open, and easy to use. It should provide features that allow the user to work the way they normally work. To accomodate this the system may be extended to provide interoperability with several open standards, and with common hardware. A short list of possibilities include:

  • VCard Contact Details
  • CVS/XML Export
  • ICal Birthday Reminders
  • PDA Integration
  • Mobile Phone Integration


Personal tools