<html> 
<head>
<title>Address Book Requirements</title>
</head>

<body bgcolor=white>

<h2>Address Book Requirements</h2>

by John Mileham

<hr>

<h3>I. Introduction</h3>

<p>
This document identifies the basic requirements of an web-based multi-user
address book application/service hybrid.
</p>

<h3>II. Vision Statement</h3><p>

<p>
An address book is very important to a collaborative site as it allows users
to interact and maintain relationships with all manner of personal and
professional contacts.  Providing this on the web is ideal because it is
available worldwide, 24/7, improving interaction across vast seperations
in space and time.
</p>

<h3>III. System/Application Overview</h3>

<p>
Address book
provides a simple UI for entering, editing, viewing, and deleting street 
addresses and other contact information including telephone numbers and
e-mail addresses.  It requires the street address storage offered by the
<a href=/doc/places/>places service</a>.  It also offers it's data model
for storing contact information to other applications, such as intranet,
who may wish to store such information in a portable format.  The data
model offers storage well-suited to PDA syncronization, particularly
with the PalmOS platform.
</p>

<h3>IV. Use-cases and User-scenarios</h3>

<p>
A typical user of the address book would store contact information of his or
her
friends and family on the web.  The user could then have ready access to the
information from anywhere with IP connectivity.  Also, the user could set
permissions on his or her personal address book to allow other parties to
view or
modify its contents.  Joe User might log on from home and add his aunt June's
telephone number and address to his address book.  Joe knows that his
brother James will (again) forget June's telephone number if he doesn't allow
James read permission on the contact.  Then James will be able to log in at any
time and read June's address, saving Joe and James both a lot of annoyance.
</p>
<p>
Also, address book may be used by other applications, such as intranet.
In the course of working on a project, team members often need to keep track
of the contact information of clients, suppliers, consultants, etc.  An
intranet project will be able to create and use its own address book.
</p>
<p>
The address book system's data model and any associated API may be leveraged
as a service by other applications wishing to store contact information for
any object in the database.  A corporate intranet might use the address book
data model to store contact information for all employees.
</p>

<h3>V. Related Links</h3>

<ul>
  <li> <a href=index>Coversheet</a>
  <li> <a href=design>Design document</a>
  <li> <a href=/doc/places/>Places</a> - <i>Service providing storage of
geographic locations that address book employs for street addresses</i>
</ul>

<h3>VI.A Requirements: Data Model</h3>

<h4>10.0 Contacts</h4>

<ul>
<h5>10.05 Identification</h5>
<code>contact_id</code> (primary key) that is guaranteed to be unique to the
local ACS site.


<h5>10.10 Basic Information</h5>
The following attributes should exist for each contact:

<ul>
<li>Name
<li>Organization
<li>Department
<li>Title
</ul>

<h5>10.20 Extended Information</h5>
A contact may contain arbitrary numbers of simple textual attributes
of the following types:

<ul>
<li>Email Addresses
<li>Telephone Numbers
<li>Notes
</ul>

<h5>10.30 Street Addresses</h5>
A contact may contain arbitrary numbers of addresses.

</ul>

<h4>20.0 Superset of PalmOS Address Book Functionality</h4>

The address book application must provide at least the functionality offered
by Palm series PDAs for future synchronization.

<h3>VI.B Requirements: User Interface</h3>

<h4>30.0 Master listing</h4>

The application will provide a master listing that will show all contacts
within the scope of the current instance of address book that a user
has permission to see.  Edit/Delete links will be provided to those with
sufficient priveleges.

<h4>40.0 Management functionality</h4>

There must be UI to manage contacts as follows:

<ul>
<h5>40.10 Single step creation</h5>
It must be possible to create a basic contact (with up to one phone number,
email address, and street address), in a single form.

<h5>40.15 Single step editing</h5>
Basic information for a contact must be editable in one step (including at least
one address, one email and one phone).

<h5>40.30 Permission Management</h5>
Default permissions for an instance of address book may be modified, as well
as individual permissions for each contact.

<h5>40.40 Deletion</h5>
Contacts can be deleted.
</ul>

<h3>VI.C Requirements: API</h3>

<ul>
<h4>50.0 Provide association of a contact with an object</h4>
Each contact may be associated with one object, though one
object may have many contacts.

<h4>60.0 Answer the question "What contacts are associated with
object X?"</h4>
<h4>70.0 Answer the question "What object is associated with
contact X?"</h4>
</ul>

<h3>VII. Revision History</h3>

<table cellpadding=2 cellspacing=2 width=90% bgcolor=#efefef>
<tr bgcolor=#e0e0e0>
    <th width=10%>Document Revision #</th>
    <th width=50%>Action Taken, Notes</th>
    <th>When?</th>
    <th>By Whom?</th>
</tr>

<tr>
   <td>0.1</td>
   <td>Creation</td>
   <td>11/23/2000</td>
   <td>John Mileham</td>
</tr>

<tr>
   <td>0.2</td>
   <td>Modified</td>
   <td>11/28/2000</td>
   <td>John Mileham</td>
</tr>

<tr>
   <td>0.3</td>
   <td>Revised</td>
   <td>11/29/2000</td>
   <td>John Mileham and Oumi Mehrotra</td>
</tr>

<tr>
   <td>0.4</td>
   <td>Revised</td>
   <td>12/05/2000</td>
   <td>John Mileham w/input from Michael Bryzek</td>
</tr>

</table>

<p>

<hr>
<address><a href="mailto:jmileham@arsdigita.com">jmileham@arsdigita.com</a></address>

Last modified: $Date: 2002/07/09 17:35:01 $


</body>
</html>