Address Book Application Design
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,
-- big enough to hold zip+4 with dash
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
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
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.
- 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