After the initial learning curve, this has all been going swimmingly. I merged my first development branch into the trunk yesterday, and this branch just so happens to dovetail nicely into the whole point of this post, which is the YUI compressor, an open-source javascript and CSS minification tool developed by Yahoo’s YUI team.

The Problem

To understand quickly why one should minify production client-side code, consider only that with the upward trend of size in javascript libraries (and the necessary files for such libraries), it’s possibly to be downloading a lot of client-side code in a typical web application, especially as its scope grows.

For a long time, I was using Dean Edward’s Packer, as was everyone, because its Base62 encoding produced the very lowest file size. However, what should have been obvious to everyone is that eval(bunch_of_stuff_goes_here) is making the browser do a lot more work, and this is a problem on dinosaurs like IE6.

To make matters worse, the nature of such encoding also meant that for servers which tried to compress outgoing content like javascript (either with zlib or gzip), the compression ratio suffered. Just look at this table that Julien Lecomte posted last August.

I said to myself, “Hey, we use a lot of this stuff, and we still support a lot of users with slow computers and slow browsers.” So, I moved our project from a Packer-based compression to a YUI-based compression, and turned on server-side GZIP compression for javascript files. The only problem was that I was storing the javascript files already minified, and simply pasted them into a large a couple of large global .js files. I had to keep a separate source directory, along with any customizations.

This got to be a pain in the ass, as you might well expect, and so when it occurred to me that I might be able to use the YUI library at build-time in our Netbeans project, I immediately sprung into action.

This was around April, and one night while attending Sungard Summit in Anaheim. I did the initial work to get our Netbeans project into a state that could use the YUI compressor at build-time, creating separate source file directories and breaking our massive javascript file into modules; I did the same with our CSS, splitting it up based on what it decorated.

There are a few tutorials about using the YUI library. Some of them involve adding the YUI library to Ant’s classpath (didn’t want to go down this route); a lot of them involve invoking the library as an external executable during the build process, which is messy.

The solution I finally settled on was yui-compressor-ant-task, a small library that allows Ant to use YUI as a build task. By adding this library and the YUI compressor library to our common libraries folder, and enabling them at build only (and not for deploying in the web archive), it makes using the compressor pretty easy.

Here’s part of our build.xml:

<!--
   * minify will concatenate all of our non-TinyMCE javascripts and stylesheets
   * then use the YUI compressor library to compress them
   -->
   <target name="minify">
       <!--${libs} is path to the downloaded jars -->
       <property
           name="yui-compressor.jar"
           location="${file.reference.yuicompressor.jar}" />
       <property
           name="yui-compressor-ant-task.jar"
           location="${file.reference.yui-compressor-ant-task.jar}" />
 
       <path id="task.classpath">
           <pathelement location="${yui-compressor.jar}" />
           <pathelement location="${yui-compressor-ant-task.jar}" />
       </path>
 
       <!-- yui-compressor task definition -->
       <taskdef
           name="yui-compressor"
           classname="net.noha.tools.ant.yuicompressor.tasks.YuiCompressorTask">
 
           <classpath refid="task.classpath" />
       </taskdef>
 
       <!-- concatenation of javascript -->
       <echo message="Building global javascript" />
       <concat destfile="${build.dir}/web/common/js/global.js" force="no">
           <!-- explicitly order js concat because ordering matters here -->
           <fileset dir="${build.dir}" includes="web/common/js/jquery.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.bgiframe.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.hoverIntent.js" />
           <fileset dir="${build.dir}" includes="web/common/js/ui.core.js" />
           <fileset dir="${build.dir}" includes="web/common/js/ui.autocomplete.js" />
           <fileset dir="${build.dir}" includes="web/common/js/ui.datepicker.js" />
           <fileset dir="${build.dir}" includes="web/common/js/ui.tabs.js" />
           <fileset dir="${build.dir}" includes="web/common/js/tablesort.js" />
           <fileset dir="${build.dir}" includes="web/common/js/customsort.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.blockUI.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.form.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.ifixpng.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.superfish.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.cluetip.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.scrollTo.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.jqModal.js" />
           <fileset dir="${build.dir}" includes="web/common/js/validation.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.timeentry.js" />
       </concat>
 
       <!-- concatenation of cascading stylesheets -->
       <echo message="Building global cascading stylesheets" />
       <concat destfile="${build.dir}/web/common/css/global.css" force="no">
           <fileset dir="${build.dir}" includes="web/common/css/base.css" />
           <fileset dir="${build.dir}" includes="web/common/css/superfish.css" />
           <fileset dir="${build.dir}" includes="web/common/css/announcements.css" />
           <fileset dir="${build.dir}" includes="web/common/css/myvt.css" />
           <fileset dir="${build.dir}" includes="web/common/css/forms.css" />
           <fileset dir="${build.dir}" includes="web/common/css/cluetip.css" />   
           <fileset dir="${build.dir}" includes="web/common/css/tables.css" />
           <fileset dir="${build.dir}" includes="web/common/css/ui.tabs.css" />
           <fileset dir="${build.dir}" includes="web/common/css/ui.datepicker.css" />
           <fileset dir="${build.dir}" includes="web/common/css/ui.autocomplete.css" />
           <fileset dir="${build.dir}" includes="web/common/css/linkspan.css" />
           <fileset dir="${build.dir}" includes="web/common/css/stepMenu.css" />
           <fileset dir="${build.dir}" includes="web/common/css/print.css" />
           <fileset dir="${build.dir}" includes="web/common/css/youHaveMessages.css" />
       </concat>
 
       <!-- invoke compressor -->
       <yui-compressor warn="false" charset="UTF-8" fromdir="${build.dir}" todir="${build.dir}">
           <include name="web/common/js/global.js" />
           <include name="web/common/css/global.css" />
       </yui-compressor>
 
   </target>
 
   <!--
   * purge-src takes our compressed files, moves them to the base /common dir
   * and deletes the source js and css dirs from the build dir
   -->
   <target name="purge-src" depends="minify">
       <echo message="Purging javascript and stylesheet sources" />
 
       <move file="${build.dir}/web/common/js/global-min.js" tofile="${build.dir}/web/common/global.js"/>
       <move file="${build.dir}/web/common/css/global-min.css" tofile="${build.dir}/web/common/global.css"/>
 
       <delete dir="${build.dir}/web/common/js" />
       <delete dir="${build.dir}/web/common/css" />
 
   </target>

What you see there is essentially four steps.

1. Concatenate all the constituent source files into a global.js and a global.css
2. Compress both of these files, which creates global-min.js and global-min.css (default behavior)
3. Move these files out of the source directories and into the root of the common web directory as global.js and global.css
4. Delete the source directories in our build folder so they don’t get deployed with the web archive

Because certain browsers (IE) break without explicit ordering, we unfortunately can’t just use “*.js” and “*.css” in our concatenation step, but having to explicitly list our components in the build file certainly isn’t the end of the world. The nice thing is that the Ant task will even print out handy statistics on just how much you’ve been able to compress the files down. In our case, we have about 441.8KB of common Javascript and CSS in our source code that, by the time it gets sent to the user, has been minified and/or gzipped to about 89KB.

The Problem

Admissions needed help. They had been moved from their former product, Exeter, to Banner’s native admissions module. But Banner’s interface stinks, and there was no decent way for counselors to do, well, anything. They relied on daily reports run out of an Excel pivot table by the executive directory of admissions, and therefore they lived on paper. The counselors needed a better way to get their work done and stay on top (figuratively speaking) of their recruits.

Enter my department. It fell to us, after some discussion, to build a tool that would be initial for undergraduate counselors, to let them slice and dice their data as needed. After a pilot run, it will gradually be expanded to include graduate and transfer admissions, as well as reporting tools for directors and and other muckity-mucks.

The current iteration is 4808 lines of code, for both the views and the comment submissions servlet. Most of it was written by me, though some was reused code, and the initial servlet skeleton was written by my boss.

Setting Parameters

The first thing an admissions counselor sees is a parameter page. There are a number of options to choose from:

• Term (can be multiple)
• Population selection (e.g. active applicants, active but non-applied recruits, enrolled applicants, etc)
• Student level (can be multiple)
• Recruiter (signed-in counselors will be auto-selected (can be multiple)
• High School (can be multiple)

Selecting from term or student level repopulates the possible recruiter list with only applicable options. Selecting “Undergraduate” applicants will necessarily filter out (or should filter out) graduate admissions counselors so they’re no longer an option.

Perhaps the toughest engineering challenge here was high schools. We currently have ≈10’000 high schools in our database, and will likely have a lot more soon. Loading all those into a multiple select box would make the page huge, and likely overload some underpowered browsers. My solution? Autocomplete. Using a simple JSP fragment and the Autocomplete plugin for jQuery, I was able to make a simple autosearch/complete behavior; selecting an item drops it into a list below the input box.

The odd thing about the plugin was that it didn’t end up being very flexible about the format of returned data. I had figured it would ask you to specify a data type and do your own parsing. It seems, though, that it only wanted one format: pipe-delimited data, with newlines between records. After wrestling with it for a while, I finally got it to work, but I really would have rather just returned XML and done some simple parsing.

The Table View

Once the parameters are chosen, the user gets a very complex table (the specifications were given to us by the Admissions department).

• Name
• Term (if >1 chosen)
• High School (if >1 chosen or none specified)
• Intended major (code display; full description on hover)
• Application decision (e.g. accepted, denied, etc) (code display; full description on hover)
• Student type (e.g. new freshman, transfer, etc)
• Athlete indicator
• Registered indicator
• Application status
  • Green: complete, no pending items
  • Yellow: complete, but pending items which don’t affect admission
  • Red: incomplete: pending items affect admission
  • None (has no application; is only a recruit)
• Financial Aid
  • Green: all items complete, and aid is packaged
  • Yellow: all items complete, but aid is not yet packaged
  • Red: outstanding items; aid cannot be packaged
  • None (has no financial aid)
• Date of application
• Composite admissions score
• Date of last comment (usually a contact with applicant)
• Visited campus indicator (is not currently used)

The recruiter can export this table as an Excel document for easy printing and carrying; otherwise, clicking on a recruit/applicant’s name will bring up a detail screen, which is divided into several sections.

The Detail View

Basic

I call it basic, but this is really the most detailed tab of this entire view.

• Application-related Items
  • Entry Term
  • Source
  • Major
  • Admissions Counselor
  • Application Status
• Biographical Items
  • Banner ID
  • PIN (for helping with portal access)
  • Last Portal login
  • Student Type
  • Advisor (email link)
  • Residence (dorm icon for on-campus, car icon for commuter)
  • College (Education, Arts & Science, etc)
  • Date of Birth
  • Phone Number(s) (shows primary; expands to show others)
  • Email Address(es) (shows primary; expands to show others)
  • Address
• Holds (is only shown when there are holds on the student’s account)
  • Hold Type
  • List of items which this hold prevents
• Education
  • High School (for undergrad and transfer)
    • Name of high school
    • Graduation Date
    • GPA
    • Class rank
    • ACT composite score
  • College (for graduate and transfer)
    • Name of college
    • Dates of attendance
    • GPA transferred
• Athletics (list of sports/activities)

Checklist

The checklist is a simple table displaying pending and completed items necessary for admission. The applicant sees the exact same table when they sign into the portal, so now the counselor can see what the applicant sees.

Mailings/Contacts/Comment

This is a tripartite screen. The first and most important section is “Comments,” which is a sort of chronicle of counselors contacts with the applicant or the applicant’s parents. This screen is especially nasty using the native Banner interface, and so the object was not only to make the viewing nice, but also allow for the deletion, editing, and creation of comments.

Contacts and mailings are merely for records of correspondence the applicant or recruit has received, aggregated from several places.

Financial Aid

This screen gives detail of all awarded financial aid, as well as both completed and outstanding documents. This, too, is almost exactly what the applicant will see when signed into his or her portal.

Bill

This screen, which details charges and payments for the student, is once again a replica of screens available to the applicant when logged in. These screens are mostly to provide parity for support with applicants who have questions about financial aid, bills, or schedules.

Schedule

Once an applicant is accepted, and registers for class, this schedule tab will be filled out. It is a slight modification of the student’s schedule, which is displayed to them upon portal sign-in. Advisor see a similar view, since this is a module we reuse in several different portions of the web app.

The Big Finish

There are always bugs. I realize, just before going live, that the abbr tag that I used so heavily in the tabular view isn’t natively supported by Internet Explorer 6.

Luckily, good old Dean Edwards notes that for some reason, prefixing the namespace to the <abbr> tag makes the damn thing suddenly work, and it’s still valid XHTML! Crisis averted.

As with most of our web application, we make heavy use of jQuery. Specifically for this application, we make use of the UI Tabs plugin, the UI Autocomplete plugin, and jQuery’s native AJAX functionality. We also use the Unobtrusive Tablesort Script from Frequency Decoder, which has much better performance than jQuery equivalents.

As I said, this is only a first try at a first stage, but we’re pretty happy with the progress, and the admissions folks seem to be as well, so we’re doing something right.

Some of you remember that I joined the 9Rules network a while ago. At the beginning of October, 9Rules members got an e-mail advertising a new membership agreement.

After talking it out in Clubhouse, we made participating either in the private member area or my.9rules a requirement, part of the membership agreement. This goes back to the 9rules core because that is the way it used to be except members naturally interacted with one another so a requirement was not necessary [...]

If you feel you are contributing by your entries being shown only, 9rules is no longer a good fit for you, decline the agreement (or do not respond), please remove the leaf from your site and we will remove your site from displaying on 9rules.

I was in the middle of a move at the time, and the news underwhelmed me. Clearly, I thought, I haven’t even had the time to blog very much lately, much less blog and start arbitrarily posting in a forum. So, though it seemed a shame, I ignored the e-mail and passed quietly from the 9Rules world.

When I redesigned my site, I began thinking more heavily about the little leaf I was excluding, and became a little more irritated at the whole thing. A couple of years ago, 9Rules was a “Who’s Who” of the blogging world. It highlighted the best designs and the best content. It didn’t ask for anything else. This is partly why I joined it.

And perhaps it was my generation that finally changed things. Mandatory forum posting? Really? When did 9Rules become a glorified social network? Wasn’t it all about driving users to good content?

Apparently, I’m not the only one who was peeved, as there seems to have been a mass exodus of really excellent blogs in response to the revised membership agreement.

• Broken Kode
• Chris J. Davis
• Standards for Life
• Open Switch
• h0bbel.p0ggel.org
• Wynia
• Seopher
• I-Marco
• Transformatum
• baires.elsur.org
• Dan Lockton
• h3h

9Rules is, of course, free to do as it wants. If this is the direction that it wants wants go, more power to it. But it’s a different 9Rules than the one I joined (or thought I did), and I’m feeling better every day about my decision to leave.

As I said in a previous comment, the problem with having content about a new theme is that it won’t be relevant when the theme goes away or changes. So this post is to both exhibit and archive this theme so that there is some record of it.

Hooloovoo

toggle thumbnails

It’s a different creature than I’m used to—I’ve never not had a sidebar, but I decided that perhaps a sidebar wasn’t the best way to do things. I moved that sort of ancillary data to the top, but I used a pull-down menu á la Foliage mod. Since sidebar data tends to not be particularly important to the content anyway, it doesn’t need to take up real estate.

Metadata, while displayed more or less inline on the index page, is moved down into a content footer on the individual post pages. This kind of graphical metaphor is actually very common now, but I’ve wanted to do it ever since I saw it in Hemingway about a year and a half ago. Like the upper menu, I’m dividing into thirds, and iterating with lists.

In general, I’ve tried to round off a lot of corners. This involves more images than I’d normally like, but I’ve tried to take shortcuts wherever possible, combining multiple images and simply changing their positioning: I managed to reduce the number of server requests significantly from the early phases of the design, but I still have some more to go.

Which brings me to another thing: I’ve used some 24-bit PNGs, not only as icons but as background images as well. I made a half-hearted attempt to use ifixpng to resolve display issues for IE6, but when it didn’t work satisfactorily, I decided that I spend enough timer catering to IE6 users and work, and I’ll be damned if I’m going to expend any extra effort on my hobby site. So let me make myself clear:

Attention IE6 users: there is no good excuse to be using IE6. Either upgrade or use a different browser. Firefox is good, as is Opera. Or go away.

On with the tour: I’ve heavily incorporated the jQuery javascript library into my redesign, and attempted to make it as performance-tuned as possible by including the extra plugins in a common file, and gzipping everything on the fly.

Beyond that, the theme is pretty unremarkable, really, but (I hope) aesthetically-pleasing and useful. I’ve completely removed categories from the template, since I think that tags have much more utility.

Comments? Questions? Suggestions? Venom?

Blockquotes, by definition, can and should in most cases have a title attribute and, if possible, a cite attribute. The former is the actually name of the quote’s source. The latter is the URI to the quotes location, if it was retrieved online.

For instance:

<blockquote cite="http://heliologue.com" title="A Modest Construct">
 
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Integer arcu ligula, tempus vel, dignissim at, molestie ut, leo. Etiam luctus, ipsum sit amet tincidunt malesuada, magna nisi feugiat eros, in tempus libero justo sed dui. Aliquam bibendum pulvinar turpis. Ut iaculis gravida nibh. Quisque elementum ligula vel nibh. Sed leo augue, tempor sed, nonummy in, interdum at, quam. Ut cursus tincidunt felis. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Integer pharetra vulputate nunc. Cras nec felis ornare augue tempor fermentum. Nullam rutrum malesuada nunc. Aliquam vel purus. Aliquam faucibus malesuada orci. Nulla sit amet nulla sit amet tortor fermentum euismod.
 
</blockquote>

This is all well and good for search engines, but it doesn’t do much for human readers (who are arguably more important, though it depends on who you ask). A human might want to see something like this:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Integer arcu ligula, tempus vel, dignissim at, molestie ut, leo. Etiam luctus, ipsum sit amet tincidunt malesuada, magna nisi feugiat eros, in tempus libero justo sed dui. Aliquam bibendum pulvinar turpis. Ut iaculis gravida nibh. Quisque elementum ligula vel nibh. Sed leo augue, tempor sed, nonummy in, interdum at, quam. Ut cursus tincidunt felis. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Integer pharetra vulputate nunc. Cras nec felis ornare augue tempor fermentum. Nullam rutrum malesuada nunc. Aliquam vel purus. Aliquam faucibus malesuada orci. Nulla sit amet nulla sit amet tortor fermentum euismod.

A Modest Construct

Which I achieved by appending

<cite class="source">
     <a href="http://heliologue.com" title="A Modest Construct">A Modest Construct</a>
</cite>

to the blockquote.

But nobody wants to hard-code a citation into every blockquote, especially when it’s technically correct to attach the information to the semantic element in question (the blockquote, for those of you not following along). So, how to be structurally correct when using blockquotes, while still allowing human readers the benefit of such data?

Well, there are a number of methods. If you’re using a CMS or any kind of dynamically-generated page, you can use the system itself to parse blockquotes for their attributes and reuse that information.

The Old Way

A somewhat simpler and more flexible solution would be Javascript, which isn’t foolproof, but should be good enough for most people. Previously, I used Dunstan’s Blockquotes, which was an excellent solution for a long time.

function extractBlockquoteInfo()
        {
        quotes = document.getElementsByTagName('blockquote');
	for (i = 0; i < quotes.length; i++)
		{
		cite = quotes[i].getAttribute('cite');
		title = quotes[i].getAttribute('title');
		if ((cite) && (cite != ''))
			{
			if ( (cite.match('http://', 'i')) || (cite.match('ftp://', 'i')) || (cite.match('person://', 'i')) )
				{
				newlink = document.createElement('a');
				newlink.setAttribute('href', cite);
				newlink.setAttribute('title', ('Go to ' + cite));
				title = quotes[i].getAttribute('title');
				if ((title) && (title != ''))
					{
					newlink.appendChild(document.createTextNode(title));
					}
				else
					{
					newlink.appendChild(document.createTextNode('Quote source'));
					}
				newdiv = document.createElement('div');
				newdiv.className = 'source';
				newdiv.appendChild(document.createTextNode('\u2014 '));
				newdiv.appendChild(newlink);
				quotes[i].appendChild(newdiv);
				}
			else
				{
				newdiv = document.createElement('div');
				newdiv.className = 'source';
				newdiv.appendChild(document.createTextNode('\u2014 ' + cite));
				quotes[i].appendChild(newdiv);
				}
			}
 
		else if ((title) && (title != ''))
			{
			newdiv = document.createElement('div');
			newdiv.className = 'source';
			newdiv.appendChild(document.createTextNode('\u2014 ' + title));
			quotes[i].appendChild(newdiv);
			}
		}
	}
 
window.onload = function(e) {
extractBlockquoteInfo();
}

The New Way

I ran into conflict issues, however. Also, the script seems overly complicated for what it’s doing. I long ago chose my spot in the jQuery camp, and am currently using it on this blog for Thickbox and a few other miscellaneous things. So I thought: why not get blockquote data using jQuery? Here’s my resulting code (which I’m sure is flawed and crufty, but I put it together in about five minutes; suggestions are welcome).

$(document).ready(function(){
     $("blockquote").each(function(){
          var title = $(this).attr("title");
          var cite = $(this).attr("cite");
 
          if (cite == null && title != null) {
              $(this).append("<cite class='source'>"+title+"</cite>");
          }
 
          else if (cite != null && title == null) {
               $(this).append("<cite class='source'><a href='"+cite+"' title='"+cite+"'>"+cite+"</a></cite>");
          }
 
          else if (cite != null && title != null) {
               $(this).append("<cite class='source'><a href='"+cite+"' title='"+title+"'>"+title+"</a></cite>");
          }
 
          else {
          }
     });
});

Essentially, I’m looking for blockquotes that contains at least one of our particular attributes, and then parsing them for title and cite values. There are four possible outcomes:

1. title but no cite:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Integer arcu ligula, tempus vel, dignissim at, molestie ut, leo. Etiam luctus, ipsum sit amet tincidunt malesuada, magna nisi feugiat eros, in tempus libero justo sed dui. Aliquam bibendum pulvinar turpis. Ut iaculis gravida nibh. Quisque elementum ligula vel nibh. Sed leo augue, tempor sed, nonummy in, interdum at, quam. Ut cursus tincidunt felis. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Integer pharetra vulputate nunc. Cras nec felis ornare augue tempor fermentum. Nullam rutrum malesuada nunc. Aliquam vel purus. Aliquam faucibus malesuada orci. Nulla sit amet nulla sit amet tortor fermentum euismod.

2. cite but no title:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Integer arcu ligula, tempus vel, dignissim at, molestie ut, leo. Etiam luctus, ipsum sit amet tincidunt malesuada, magna nisi feugiat eros, in tempus libero justo sed dui. Aliquam bibendum pulvinar turpis. Ut iaculis gravida nibh. Quisque elementum ligula vel nibh. Sed leo augue, tempor sed, nonummy in, interdum at, quam. Ut cursus tincidunt felis. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Integer pharetra vulputate nunc. Cras nec felis ornare augue tempor fermentum. Nullam rutrum malesuada nunc. Aliquam vel purus. Aliquam faucibus malesuada orci. Nulla sit amet nulla sit amet tortor fermentum euismod.

3. cite and title:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Integer arcu ligula, tempus vel, dignissim at, molestie ut, leo. Etiam luctus, ipsum sit amet tincidunt malesuada, magna nisi feugiat eros, in tempus libero justo sed dui. Aliquam bibendum pulvinar turpis. Ut iaculis gravida nibh. Quisque elementum ligula vel nibh. Sed leo augue, tempor sed, nonummy in, interdum at, quam. Ut cursus tincidunt felis. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Integer pharetra vulputate nunc. Cras nec felis ornare augue tempor fermentum. Nullam rutrum malesuada nunc. Aliquam vel purus. Aliquam faucibus malesuada orci. Nulla sit amet nulla sit amet tortor fermentum euismod.

4. no cite and no title:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Integer arcu ligula, tempus vel, dignissim at, molestie ut, leo. Etiam luctus, ipsum sit amet tincidunt malesuada, magna nisi feugiat eros, in tempus libero justo sed dui. Aliquam bibendum pulvinar turpis. Ut iaculis gravida nibh. Quisque elementum ligula vel nibh. Sed leo augue, tempor sed, nonummy in, interdum at, quam. Ut cursus tincidunt felis. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Integer pharetra vulputate nunc. Cras nec felis ornare augue tempor fermentum. Nullam rutrum malesuada nunc. Aliquam vel purus. Aliquam faucibus malesuada orci. Nulla sit amet nulla sit amet tortor fermentum euismod.

I think that the <cite> element is the most semantically correct, but of course you’ll have to change that to fit your needs. I style it like this:

blockquote cite.source {
     text-align: right;
     border-top: 1px dashed #aaa;
     font-size: 0.95em;
     display: block;
     }

And there you go. An excellent Javascript library, a few lines of code (more than necessary even, as I wanted to cover all the possible cases), and you’ve got a flexible solution to blockquote citations.

Cleveland is a funny place. Like Wisconsin, it’s significantly greener than Illinois, and I find myself surprisingly aflush at the sight of all the verdure, but Cleveland is like a rusted, hulking monolith overgrown by jungle. The juxtaposition is frightening: while lost, we drove along so many leafy parkways lined with large embellished houses, but our destination was inevitably in the sprawl of the city itself, hemmed together with slummy, apartmented streets and the blackened faux-marble of the botanical gardens, the public library, and the enormous Presbyterian church on Euclid Ave. One building along a main drag called Chester St. appeared to have two dark bronze statues of skeleton warriors, as though someone had stitched together twisted detritus from a plane wreck to make this thanatotic duo, their sharp ribs prominent, their wielded swords even moreso.

It rained all three days we were there, in random spurts of thunderstorms. Cleveland’s drainage—at least downtown—isn’t the best, as even a relatively gentle storm left standing pools of water on the roadsides and muddy ponds in the grassy medians as late as the next morning. I’ve already said that Cleveland is organic, but add near-constant construction and rain to the list, and the city itself is a violent storm of confusion, parkways ceding to slums, trees to effaced apartment complexes, prestigious university to vacant, overgrown gas stations.

I realize that I saw but a fraction of the city, but I would expect that the university-dominated section would be a thriving little community of its own. Perhaps things are different during the school year: I saw few college students at all; only middle-aged conference attendees and the occasional gaggle of misguided tourists—why Cleveland?—gaping at the squalor.

A Retrospective on Ben qua Conference Attendee, as Well as a Discussion of Code

But enough sentiment. My own journey to get here, in a plain grey van, speeding down I-480, was just as mixed. I woke at 7:09 this morning and —my understanding being that only my boss and his boss were going to the presentation at 10:30—went back to bed, to be awoken exactly four hours later at 11:09 by the sound of little kids (?) playing soccer on the athletic field next door. I was alone—all four of my companions had gone to the presentation, had even called for me through the door of my sleeping area, but to no apparent avail. The neck-ache I awoke with had nothing on the painful feeling of being such a schlub.

I mentioned last night that the recurring theme of the conference was that Oracle’s portal is utter shit. To that end, I find myself excited not by the opportunity to work with it, my loving ministrations being severely limited by its obstinate nature, but the opportunity to work with Tim, our DBA and resident Java guru, on his separate-but-not webpiece that will tie into the portal. Having seen yesterday’s presentation on Web 2.0 and AJAX, he and I decided that it would be a good idea to integrate it into his webpiece. Since the logic that drives the overhead menu requires database calls, we thought that using AJAX to load content into the specified area would reduce overhead and feel more responsive to the user, broken back-button or no. So, during the afternoon session on Thursday, I found a little AJAX script and made a working prototype with static HTML. Tim came back from his afternoon session with news of OS3Grid, a Javascript-based table system that allows for dynamic reordering, editing, and effects that wouldn’t be possible in IE with pure CSS. The only problem is that they don’t want to work together: the function to render the grid is run on page load, which doesn’t work if you are loading the grid’s host page with AJAX. I hacked up a fix by adding a new line to the AJAX script’s pageload function that reevaluates OS3Grid’s table-rendering function, forcing the grid to be rendered when the page was loaded with AJAX. The only problem is that each grid has a specific line that has to include the name of the parent div that hosts the rendered table, and since we’re guaranteed to have pages with multiple tables, we can’t simple hard code a standard id into the function and let it go. I will need to research other methods of forcing the script to run.

These are both neat Javascript tricks, but the real question is how well we can get them to work with the database. The AJAX function for navigation is entirely client-side: there’s not yet AJAX to submit any forms or grab any data from the database—it merely calls a JSP, which in turns talks to the database. One of the interesting features of OS3Grid, however, is the ability to edit table contents, and I’d like to make it so that an edited table cell submits—via AJAX, of course—back to the the database the changed contents. For that, I’ll need Tim’s help in using AJAX to talk to Java to talk to the database. It’s possible, of course, but my experience with Java is so limited that the slightest problem will sending me running to Google. Still, I think that this has the potential to be a really great interface, and I really like working with Tim because he’s truly excited about what he’s doing, and he asks things of me that push my limits and force me to improve my knowledge set.

The default blockquote style in K2 is a simple indent and a left-positioned PNG openquote. Not only is the quote graphic kind of ugly (a not-very-stylized grey), but it seems incomplete in that it’s only an openquote, and doesn’t include a closequote. Because it’s set as a background image, of course, we can’t have two (one for open, one for closed).

In my old theme, I solved this with a messy hack wherein I searched and replaced all blockquotes with a blockquote and a nested div. I set the blockquote to have the openquote in the top left and the div to display the closequote in the bottom right. Semantically bad, but it worked.

For K2, though, I wanted less cruft, but I wanted to accomplish the same basic thing. Enter CSS and Design Meme’s Curly Quotes idea. It uses :before and :after pseudo-classes to add areas before and after the blockquote. Then it uses the content attribute to add in open-quote and close-quote. It’s an elegant solution, but it has two problems. One: it’s not cross-browser (IE doesn’t support pseudo-classes). Two: even among CSS-compliant browsers, the handling of the open-quote and close-quote varies. Obviously, I want the quotes to appear as “” and not "". However, only Firefox 1.5 did that: Opera 8.52, Safari 1.3, Firefox =< 1.0.7 and others all displayed ".

So, I changed

content: open-quote | close-quote

to

content: """ | """

Still no luck. Only Firefox 1.5 would display them correctly. The others just gave me marks that looked more like 11s than stylized quotes. So, I went back to my old theme, grabbed the quote images, resized them to 50px and adapted the CSS to use images instead of content. Here’s the result:

blockquote {
display: block;
padding: 0 60px 0 60px;
width: 350px;
border: 1px solid #c6c9ff;
background-color: #f0f0ff;
margin-left: auto;
margin-right: auto;
}
 
blockquote:before, blockquote:after {
color: #616d9f;
display: block;
font-size: 900%;
width: 50px;
font-family:  'Georgia', 'Times New Roman', serif;
}
 
blockquote:before {
content: "";
background-image: url(images/quote1.png);
background-repeat: no-repeat;
background-position: left top;
height: 0px;
margin-left: -0.55em;
padding-top: 60px;
margin-bottom: -50px;
}
 
blockquote:after {
content: "";
background-image: url(images/quote2.png);
background-repeat: no-repeat;
background-position: right bottom;
height: 50px;
margin-top: -50px;   
margin-left: 360px;
padding-bottom: 0px;
margin-bottom: 0px;
}
 
blockquote cite {
display: block;
text-align: right;
border-top: 1px dashed #69c;
margin-bottom: 0px;
padding-bottom: 0px;
margin-top: 5px;
}

The rendering is pretty good—except for IE6, which doesn’t display the images at all, but degrades pretty gracefully—but I can’t for the life of me figure out why Opera pushes the open-quote so far to the right (see below). Anyone have any ideas? I was able to fix it. For some reason, I overlooked the fact that the original curly quotes designer had used em width only for the left margin on the blockquote:before declaration. When I noticed that Opera seems to handle em a bit differently than its peers, it clicked.

Safari 1.3.2 [OS X 10.3]

Safari 2.0.3 [iCapture]

Konqueror 3.4.2 [SuSe 10]

Firefox 1.0.7 [SuSe 10]

Firefox 1.5.0.1 [Windows XP SP2]

Opera 8.5.2 [Windows XP SP2]

Internet Explorer 6.0 [Windows XP SP2]

Alas, we’re a small school, and still pretty stupid about some things. A laundry list of all of them (even those limited to the technological) would be beyond the scope of this post. One thing in which we’re stupid is our website, which is sprawling (the faculty tend to use the web server for storage instead of their network drive) and not database driven. We’re moving to a portal system in January ’06 (tentative), but we’ll still have a lot of the current site.

Therein lies one of my biggest problems: instead of pulling content dynamically and running it through some CSS, we’re still using crufty, hardcoded pages and the horrible, byzantine templating system of Dreamweaver.

Until summer of 2004, we were on a template created entirely by Adobe GoLive. Why anyone was ever allowed to use such a miserable program is completely beyond me: it filled the code with GoLive “actions”: in other words, proprietary markup similar to what Microsoft does with its created HTML files.

But I’m not going to talk about the template per se, because I have yet to tinker with that. I am, however, going to talk about the home page, which in many respects is far more important.

In 2002 (and up until 2004), we had a homepage that looked like this [copy stored on Archive.org]. The buttons weren’t distorted when we had it live, but that’s the basic look. In 2003, we updated the menu slightly. Take a look at the source, and you’ll see hundreds of lines like this:

<csaction name="GoLiveAction2" class="Set Image URL" 
type="onevent" val0="default_32" 
val1="http://www.stfrancis.edu/images/default_32- default_07_over.jpg"> 
</csaction>

The page itself isn’t that large: about 133KB without rollover images. Still, it obviously needed to go, as did the rest of the template. So, in early 2004, the Web Services Department began an extensive redesign effort. It was spearheaded by my boss, Mike, and had to go through committee after committee (since the website constitutes our online image) and revision after revision. I was a new guy at that point, so the actual design work was handled by my former coworker, Ryan. He was an excellent graphic artist, but his approach to the technical aspects of web design? Eh, not so good.

His method involved creating a screen-sized picture in Photoshop and then cutting it up in ImageReady. Then he further edited it in Dreamweaver, creating editable regions and places for text. To see his version of the homepage, click for the current USF homepage [stfrancis.edu] which still uses this system or an archived copy [Archive.org] from November of 2004. There have been no substative changes between then and now.

For starters, try looking at the background image alone. The first thing you’ll notice is that the background image is the homepage. The second thing you’ll notice is that it’s 203.51KB. That’s a lot for a 56K user (we do have them).

Secondly, look at the menu system. It’s ugly, inconsistent, and under the hood, completely inadequate. For starts, it’s hardcoded into every page (this same menu persists on all pages), which means that it needs to be reloaded every time. Secondly, it works by showing and hiding individual layers.

function MM_showHideLayers() { //v3.0
  var i,p,v,obj,args=MM_showHideLayers.arguments;
  for (i=0; i< (args.length-2); i+=3) 
if ((obj=MM_findObj(args[i]!=null) 
{ v=args[i+2];
    if (obj.style) { obj=obj.style; v=(v=='show')?'visible':
(v='hide')?'hidden':v; }
    obj.visibility=v; }
 
var timerID = "global";
function hideMenus() 
{
   // insert the MM_showHideLayers function you create that 
   // hides all popout layers. Be sure you put a semi-colon
   // at the end of the code. Here is an example:
   // MM_showHideLayers('menu1', '', 'hide', 'menu2', '', 'hide');
   MM_showHideLayers('AboutUSF', '', 'hide', 'Academics', '', 'hide', 
'Athletics', '', 'hide', 'Prospective', '', 'hide', 'StudentLife', '', 'hide', 
'Calendar', '', 'hide')
}
function startTimer()
{
   stopTimer();
   // the number "1000" is the number of 
thousands-of-a-second
 
 timerID = setTimeout("hideMenus()", 100);
}
function stopTimer()
{
   clearTimeout(timerID);
}

Later, in the body:

<td><a href="admissions/index.htm"
onMouseOver="MM_swapImage('Image5', '', 'images/indexr_08.gif', 1);
MM_showHideLayers('AboutUSF', '', 'hide', 
'Academics', '', 'hide', 'Athletics',
'', 'hide', 'Prospective', '', 'show', 
'StudentLife', '', 'hide', 'Calendar', '', 'hide'); 
MM_callJS('stopTimer()')" 
onMouseOut="MM_swapImgRestore(); 
MM_callJS('startTimer()')"> 
<img src="images/index_08.gif" 
width="169" height="28" name="Image5" 
border="0"/></a></td>

That’s a single rollover image in the menu that calls a layer to be shown. Byzantine, right? The total size for this incarnation of the homepage to be loaded is almost half a MB (420KB without rollovers). For any users on a slow connection, that means, basically, no access. Anyone who waits that long for a University web page to load is an idiot. Also notice the number of nested tables used in the layout (it’s worse on the content pages). Dreamweaver’s templates don’t play well with tables, so this means a lot of screw-ups when we do a template update.

You’ve probably gathered by now that none of the code that the University has used so far has been anything close to standards-compliant. As you can see from the links in my meta section, I’m all about standards compliance, so this bugs me to no end.

Last week, after my boss complained about how difficult it is to make any sort of changes to the homepage (he wants the white news section expanded), I offered to recode it. I can’t make any substantial changes to the look, of course, since that would require more committee meanings and long delays. I can, however, redo the guts.

Because of the way the University web server serves up CSS files (wrong MIME type: we’re in the process of fixing it), my testing version can’t currently be viewed on that server. However, I have hosted it on mine, so you may view my tentative design now.

The first thing you’ll notice is a redesigned header. It uses our new officially approved logo, but within a 100% div, so it stretches regardless of screen size. Same with the thinner brown bar below. One of my goals was to scale the design better. Mike says that we’re only going to officially support resolutions of 1024 x 786, so my end design scrolls a bit on lower, but is still functional.

The second thing you’ll notice is the redesigned menu. Not only does it blend better with the header, but it’s consistent in its look, is simpler (in a sense) by not simply showing and hiding div layers. Also, and more importantly, it’s all housed in 3 called data files, only one of which needs editing. This makes updating the menu sitewide a matter of seconds. The off/hover colors are not finalized, depending on what input we get. The menu is cross-browser (I’ve tested on Safari 1.x, IE 5.x, Netscape 7.x, IE 6.x, Firefox 1.0.x, and Opera 8.x).

Thirdly, the new design makes extensive use of CSS. The old one, to its credit, did use a CSS file, but only for setting a sitewide default font and <h1>. I expanded it later to stylize table elements and floating images. Still, this one uses CSS for everything, and will use it even more heavily for content pages.

One of the tricks I used CSS for was eliminating image rollovers. On the current layout, you’ll notice that the five central buttons (Faculty, Current Students, Alumni, &c.) have a rollover which turns them from a sepia tone to their actual RGB values. I dislike image rollovers in general (images are largely crufty), so I instead used an opacity effect to turn them from 75% opaque to 100% opaque on a hover. It was tricky, because IE 6 doesn’t support the addition of :hover to any elements besides anchors. Here’s my CSS:

#buttonset a:link img, 
#buttonset a:visited img, 
#buttonset a:active img, 
#buttonset a:focus img {
opacity: .75;
filter: alpha(opacity=75);
}
 
#buttonset a:hover img {
opacity: 1.0;
filter: alpha(opacity=100);
}

#buttonset is the floating div that houses the buttons in my version. Unfortunately, this opacity effects invalidates the standards compliance for CSS. If anyone knows a way around this, let me know. Also, Opera doesn’t show the hover effect, but since it is an infinitesimal portion of our user base, we’ll allow it. Otherwise, all tested browsers work with it.

Finally, we have the pesky news section. On the original site, the yellow news bar is graphically separate from the news section. I could have emulated this, but I thought it was better combined in a single element. I simply nested a block displayed div instead the larger news section and floated the whole thing. Something I had to grapple with after the face was getting all these different divs to clear each other; also, getting both IE and good browsers to handle the code in substantially similar ways. I really need to get my hands on a beta of IE7 and doublecheck that.

The total size for the loaded homepage is about 165KB. This is larger than I’d like, but I had to work within certain boundaries to ensure that the new design was visually compatible with the old one. I also console myself with the fact that since the menu system is separate from the page, and it persists throughout the site (as will several other key graphics), any decent browser will cache it and continue to use it during further perusal. Since the menu makes up 32KB of the load, this is significant.

Most importantly, though (to me), is the link you see at the bottom of my version that says “Valid XHTML.” Yes, it validates, even if the CSS doesn’t. I decided upon XHTML 1.0 Transitional because my boss likes to use the target="_blank" attribute a lot, and this was the only way for it to validate as such.

So, there you have it: my recent travails in the world of (semi-)corporate web design. Stay tuned, and I’ll eventually be able to write at length about redesigning the rest of the content pages, as well as all of the (enormous) headaches that such a thing entails.

For those of my readers with m4d h4xx0rz 5k1llz, any improvements or advice would be appreciated.