Familysite Design Specification
Group Deliverable #2
Andy Schamp, Dave Brondsema, Brian Hibma, AJ Penninga, Randy Moeller II

I. Introduction

A. Purpose and Content of this Document

This document specifies the design of Familysite.  It contains
explanations of the structural design and user-interface design.  It
containes diagrams of the database.

B.  Familysite

The Familysite project is a package that can be
installed on a web server to manage information about a large family
group, including personal information, contact information, family
calendar information, and photos.  It also tracks the relationships
between members of the family so that genealogical information can be
displayed.

It will be written in PHP, using the ADODB library to interface with many
different databases, and the PHPHTMLLIB library to generate the HTML code
and forms.  The site will be administered by one or more admin-level users
and a number of HOHs (heads-of-household), one managing each household
unit.

C. Requirements Specification

The design for Familysite is based on the requirements in the Familysite
Requirements Specification document.
(http://familysite.sf.net/requirements.html)

II. Structural Design

A. Object Design

Familysite is not written from using OO techniques, so there is
no object design.

B. Structural Design

Familysite is designed with different modules that are loaded into
template pages.  The ADODB database libraries and PHL html generation
libraries are managed via a page that takes care of every line of code
necessary for the site to function, inserted at the beginning of every
page.  The code for each module is generated by a function call, which is
placed in the desired spot in the template.

Form processors are built into the form display page functionality, thanks
to PHL.

C. Database Design

The database design is detailed in the database ERD chart
(http://familysite.sf.net/Database_ERD.html).  It specifies the tables and
fields used by the various parts of the system to manage information and
relationships.  

D. Use Case Explanation

There are 4 possible types of users of Familysite, web visitors, family
members, HOHs, and administrators.  Each higher level has all of the
privileges and functions of the lower levels, plus higher privileges to
which the others do not have access.  They are detailed below.

Level 0:  Web Visitor

View Site - (Can view everything global privacy setting (i.e., visible to
everyone)
    View Calendar
    View Photo Gallery
    View Personal Information

Level 1:  Family Member (can view everything with family-wide permissions)
    Manage personal information
    Manage personal privacy info
    Add photos to gallery
    Manage personal calendar events

Level 2:  Head of Household (can view everything in the household)
    Add users to household
    Manage household information
    Manage personal information of household members
    Manage household photo gallery
    Manage household calendar events

Level 3:  Administrator (can view everything)
    Change person status (designate HOHs and other Admins)
    Manage personal information of all users (incl. deceased)
    Manage all calendar events
    Manage forums

III. Human-Computer Interface Design

A. User Task Narratives

Upon visiting the site, the web user will see the familysite logo at the
top of the page, and a login form on the left.  There will be a help link
and a list of navigation items on the left and an area for news in the middle.

A visitor can view calendar information, see a list of household members
and view their personal pages, look at pictures, and go back to the main
page without logging in, if the privacy settings allow this information to
be visible to the world.

A user can also fill out a form to register with the family group.  They
can fill in the appropriate information and they will be granted an
account with pending status, until an adminstrator approves their entry
into the system (this is useful for large family groups).  If a user has
forgotten her password, she can have a new one emailed to her via the
Forgotten Password form, linked from the login page.

When attempting to log in, a user is presented with a form in which to
enter his username and password.  If the user exists, the password is
correct, and the user is marked as "active" in the database, then he is
logged into the system and forwarded to his personal information page.

Here, he can edit personal information, add calendar items, add photos,
and so on.  Each area will have its own administration page.

If the user is marked as a head-of-household, she will have links to pages
for administering the information of other household users, as well as her
own.  She can also manage household-wide information, approve users for
inclusion in the household (after they have submitted their information),
and so on.

If a user is an administrator, he will be able to manage any user or
household information in the entire system, as well as manage system-wide
configurations, such as templates, etc.

B. User Interface Mockup

We intend, if all goes according to plan, to have several possible
template files available for use with Familysite.  We have included one of
the proposed designs (which will be used as the default) with this
document (see attached).

IV.  Related Links

Familysite homepage:  http://familysite.sourceforge.net/
PHPHTMLLIB:  http://phphtmllib.newsblob.com/
ADODB:  http://php.weblogs.com/ADODB/