Under the Hood
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
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.
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
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:
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,
- Include Requirements & Contribution Sub Types
June 9, 2014
- User Case Story from Hope Community Church
October 28, 2013
- Group Search Categories and More
October 21, 2013
- Account Creation
August 7, 2013
- Single Sign On Functionality Exposed
June 25, 2013
- API Communication Value Changes
November 2, 2012
- API Enhancement: Create and Edit Groups!
August 13, 2012
- API Enhancement: Requirements Exposed
June 25, 2012
May 23, 2012
- Resource Versioning
April 24, 2012
- Enter Visitor Data via Your Church Website
March 16, 2012
- Fellowship One & Planning Center Online
March 1, 2012
- API Libraries and Sample Code
February 7, 2012
- Building a custom login for your church website using the API
November 29, 2011
- Roll Foward!
August 9, 2011
- The Agile Triangle
July 27, 2011
- Conversation Paralysis
July 7, 2011
- Picture this, image updates & creates through the REST API
May 10, 2011
- A REST API double shot : Groups and Events realms
May 9, 2011
- Increasing Software Delivery by 500%
May 3, 2011