Step 12: Economic Eligibility
From PikaDocs
| Table of contents |
Overview
In prior steps we built out stages of the intake workflow to screen the potential client to see whether there is an existing intake, case record or contact record (http://pikasoftware.net/docs/index.php/Image:Workflow_104a.jpg), and also to screen the prospective client to confirm citizenship or eligible alien status. The next workflow stage (http://pikasoftware.net/docs/index.php/Image:Workflow_104b.jpg) in the Claire design is determination of the prospective client's economic eligibility. Here's where we're going with it:
The markup for this next step of the potential client intake workflow is contained in the the intake_step2.html template. The principal design logic behind our changes to the Pika economic eligibility screen is two-fold:
- First, purposefully parse out "economic" eligibility as part of the initial intake workflow, i.e., at this stage create only a disposable "intake" record instead of an actual "case" record.
- Second, avoid confusion of "eligibility" metaphors and make the page what it really is by removing non-economic screen elements from the page.
For example, part of the default Pika eligibility case "activity" template, illustrated here:
... includes several elements we have moved to other locations within Pika, such as the "Intake Type," "Referred By," "Citizenship/Verification" and "Client Age" fields.
As can be seen from the Claire design screenshot, above, the left side of the template is identical to the intake_step1.html and intake_step1b.html templates discussed in the prior step. Here in Step 12 we focus on the "main-content" area of the intake_step2.html template containing the income and asset eligibility elements.
The Economic Eligibility Page Elements
At its simplest, the structural markup for this "main-content" area is a single form (http://www.htmldog.com/reference/htmltags/form/) element within which are embedded six sets of sub-elements:
- input (http://www.htmldog.com/reference/htmltags/input/) fields for household composition;
- a wage calculator;
- an income/asset "grid";
- fields for calculating poverty percentage and selecting an income justification;
- a notes field; and
- a set of submit buttons.
The original Pika template relied on tables to control the positioning of these various sub-elements. As we have done elsewhere in the Claire design, we avoid using tables for this purpose. Instead, we have rebuilt the template to rely on floated divs for the positioning of most elements, relying on a single table solely to contain the array of "income/asset" select (http://www.htmldog.com/reference/htmltags/select/) and input fields in the "grid" in the middle of the content area.
At this juncture of the Claire redesign, you've already seen a lot of our structural markup and CSS-styling bag-of-tricks. To the extent practicable, we've eliminated all embedded style elements and table markup to control layout and positioning of page elements, instead using other structural, more semantically correct markup, with application of external CSS code to control how elements appear or are "presented." We won't belabor those points further.
For most of the page elements, you can refer to the full intake_step2.html template for structural, script and and related program code detail. Layout and positioning of the various divs and related styling characteristics are controlled by the corresponding code in the danio.css external stylesheet. The most siginificant structural element on this page, however, is the table grid containing the select and input fields for the income and asset information, discussed in the next section.
Rebuilding the Income and Asset Table Grid
We have eliminated all the tables used in the original template except for one: the income and asset "grid," illustrated here:
To be sure, a similar "presentation" of the very same grid could be accomplished without using a table, as was done in the alpha version (http://www.openpika.org/images_pika/alpha_intake_step2_test.html) of our Pika redesign. (Really, it was done without using any tables at all. Honest!) But such an approach proved all but unworkable if other goals were to remain intact, including a workable resizing or rescaling of the page for usability and accessibility purposes.
We pause here to note that we are paying attention to text resizing. One of the primary reasons the table grid was built the way it was for this template is that it lent itself to practical text resizing. For example, if you compare the default view (http://www.openpika.org/beta_gallery/beta_intake_step2_ie.html) in IE for this page with the same page with the text resized "up" one step (http://www.openpika.org/beta_gallery/beta_intake_step2_resize_ie.html) within IE, you can see the point: The latter is easier to read for the user whose vision demands a larger font, but the page design remains intact.
One of the primary design goals (http://www.openpika.org/archives/2005/04/codename_claire.html) of Project Claire is to build out for both usability and accessibility, including practical, client-side, browser-controlled text resizing. This is a fairly modest goal that can be accomplished for most users if there is ease of control of at least one step "up" in the browser-based text resizing function. There are any number of advantages and disadvantages (http://css-discuss.incutio.com/?page=UsingFontSize) within the universe of font sizing options, but there seems to be lack of design consensus (http://css-discuss.incutio.com/?page=FontSize) of how best to do this, although one view (http://www.thenoodleincident.com/tutorials/box_lesson/font/index.html) is to utilize percentage to set the default body font-size, and then use a varied combination of ems (http://css-discuss.incutio.com/?page=UsingEms) and percentages (http://css-discuss.incutio.com/?page=UsingPercentages) to control font sizing for other page elements.
Undoubtedly, as we progress further down the path of Project Claire, we will continue to tweak font settings in the CSS code as we strive for something optimal for the two browsers all but universally relied upon by Pika users: Firefox and IE.
And, after all, the grid here is a legitimate use (http://www.htmldog.com/ptg/archives/000049.php) of a table structure, albeit about "inputting" rather than "returning" tabular data. As Yogi Berra would say, "You've got to be very careful if you don't know where you're going, because you might not get there." We're opting for practicality and usability here so that we end up in the right place, and so we have retained a single table to structure the income and asset grid. Here's our table markup, modified from the Pika original:
<!-- TABLE container for financial eligibility input/select elements -->
<!-- row = type of income ~ frequency ~ amount | type of asset ~ value -->
<table id="eligibility-grid">
<colgroup id="income-type">
<col span="3">
</colgroup>
<colgroup span="2">
<col id="asset-type" span="1">
<col span="1">
</colgroup>
<thead>
<tr> <!-- table column headings -->
<th scope="col">Income Type</th>
<th scope="col">Frequency</th>
<th scope="col">Amount</th>
<th scope="col">Asset Type</th>
<th class="last" scope="col">Value</th>
</tr>
</thead>
<tbody> <!-- opening TBODY content -->
<tr id="first-row"> <!-- row 1 -->
<td>%%[income_type0,income_type]%%</td>
<td>%%[income_freq0,income_freq]%%</td>
<td>$ <input type=text name=annual0 value="%%[annual0]%%" tabindex=1 /></td>
<td class="asset">%%[asset_type0,asset_type]%%</td>
<td>$ <input type=text name=asset0 tabindex=1 onChange="asset_change();" value="%%[asset0]%%" /></td>
</tr>
<tr> <!-- row 2 -->
<td>%%[income_type1,income_type]%%</td>
<td>%%[income_freq1,income_freq]%%</td>
<td>$ <input type=text name=annual1 value="%%[annual1]%%" tabindex=1 /></td>
<td class="asset">%%[asset_type1,asset_type]%%</td>
<td>$ <input type=text name=asset1 tabindex=1 onChange="asset_change();" value="%%[asset1]%%" /></td>
</tr>
<tr> <!-- row 3 -->
<td>%%[income_type2,income_type]%%</td>
<td>%%[income_freq2,income_freq]%%</td>
<td>$ <input type=text name=annual2 value="%%[annual2]%%" tabindex=1 /></td>
<td class="asset">%%[asset_type2,asset_type]%%</td>
<td>$ <input type=text name=asset2 tabindex=1 onChange="asset_change();" value="%%[asset2]%%" class=maskf></td>
</tr>
<tr> <!-- row 4 -->
<td>%%[income_type3,income_type]%%</td>
<td>%%[income_freq3,income_freq]%%</td>
<td>$ <input type=text name=annual3 value="%%[annual3]%%" tabindex=1 /></td>
<td class="asset">%%[asset_type3,asset_type]%%</td>
<td>$ <input type=text name=asset3 tabindex=1 onChange="asset_change();" value="%%[asset3]%%" class=maskf></td>
</tr>
<tr> <!-- row 5 -->
<td>%%[income_type4,income_type]%%</td>
<td>%%[income_freq4,income_freq]%%</td>
<td>$ <input type=text name=annual4 value="%%[annual4]%%" tabindex=1 /></td>
<td class="asset">%%[asset_type4,asset_type]%%</td>
<td>$ <input type=text name=asset4 tabindex=1 onChange="asset_change();" value="%%[asset4]%%" /></td>
</tr>
<tr id="total-row"> <!-- row 6 = totals -->
<td> </td>
<td colspan="2"><b>Total:</b> $ <input type="text" name="income" tabindex="1" value="%%[income]%%" readonly></td>
<td colspan="2"><b>Total:</b> $ <input type="text" name="assets" tabindex="1" value="%%[assets]%%" readonly></td>
</tr>
</tbody> <!-- closing TBODY content -->
</table> <!-- "eligibility-grid" TABLE closing tag -->
How does this table markup differ from the original? A couple of things worth noting:
- A single table is used to contain both income and asset fields, rather than the mutliple and nested tables used in the original.
- Instead of setting embedded styles in the markup to control the table widths, as used in the original template, the Claire design relies on the "main-content" div that in the markup precedes the single table to provide the containing "boundary" for the table, which is then allowed to expand to the natural limits of its inherent tr and td elements, which in turn are specifically styled and delimited by the external stylesheet.
- Additional "hooks" are added to the single table, including a modified colgroup (http://www.htmldog.com/reference/htmltags/colgroup/) structure and both thead (http://www.htmldog.com/reference/htmltags/thead/) and tbody (http://www.htmldog.com/reference/htmltags/tbody/) tags, affording structural elements that can be styled externally, now or in the future.
Using CSS to Redesign the Table Grid Header
Having postured about all that, we actually styled the basic th (http://www.htmldog.com/reference/htmltags/th/) structural tags as the target for a design creating an intentionally subtle 3-D effect of the "header" that spans across the top of the entire table:
Styling of this "table header" was done with the following CSS code in the external stylesheet:
#eligibility-grid th {
font-size: 80%;
padding: 1px 0 3px 0;
color: white;
background-color: #B5C6A5;
border: 1px solid #CAA8B6;
border-right: 1px solid #B5C6A5;
border-bottom: 1px solid #7C806A;
}
#eligibility-grid th.last {
border-right: 1px solid #7C806A;
}
The CSS trick here was to initially set a border (http://www.htmldog.com/reference/cssproperties/border/) design that applied to all the th tags in the "eligibility-grid" table:
border: 1px solid #CAA8B6;
... then reset the border-right property to match the background-color property (#B5C6A5) so that the right border of all the th elements matches or blends into the background:
border-right: 1px solid #B5C6A5;
... effectively disappearing into the background-color of the "header." And then reset the border-bottom property and the border-right of the "last" th tag to the far right (appropriately, given the class name "last" in the markup) to a different color to create the subtle 3-D effect:
border-right: 1px solid #7C806A; border-bottom: 1px solid #7C806A;
Full-size IE and Firefox screenshots of the redesigned Step 2: Income|Assets Screening page are posted at the Project Claire Design Gallery (http://www.openpika.org/gallery.html).
Next: Step 13: Contact Information
Related articles and files:




