Step 11: Citizenship and Alien Status
From PikaDocs
| Table of contents |
Revisiting Intake Workflow
It's time to revisit workflow (http://www.openpika.org/archives/2004/08/workflow_101_1.html), folks.
Up to this point what we've done is rebuild the initial Pika intake pages to deal with the prospective client, i.e., someone we screen to determine whether they already exist in our Pika database, or already knowing they do exist we need to find their contact or case record information. We previously diagrammed this initial phase of intake in some detail as Workflow 104a (http://pikasoftware.net/docs/index.php/Image:Workflow_104a.jpg), which at this juncture after searching contact records gives you a screen that looks like this (http://www.openpika.org/beta_gallery/beta_prospective_search_results.html).
The next step in the Project Claire intake process is all about client eligibility, which we break down into two basic components. The first is determining the prospective client's citizenship or alien status; the second is determining economic eligibility. At LSNC we refer to the first component as "Eligibility: Step 1." We have previously diagrammed this step in Workflow 104b (http://pikasoftware.net/docs/index.php/Image:Workflow_104b.jpg).
Actually what we've done is break down "Eligibility: Step 1" itself into two distinct workflow pages. To view full-size Firefox screenshots of each of these page, see Step 1: Citizenship Screening (http://www.openpika.org/beta_gallery/beta_intake_step1_firefox.html) and Step 1b: Eligible Alien Status (http://www.openpika.org/beta_gallery/beta_intake_step1b_firefox.html). These are two custom templates with Pika code modifications built for us by Pika Software. By this time, you know the drill: We took those two custom templates and rebuilt the markup and applied our custom CSS styles. Read on to see how we broke it all down for the Claire redesign.
Initial Citizenship / Alien Screening
The threshold step is to force determination whether the prospective client is either a U.S. citizen, an LSC-eligible alien or an undocumented alien. The intake_step1.html template is fairly minimal, identifying the client's name in the side-content area and a set of three related "intake workflow" links enabling the intake worker to move and back forth, as need, through the three "eligibility" intake pages:
The main-content area of the intake_step1.html template is simple and straightforward: three mutually exclusive radio buttons identifying the person's citizenship or alien status, a checkbox to verify the intake worker has confirmed citizenship status where applicable, and an "Intake Notes" field for recording specific information relevant to the eligibility process:
By default, radio buttons in Pika are dynamically generated for horizontal display. In the Claire design, we modified the Pika code to dynamically generate radio buttons vertically, as illustrated, above. For details on how to do that, see Radio Buttons: Going Vertical.
In consort with the selection of four different submit buttons at the bottom of the page ...
... validation scripts have been built into the template to preclude inconsistent data entry errors. For example, if the intake worker selects the radio button for Eligible Alien but submits using the Eligible Citizen button, an error message pops up:
There are a number of combinations to consider when selecting a submit button this page:
- If the prospective client is a U.S. citizen, clicking the Eligible Citizen submit button passes the intake over to the next page for economic eligibility screening, detailed in the next step.
- Should the prospective client be an LSC-eligible alien and the Eligible Alien submit button is selected, the intake passes over to the next intake page for confirming eligible-alien status, discussed below.
- If the the Undocumented Alien radio button is selected, there are two submit options:
- the intake worker can select the Eligible Alien submit button to move to the step for confirming alien eligibility (e.g., the person is undocumented but fits within the exception for battered women or other specific LSC exception); or
- select the Not Eligible submit button, which triggers rejection of the intake and deletes the intake record from the Pika database:
The Save button on this page does just that - it saves the intake record without requiring anything else. This is useful for the intake worker who has taken intake notes but, for whatever reason, at the moment cannot confirm the status of the prospective client. (What, you've never been interrupted doing intake?)
Assuming the intake worker has initially identified the prospective client as an LSC-eligible alien and selects the Eligible Alien submit button, the intake moves on to Step 1b, described next.
Confirming Alien Eligibility
The structure of the intake_step1b.html template is similar to the template described above. The same prospective client information and intake workflow links appear in the side-content area. The Step 1b: Eligible Alien Status choices in the main-content area are, again, radio buttons clustered in two groups: one for identifying the person's alien status ...
... and the other to identify the LSC-required documentation supporting that status:
Within each of these clusters, the radio buttons are mutually exclusive, i.e., one can only select one radio button in each group. There is a separate form (http://www.htmldog.com/reference/htmltags/form/) field for recording the specific document number or similar identifier, for ease of confirmation and searching within the Pika database:
As with the previous intake screen, there is also an Intake Notes field, which carries over any notes entered at a prior stage of intake:
Finally, there are three submit button options at the bottom of the page:
Selecting Continue will pass the intake record forward to the the next intake page, detailed in Step 12: Economic Eligibility. Selecting the Not Eligible submit button confirms rejection of the prospective client and deletes the intake record. The Save button, needless to say, saves the intake record in its current state.
The Help Pop-up Link
Using the same basic technique described in Pop Goes the Pika!, both the Step 1 and Step 1b pages include a [What do these terms mean?] link, which will pop-up a help window:
The JavaScript for the pop-up window is called from the top of the page template ...
<script language="javascript" src="/pika/js/pop_up_help.js"></script>
... which invokes the pop_up_help.js file located in the /helpdocs subdirectory.
CSS Alert: The Firefox bug
The CSS code specific to the intake_step1.html template page is listed in the Project Claire: CSS Code under the grouping for the intake_step1.html template. In general, there is nothing unusual there. Again, we eschew tables for layout and positioning, instead rebuilding the page elements with floated divs. The CSS code includes a typical complement of star html (http://www.info.com.ph/~etan/w3pantheon/style/starhtmlbug.html) hacks, primarily to deal with differences between IE and Firefox in how they handle margins for some page elements.
Having said that, there is one particular CSS quirk that must be laid at the foot of Firefox. (Yes, even the much lauded Firefox does CSS incorrectly. Not often, but sometimes.)
The problem? If a web page like the intake_step1.html template does not fill up the entire viewport because it is too "short" to do so, Firefox will leave out the vertical scroll bar on the right, with the result that there is unintended horizontal space, breaking the page display. (I guess the logic is that there is no need for a vertical scroll bar for a short page.) In the case of the intake_step1.html template, with its short-page display, this has the effect of violating the otherwise specified width of the page. (Recall our "wrapper" #page-content (width: 760px) from the default.html template?).
The solution? An itty bitty but essential tweak to the CSS settings for both the html and body tags:
/* required for Firefox where #page-content < viewport height */
html,
body {
min-height: 100%;
margin-bottom: 1px;
}
This fix forces Mozilla (http://www.mozilla.org/)-based browsers to display the page correctly. The min-height property is not recognized by IE, but it doesn't matter because it doesn't need the fix.
In anticipation of getting royally flambée'd on this point, full disclosure demands recognition that one could simply set a specific height property for the #page-container selector (which works in both Firefox and IE) or even maybe a min-height property for the same selector (although it will only work in Firefox). And that will work to solve the problem with the disappearing vertical scroll bar in Firefox - but only if you can reliably predict the height or min-height property is high enough for the viewport of every potential user. This approach also risks pushing the dark-green border-bottom of the #page-container div down and out of sight, compromising the visual cue that one is at the bottom of the page, which is why it's there in the first place. (Yes, one of the primary reasons for having a web page bottom border or footer is to tell you've reached the end of the page.)
In contrast, the fix we propose here works in all browsers, at all screen resolutions. Plus, it preserves the visual cue provided by the bottom border.
But as Shelby Lynne says, suit yourself (http://www.shelbylynne.com/music.asp).
Next: Step 12: Economic Eligibility
Related articles and files:
