Under the Hood

Posted By: Nathan Smith on October 5, 2009

Whenever I hear about a new model of a classic sports car rolling off the assembly line, my first reaction is to wonder: "Ooh, what will it look like?" If the car ends up looking terrible, then that is usually the end of my curiosity. However, every now and again a roadster comes along that literally turns heads as it roars down the highway. Inevitably, this leads to observations such as "Wow, that looks awesome!" closely followed by questions like, "What type of engine is under the hood?"

In similar fashion, the latest rendition of our flagship web application has been significantly streamlined. The entire development team put in a lot of long hours to make it possible. I would like to take this opportunity to describe the changes to underlying technologies that power our newly refreshed Fellowship One portal. Basically, this endeavor was a complete redesign, meaning that all the front-end code was totally rewritten from the ground up.


One of the key changes we have made was moving from XHTML 1.0 to HTML5. In case you haven't been following along with all the drama between the ill-fated XHTML 2.0 and HTML5, here's a brief history. Essentially, HTML5 is the future. It began with the backing of companies such as Apple, Google, and Opera, and now has the support of Microsoft as well.

Google considers HTML5 to be such a game-changer that they recently announced plugin for Internet Explorer, dubbed Chrome Frame. After installing it, users can benefit from the newer features of HTML5 even if they are unable to upgrade their version of Internet Explorer.

For us, one of the immediate benefits of the HTML5 switch has been typing less code overall. I will not get into all the nitty gritty details in this blog post, but feel free to peruse our code standards document.

Suffice it to say that greater terseness (is that an oxymoron?) cuts down on the potential for typing errors, and less code overall means faster page loading times as well. In this aspect, HTML5 requires only the essentials, and eliminates the need to type superfluous attributes. It even adds the handy data-* attribute, which allows developers to store snippets of information in the DOM for use via JavaScript. This is something I am excited to make use of as we continue to add enhancements.

In addition to the aforementioned benefits of moving to HTML5, long-term implications also factored into our decision. We on the UX team are eager to do data visualization via the canvas tag. Once it gains wider browser adoption (read: Internet Explorer is holding us back) we will be able to have rich user interfaces that display varying permutations and cross-sections of information.

Canvas alone is reason enough to consider HTML5. You could think of the canvas element as a painter's palette that can be dynamically update with JavaScript. It is perfect for things like charts and graphs. Before, if the data changed, you would typically have to generate any new imagery associated with the data via the server-side. This placed you at the mercy of available platforms and plugins. By using canvas, an interface can be updated nearly in real-time, via live Ajax data calls.

CSS Improvements

While not as sweeping of a change as with HTML, we have made strides in our use of CSS. Whereas before much of the page layouts were handled via tables, now nearly everything is done via cascading style sheets. For browsers that support it (read: not Internet Explorer) we are using text-shadow, box-shadow, and border-radius to add a bit more elegance to an otherwise rectangular world.

For users on Internet Explorer, the application is still functional, just a bit more bland. This is an approach referred to as progressive enhancement. If you are using a modern browser like Firefox or Safari, then you get to experience Fellowship One in its most high fidelity form. If not, then you still have a solid user experience, minus a few elegant nuances. I think of it like watching regular television vs. HD - the content is still the same, albeit not quite as immersive.

We are also making use of the 960 Grid System, a CSS framework that allows for rapid prototyping and building of production ready web layouts. Our developers have grown accustomed to building page layouts by using 960 to create new .NET master pages. This allows us to map newly created pages to their appropriate templates. Overall, it's been a good workflow for us.

Along those same lines, the CSS that we have written specifically for Fellowship One has been modular and object oriented by design. This allows us to mix together several class names per element, each which has a particular effect, rather than having a series of IDs, which replicate similar chunks of code. By using a more object oriented approach, we can selectively sprinkle in specific styles, creating recipes out of a pre-defined set of ingredients. For more on this code philosophy, read...

.NET Master Pages

From a .NET standpoint, we took the time to take a step back and look at our templates from a high-level standpoint. This involved re-architecting our usage of master pages. For those who are familiar with PHP, this is similar to using include 'file.php' to piece together dynamic and static content. For those familiar with Ruby on Rails, this is akin to using layout 'template_name'.

Essentially, we have one site-wide template named Application.Master, which serves as a parent to three other templates: OneColumn.Master, TwoColumn.Master, and FreeStyle.Master. From there, *.aspx pages inherit from one of those three templates. Our master page hierarchy looks like this:

Application.Master applies site-wide to all pages. OneColumn.Master and TwoColumn.Master are pretty self-explanatory, creating a single or double column layout. In terms of the 960 Grid System, OneColumn.Master spans all 16 grid units, whereas TwoColumn.Master uses 11 grid units for the primary content, and 5 grid units for the sidebar. FreeStyle.Master is essentially just a page template with the header and footer pre-defined, but allows for a developer to hand-code the columnar layout, sub-dividing as needed. From a directory tree standpoint, here's an example:

—— OneColumn.Master
——— PageName.aspx
——— PageName.aspx
—— TwoColumn.Master
——— PageName.aspx
——— PageName.aspx
—— FreeStyle.Master
——— PageName.aspx
——— PageName.aspx


Well, I guess that wraps things up for now. Without belaboring the point, let me just say that we really had a lot of fun rebuilding the Fellowship One portal. If you have a minute to spare, check out this satirical video we put together about what went into the redesign. If you have any feedback or questions about our design patterns or code standards, please let us know in the comments.

Posted In: News,

Tracy Mazelin said: on October 5, 2009 at 09:04 PM

Can’t wait to see it in the staging environment!!

Mark said: on October 6, 2009 at 06:13 AM

Where is this on the timeline to roll out?

Matt Vasquez said: on October 6, 2009 at 08:40 AM

@Mark - The ACE team will be communicating the delivery date, it should be in our staging environment soon.

Floyd Soule said: on October 13, 2009 at 06:57 AM

What impact do these changes have on WebLink?

We have a very large online giving community!  Large number are IE7 users!

Changes look great!

Matt Vasquez said: on October 13, 2009 at 10:30 AM

@Floyd - there will be no impact to WebLink. IE7 will continue to be supported in all of our products. Portal will no longer support IE6.

Commenting is not available in this channel entry.