Address Book Design Documentation

by John Mileham

I. Essentials

II. Introduction

Address Book is an application/service hybrid. It allows the end user to create and store contact information in a collaborative web environment according to permissions set through the standard ACS permissions API. As a service, it also allows application programmers to leverage its extensible contact storage mechanism for other applications, such as an e-commerce order fulfillment system.

Address book stores basic identity information about each contact. Each contact may store an arbitrary number of custom attributes that may be used to contain phone numbers, notes and email addresses. Address Book relies on the places service to provide storage of an arbitrary number of street addresses per contact. The end result is a superset of the attribute and address storage provided by Palm-OS's address book application. This will enable us to write a full-featured synchronization conduit in the future.

III. Historical Considerations

Address Book evolved out of an ACS3.x package of the same name. The original address-book provided specific storage of all attributes, which was very limiting. A given entry could only support the number of email or street addresses originally planned when programming the application. It also provided a reminder service for birthdays. An address-book itself should not be date aware. The 4.x model is to integrate applications as completely as possible, especially considering the public APIs that are now standard with 4.x packages. This functionality should be handled by the calendar or even a new birthday reminder application that has the capability to link address-book contacts with calendar reminders.

Another disadvantage of the 3.x model of address-book was that there was no canonical storage mechanism for street addresses. Another application hoping to derive meaning from the address book data would have to be programmed to interact specifically with the table and column names of the address-book application. By using the places service for street address storage, address-book opens the storage of addresses to other applications. If a mapping package were written for ACS, it could be passed the address_id of the addresses associated with a contact and know exactly how to display a map for it. Contact addresses can even be used directly for radius searches using the places service.

IV. Competitive Analysis

Address Book was designed to take the functionality of the Palm application of the same name as a starting point. It goes from there to provide arbitrary numbers of attributes and addresses, which means greatly reducing the headache involved in keeping track of complex entries (such as a contact having home and work addresses, or many telephone numbers and email addresses). Address Book also supports single-step creation of a basic contact. There is no extra complexity just because of the more robust storage mechanism. You get the same ease-of-use of the Palm application with fully extensible storage sitting behind it.

V. Design Tradeoffs

There were two areas of address-book that were identified as focal points from the beginning of design. First, it was to be flexible. We met this requirement by providing extensible attribute and address storage. Second, it had to be easy to use. At every phase of design and development, the user experience was taken into account. Initially, there was a significant amount of JavaScript automation in the user interface. It did appear very slick, and allowed users to swap attribute locations on the page on the edit page without waiting for a page load. The problem was that it could be confusing to users unaware of the state of the actual data. The interface was pared down to the minimum. Swapping still exists, but all swaps are done on the server side in a quick operation rather than on the browser side. Forms are less confusing because there is only one committal action that can be taken per form. That is clicking on the submit button. Rather than incorporating confusing functionality on a single edit form, the user may choose to modify what they want through a number of intuitive actions directly from the view page. An additional benefit of removing JavaScript is a decreased dependence on client-side robustness. Many businesses and higher security institutions disable JavaScript on all workstations for security reasons. By eliminating this frivolous dependency, Address Book becomes fully functional on older and more unusual platforms.

VI. API