Step 20: Case List Search Results
From PikaDocs
| Table of contents |
Design choices for displaying the case list
There are any number of locations within Pika that display "search results" of one kind or another. Both in the classic Pika design and our Claire redesign, the display of search results typically involves a "zebra" table, i.e., results listed in rows of alternating colors to facilitate scanning a long list of records and recognizing where one records ends and the next starts. For example, a recent iteration of the standard Pika design displays case lists this way, with a zebra table of results offering a full dozen, data-dense columns of case record factoids:
Another recent iteration was one of the Pika 3.04 designs providing a left-side column with more refined options for filtering the selection criteria, along with an adjoining case list search result table of half as many columns, but which is notably easier to visually scan. After vetting these sort of design and user options with several of our frontline intake workers, we opted to plagiarize the latter choice for the Claire design, illustrated here (with obviously bogus and incomplete case records):
In one form or another, most of the design choices made here have already been detailed, if in slightly different form, at earlier steps of this project. But let's pop through them quickly to make sure we cover all the basic page elements for the Case List page design, built first on one overarching design choice that you've heard before, and second on the following four basic clusters of page elements:
- "Quick Lists" of links for automatically generating a variety of predefined and commonly used lists of cases.
- "Custom Lists" options and fields affording a user-friendly way to do granulated search queries.
- The "Search Results: Case List" table itself, generated by either of the first two items, above.
- A compilation of numbered links at the bottom for "paging" through additional case list search results.
Substituting DIVs for the TABLE in the side column
If there has been a core mantra to the Claire design, it is the one we first uttered in our article Home Page: No Tables and again at Step 03 of this design project: if used solely for layout or positioning of page elements, then remove the table tags and replace them with (floated) divs.
That big-picture design rule applies to the Case List page, as it has to most of the other pages we've redesigned as part of this project. To be sure, the search results themselves need semantically correct (http://www.govis.org.nz/conference2005/presentations/joseph-lindsay-html/semantichtml.html), table-based structural markup (http://www.456bereastreet.com/archive/200410/bring_on_the_tables/), detailed below. But nothing else on the page does.
The structural markup for the "side-content" area of the Case List page here is based directly on the same "side-content" and "side-form" floated-div design used earlier, for example, to build the Home page and the Case Screen "Shell". As illustrated here, first with the CSS code controlling its display and then a screenshot with a dashed-blue outline surrounding it, the "side-content" area is simply a 160 pixel-wide div floated to the left, with the search-results table slipping in to the right to fill in the remaining space between the side-content div and the right side of the main content area of the page:
.side-content {
float: left;
width: 160px;
padding: 10px 0 10px 10px;
}
Let's now break out those four page-element clusters we we're talking about.
"Quick Lists" of search results
In the upper left-hand side of the page, there is a cluster of links called "Quick Lists," i.e., a set of links that automatically generate varied lists of cases based on preselected search criteria (e.g., all of the logged-in user's "open cases"):
In the original Pika design, this cluster was called "Case List Modes." We opted for a title that was a touch less geeky, and then worked at simplifying the structural markup for this part of the page. In the original case_list.html template, these links were embedded inside table/td tags, within which was nested a p (paragraph) tag, and within that paragraph were further embedded three lines of code for each link: an img (image) tag, an a (anchor) tag and a br (line break) tag:
<h2>Case List Modes</h2>
<p>
<img src="%%[base_url]%%/images/point.gif" alt="Arrow"/>
<a href="%%[base_url]%%/cases.php/">My Open Cases</a>
<br/>
<img src="%%[base_url]%%/images/point.gif" alt="Arrow"/>
<a href="%%[base_url]%%/cases.php/?show_open=0&show_closed=1&user_id=%%[user_id]%%">My Closed Cases</a>
<br/>
<img src="%%[base_url]%%/images/point.gif" alt="Arrow"/>
<a href="%%[base_url]%%/cases.php/?status=1&show_open=1&show_closed=1&user_id=%%[user_id]%%">My Pending Cases</a>
<br/>
<img src="%%[base_url]%%/images/point.gif" alt="Arrow"/>
<a href="%%[base_url]%%/cases.php/?show_open=1&show_closed=0&user_id=">All Open Cases</a>
<br/>
<img src="%%[base_url]%%/images/point.gif" alt="Arrow"/>
<a href="%%[base_url]%%/cases.php/?show_open=1&show_closed=1&user_id=">All Cases</a>
<br/>
</p>
For the Claire design, again as we have done elsewhere, we changed this markup by removing the table tags, since we are relying on a floated div for this part of the page, as described above; then removing the p, img and br tags; and instead using ul (unordered list) with li (list item) tags whose presentation is controlled via CSS code. Here's the corresponding markup for our version of the case_list.html template:
<h2>Quick Lists</h2>
<ul>
<li><a href="%%[base_url]%%/cases.php/">My Open Cases</a></li>
<li><a href="%%[base_url]%%/cases.php/?show_open=0&show_closed=1&user_id=%%[user_id]%%">My Closed Cases</a></li>
<li><a href="%%[base_url]%%/cases.php/?status=1&show_open=1&show_closed=1&user_id=%%[user_id]%%">My Pending Cases</a></li>
<li><a href="%%[base_url]%%/cases.php/?show_open=1&show_closed=0&user_id=">All Open Cases</a></li>
<li><a href="%%[base_url]%%/cases.php/?show_open=1&show_closed=1&user_id=">All Cases</a></li>
</ul>
Since the CSS code for ul and li elements was already defined earlier, the design changes render immediately without any need to tweak the CSS for the links on this page.
"Custom Lists" of search results
Again, this part of the design was revamped to remove the table tags used to position it in the original design, and then restructured it by using a set of id-named divs (#side-form, #case-list-checkbox and #side-form-submit), plus an id name for the h2 tag, to provide unique hooks for applying CSS code to control the appearance and positioning of these page elements. You can view these structural changes in the Project Claire: case_list.html template, and how they are presented via the corresponding CSS code.
The Case List search results TABLE
As explained earlier, the design of the case-list table used at this page is derivative, being based on the table design originally created for LSNC's custom intake_contact_list.html template in Step 08. You can view the changed markup for these table elements in our version of the Project Claire: case_list.html template.
There is one particular aspect of this page element we feel bears repeated emphasis: It is essential to use a table here because search results of this kind are the type of tabular data for which XHTML table markup was created. But you do not need to embed any presentational attributes in the table markup itself. None.
As we did in Step 19, you should consider simplifying the table markup by removing any deprecated or presentational attributes better defined by the external stylesheet. For example, in the Claire version of the case_list.html template, both the table's traditionally embedded width and cellspacing values, among other things, are controlled solely by applying external CSS to the relevant selectors:
#case-list {
width: 100%;
font-size: 85%;
}
#case-list-table {
width: 100%;
border-collapse: collapse;
margin-top: 10px;
margin-bottom: 20px;
}
Also, the traditionally embedded cellpadding value here is controlled the same way, by appling padding properties to the table's td (table data cell) selector in the CSS code:
#case-list-table td {
padding: 4px 0 4px 4px;
}
There are two other, less significant but interesting items about the Claire table design here. First, the clickable "time" icon to the far right of each row in the search-results table, as seen in this example:
... is based on one of our other articles, Time Slips: Changing the Icon. Make of it what you will. It works for us.
Also, we substituted a replacement set of images for the black, inverting "ascending" and "descending" icons embedded in the th (table header cell), illustrated here adjacent to the "Opened" column header:
This is a nice Pika feature that enables the user to click on the column header to resort the results in ascending or descending order (similar to a feature common to applications like Excel that list data in table/column format). However, we had some trouble with the original icons because their backgrounds were not transparent, causing their white-color backgrounds to clash with our CSS-defined background color for the column headers. What to do? Just replace the icons with duplicates that have a transparent background and upload them to the /images subdirectory. No more clash!
We've posted the new icons as part of the collection at Project Claire: User Interface Images. You'll see them at the bottom, beneath the varied collection of submit buttons.
The Pika "pager" links
The final bit for this page is the compilation of "page" links at the very bottom, beneath the case list itself:
We have a confession to make: We had other design ideas for these page links (which one can use to "page" through multiple pages of search results, akin to what you have done innumerable times at web search sites like Google). But we abandoned them. Why? Because once we deconstructed how these page links are dynamically generated (the Pika system code internally refers to this feature as "Pager"), we were thoroughly intimidated by everything that went into generating a simple number link. We looked down the "pager" rabbit hole, let us tell ya, and it's an unholy abyss, people. You don't want to go there.
So, we punted. We still wanted to have some kind of hook for applying CSS code, generally, to this part of the page. Our solution was simply to wrap a div named "page-links" around the Pika code field reference to the "pager" function that appears at the bottom of the case_list.html template, as so:
<div id="page-links"> %%[end:flex_footer]%% </div>
For now, we haven't done anything with it other than resize the font in the stylesheet:
#page-links {
font-size: 110%;
}
But the named selector is now there as a future hook for applying CSS. You know, after we've recovered from the abyss-trauma thing.
Oh, yeah. Did we happen to mention that full-size screenshots of this redesigned page and all the others in the Claire series are on view at the Project Claire Design Gallery (http://www.openpika.org/gallery.html)?
Next: Step 21: Time Slip and MSR Screens
Related articles and files:
