Step 13: Contact Information
From PikaDocs
| Table of contents |
Overview
We're still focused on workflow.
In the Claire design, having screened the potential client to determine his or her citizenship or alien status, and then economic eligibility, the intake worker's confirmation of eligibility creates of an actual case record (http://pikasoftware.net/docs/index.php/Image:Workflow_104b.jpg). Confirmation of eligibility also automatically triggers a separate intake Contact Information page, which in finished form you can view in this screenshot (http://www.openpika.org/beta_gallery/beta_contact_info_ie.html).
Although there are slight differences in recent iterations of the Pika default design for the "contact" or "address book" page, Pika users will recognize the page as looking something like this:
The same page elements repositioned and restyled in the Claire design look like this:
In the Claire design the specific subtemplate for this Contact Information page is the contact_full.html template. The Claire design adopts the basic page elements from the Pika default template but, as done with other Pika subtemplates, table elements have largely been stripped out where used to position those page elements, substituting instead floated divs. But not entirely. Let's break it down, looking at the three basic areas of the page: the "side-content" and the "main-content" areas, which have been rebuilt using floated divs; and the "Case List" area beneath them, which is built using a simplified table design.
But first, we need to explain something: Why we've added an extra class to the "content-container" div.
Tweaking the "content-container" DIV
At line 8 of the redesigned contact_full.html template, there is a form element that has an unintended effect in both Firefox and IE on the display of the page elements that follow it in the source code. This form element has the effect of "pushing down" the floated "side-content" and "main-content" divs that display adjacent to each other (the former to the left and the latter to the right). We had no luck targeting the form element itself with CSS to correct this effect, so we added a unique "contact-container" id to the "content-container" div at line 10 of the template:
<div class="content-container" id="contact-container">
We then added a corresponding CSS selector to provide a negative margin-top to the "contact-container," effectively "pulling up" the floated "side-content" and "main-content" divs to the same relative position they occupy on other pages:
#contact-container {
margin-top: -19px;
}
Alias/Actions "side-content" Area
Pika Software recently did some of its own redesign work, to modify page elements that display "alias" name information for each person with a contact record, plus active "action" links enabling the user to merge duplicate records or create a new case record for the person listed in the contact record. In the Pika default design, these page elements were embedded in a table used to control the layout and positioning of these and other page elements.
But by this time you know our mantra: "No tables: float, baby, float!"
Well, at least as often as you can, and we can do so here. As we have done with other subtemplates, we've removed these elements from the table and inserted them into the "side-content" floated div you've seen in prior Claire subtemplates. The already existing CSS code for that class does the rest:
<!-- "side-content" DIV -->
<div class="side-content">
<h2>Aliases</h2>
<!-- see contact.php at line 132 for "No aliases found." -->
%%[begin:alias]%%
<p>
Name: %%[full_name]%%<br />
SSN: %%[ssn]%%<br />
ID: %%[state_d]%%
</p>
%%[end:alias]%%
<ul>
<li><a href="%%[base_url]%%/alias.php?contact_id=%%[contact_id]%%">Add a new alias</a></li>
</ul>
<h2>Actions</h2>
<ul>
<li><a href="%%[base_url]%%/merge_contacts.php?contact_id=%%[contact_id]%%">Merge Duplicate Records for this Contact</a></li>
<li><a href="%%[base_url]%%/ops/new_case.php?thiscon=%%[contact_id]%%">Create a New Case for this Contact</a></li>
</ul>
</div> <!-- "side-content" closing DIV -->
Repositioning the Contact Information
There are several pieces of design logic to our repositioning of the input and select fields displayed on the Contact Information page. The information is displayed in three vertical columns to accomplish the following:
The "Person" Cluster
- The first cluster or logical grouping is a vertical listing of information that is unique and specifically "personal" to the contact: name, date of birth, Social Security number and default telephone contact information.
- To make it easier to scan the page for this information, this first cluster of corresponding input fields has a contrasting background to intentionally draw the user's eye to the content.
- The contact's telephone number is listed at the bottom of this first grouping to make it easier for the user to scan the page to locate that information.
- Validation scripts have been added and/or tweaked for all numerical fields in this first grouping. The goals of the validation are:
- Assure dates are entered in a correct format.
- Prevent "impossible" dates. (Mel Brooks you can represent, maybe, but not the 2,000 year-old man, okay?)
- Assure Social Security numbers conform to standardized numerical sequences and format.
- Require valid area codes and correct telephone number format.
- Automatically "mask" numerical fields so that the user does not have to key in slashes or dashes.
The "Address" Cluster
- The second grouping is all "address" information, specific to the same contact.
- Again, this second grouping is given a contrasting background color to facilitate visual scanning for the related information.
- For this grouping of "address" information, we moved the Zip Code field to the top for initial entry. Assuming one has correctly entered the zip code, then a corresponding validation script automatically enters the information for three other fields: county, city and state.
- Validation scripts for the Zip Code, State and E-mail fields to assure correct entry.
The "Categorical" Cluster
- The third grouping includes five select fields, all of which are "categorical" fields, i.e., identifying the contact as a member of non-unique categories: race/ethnicity, language, type of residence, marital status and gender.
- The default for each categorical select field is set to be blank.
- Validation scripts require all categorical fields to be filled out (even if only to indicate "Unknown").
- Failing to fill out any one of the categorical field results in an error message should the user attempt to "Save" the contact record.
- To make it easier to scan the third grouping, a modest visual separation has been created to set apart the race/ethnicity and language fields at the top from the three fields below them.
Contact Notes
Finally, sitting below the "address" and "categorical" clusters is the "Contact Notes" textarea (http://www.htmldog.com/reference/htmltags/textarea/) form field, a text field that is distinct from any "intake" notes taken earlier or "case" notes to be taken later.
All well and good. But the significant difference between these page elements in the Pika default template and the redesigned Claire contact_full.html template is that the former relies on one big honkin' table to contain and position all these page elements, and the Claire design ... doesn't. But you already knew that, right?
There are no real surprises in that regard. If you take a look at the contact_full.html template, you'll see in structural source order four "contact" divs: "contact01" for the "person" cluster, "contact02" for the "address" cluster, "contact03" for the "categorical" cluster, and "contact04" for the "notes" text field. In the corresponding CSS code, all four of these divs are set to {float: left;}. Also, other presentational style characteristics were removed from the original template, most notably the size of the input fields which were instead defined by using width values in the corresponding input selectors.
Repositioned and with other CSS styling tweaks in place, the finished form fields in these four floated divs look like this:
The "Case List" Table
Directly below the form fields is a dynamically generated "Case List" ...
The design of this table mimics the one used earlier for the Prospective Client search results table. Structurally, both tables are all but identical, although they return differing types of results. The "zebra" row effect is the same, as are the small-print links to "Case Notes," etc., and pop-up help windows. We won't repeat those lessons here, but you can find them explained in Step 08: Prospective Client (Part Three).
There is one significant structural difference worth noting: In the contact_full.html template, the "Case List" table (here given the class name "list-results") is embedded within a "table-container" div:
<div class="table-container">
<h2 class="list-results">Case List ... %%[full_name]%%</h2>
%%[begin:flex_header]%%
<!-- "Case List" TABLE -->
<table class="list-results" summary="List of client case records">
...
...
...
</div>
Why? Because embedding the table in a div here offers one way -- not the only way -- to control some presentational characteristics of the table across the full width of the page, including the convenience of centering the table itself as well as the embedded h2 elements. An alternative way to accomplish the same thing would be to set the margin-left and margin-right properties of the table and h2 elements to auto.
As we like to say, de gustibus (http://www.bartleby.com/59/3/degustibusno.html), dude!
Next: Step 14: Site Map
Related articles and files:
