ITC382 11255412 A2

From PeacockWiki

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

Contents

Problem

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

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.

Business

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.

Blogs

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.

Design

Scope

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.

Database

  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
  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: Has 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.

Note

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.

GUI

Technical

Solution

The solution is a form of Collaborative online address book, where users may change their own details, and define who has access to the details.

Personal tools