ArsDigita Archives

Address Book Application Design

by Bryan Che

I. Essentials

II. Introduction

People often keep address books containing their contacts. The address book application will allow people to store their contact information on a Web site, enabling them to access their contacts from anywhere they have access to the Web. Furthermore, because the address book application supports group and public address books, they will be able to share contact information with other people on the Web.

III. Design Tradeoffs

The address book data model directly stores each contact field as a column within the address_book table. This makes it simple to program the address book and also helps it to perform more robustly. But, this design approach loses some flexibility because it does not readily let users customize their address books by adding additional fields or deleting current fields.

Another approach for storing address book contact fields would be to use meta data to allow individual users to create truly customized address books with their own fields. This, approach, though, would have the danger of becoming unwieldy in its implementation and user interface. It also would mostly likely decrease performance.

IV. Data Model Discussion

The address book data model consists primarily of two tables:

create table address_book (
	address_book_id	integer primary key,
	-- if scope=public, this is the address book the whole system
        -- if scope=group, this is the address book for a particular group
        -- is scope=user, this is the address book for for particular user
	-- if scope=table, this address book is associated with a table
        scope           varchar(20) not null,
	user_id		references users,
	group_id	references user_groups,
	on_which_table  varchar(50),
	on_what_id      integer,
	first_names	varchar(30),
	last_name	varchar(30),
	email		varchar(100),
	email2		varchar(100),
	line1		varchar(100),
	line2		varchar(100),
	city		varchar(100),
	-- state
	usps_abbrev	char(2),
	-- big enough to hold zip+4 with dash
	zip_code	varchar(10),
	phone_home	varchar(30),
	phone_work	varchar(30),
	phone_cell	varchar(30),
	phone_other	varchar(30),
	country		varchar(30),
	birthmonth	char(2),
	birthday	char(2),
	birthyear	char(4),
	days_in_advance_to_remind	integer,
	date_last_reminded	date,
	days_in_advance_to_remind_2	integer,
	date_last_reminded_2	date,
	notes		varchar(4000)

create table address_book_viewable_columns (
       column_name  varchar(100) primary key,
       -- for when the column name results from an "as" command
       -- for ex., you can customize viewing columns
       extra_select varchar(4000),
       pretty_name  varchar(4000) not null,
       sort_order   integer not null

The first table, address_book, stores address book entries. These entries contain information about who owns the entry and the contact information within the entry. They also contain birthday-reminder information. The second table, address_book_viewable_columns, stores information about how to present the address book fields in address_book.

V. Legal Transactions

The Admin Pages

The admin pages do not perform any transactions

The User Pages

Users may add, edit, and delete address book entries. They may also add and edit information about how to view a contact field.

VI. User Interface

The User Interface

From the user interface, the user can go to his own private address book, a group address book, or a public address book -- if he has permission to view them. Furthermore, if he has the right permissions, he may edit the address books as well. At the address book, he may sort and search for contacts and view them. He may also add, edit, and delete contacts. Finally, he may manage the contact fields he would like to use in his address book.

Contacts' e-mail addresses are linked with an HTML mailto tag, so the user may directly e-mail contacts by clicking on their e-mail addresses. Furthermore, addresses have a link next to them which will direct the user to a map of that address.

The Admin Interface

From the administrator interface, the administrator can view which users have address book entries, how many entries each user has, and what those entries are.

VII. Acceptance Test

You should test adding, editing, viewing and searching for a contact.

Suggested path:

  • Add a contact
  • View a contact
  • Edit a contact
  • Search for the contact

VIII. Future Improvements

The address book application does not currently support many of the fancier features which other electronic organizers do. In the future, it should support categorizations of contacts, increased flexibility in managing contact fields, and tighter integration with other ACS packages, like calendar. The ability to synchronize with other popular electronic address books, such as the Palm Pilot's address book, would also be nice.

IX. Authors