There are a number of priorities that must be defined at the outset of any development project. Depending on the type of project, these priorities will change. Because we’re an agency, an overarching goal was to provide an experience that was as consistent as possible for all site visitors. This meant being wise about what browsers we support, how we use CSS, JavaScript or Flash, and how we could optimize the site. This article outlines our development goals and how we accomplished each one.
Browser Support
Goal: Provide support for majority of users, based on known data.
FIG. 1 - Google Analytics overview of browser usage.
You still can’t talk about browser support without determining what you’re going to do about Internet Explorer. According to the W3C, global usage of IE has fallen to ~25%, down 5 points from this time last year, and down 15 points from this time two years ago. While IE7 and IE8 provided us support for the low hanging fruit, CSS3 support wasn’t more fully baked-in until IE9, so we were still left with decisions on how to handle effects, transitions, &c. for these “in-between” versions.
It had been a while since we celebrated the death of IE6, however we were still not only having to provide IE6 support for most of our client sites, but also for ours. Analytics showed a ~1% usage of IE4-6, so it was time to say good-bye. We decided that once usage of these browsers fell below 5%, we would no longer offer support. It isn’t that we don’t care about the experience these folks have while visiting our website, we just think they should use a proper browser!
In addition to full support for versions of IE7+, we also focused on fully supporting Firefox, Chrome and Safari, which collectively represented over 95% of our site visitors. Other browsers like Opera represented a thin but stagnant slice, as Opera usage globally has held consistently around 2% for the last 8 years, and historically about 1% of users for our website. Providing an acceptable experience for iOS/Android devices was also a goal, while keeping in mind that we will be releasing a bona fide mobile site to target these devices in the coming months. This group of users represented less than 1%, but is a more important 1% to us than those using archaic browsers.
Controlling The Experience
Goal: Provide accessibility to majority of users, and set expectations otherwise.
FIG. 2 - <noscript> message to those with JS disabled.
Notice that our goal here was not to be 100% backward compatible or fault-tolerant. In fact, graceful degradation for JS driven elements wasn’t even a goal! (Keep reading before you get all huffy.) Our site does not have to support IE6, and it does not have to function the same with JS disabled as it does when it’s enabled. And unless your user base forces such compliance, it’s OK to say so. (If you think that’s out of bounds, try Gmail with your JS disabled.)
It was once common to load up a website and see “this site is best viewed in xxxxxx.” Those days are over. (Well, at least the days of being that conspicuous about it are over!) When you show your users a <noscript> message, what you’re doing is taking a back-door approach to a similar end. The fact is, we don’t want you viewing our website without JS; you won’t get the experience we intend for you to have. We want to provide experience X, and know that the user needs Y to have that experience. In the case of the new paramore.is, Y was JS enabled on a modern browser. We don’t think that’s too much to ask, so we show the user a message right up front, implying that they’re not going to have the experience we want them to have with their current settings.
By showing this message, we are forcing the user to either have JS enabled and get the experience we want them to have, or leave it disabled with the understanding this isn’t what we intended. It was either this route, or downgrading the UX for some folks. Sorry, but our Peeps page just wouldn’t be the same without the JS touches! We chose to make the experience great for the 97%.
Goal: Provide a consistent experience across supported browsers.
Given the browser set we aimed to support, there were some things we needed to do in order for certain elements to display consistently. Remember that our analytics showed the largest majority of users were using browsers that provide at least some support for CSS3. This meant that we were able to use CSS3 selectors and attributes, prepending the -webkit- or -moz- where necessary. For IE versions, we used the PIE HTC behavior to get the same rendering as the browsers that had native support for such selectors.
There’s a sort of cost/value proposition to be considered when determining how certain elements can/should be displayed across your supported browser set. For example, the 10 Year homepage masthead feature uses the webkit & mozilla rotate property, that isn’t [yet] part of the CSS3 spec. The IE alternative is a filter that allows rotation of elements. (Here’s a great article on this topic from Jonathan Snook) While these IE filters worked as intended, it didn’t support the particular rotation of 110 degrees that we needed to maintain the integrity of the layout. For this feature on IE, we used images. No, that’s not as cool as making the lines in CSS, but the “compromise” was worth consistent rendering across our supported browser set.
Plugins
Goal: Get the biggest bang for the bandwidth buck.
As a general rule, we do not like to flood our sites with third-party plugins. If what we want to accomplish can be done more efficiently without employing a heavy plugin that is going to increase load time, then we typically opt to write it from scratch on top of a core library. However, there are a few third-party plugins we used on this site that positively affected the UX.
jQuery
jQuery has been our library of choice for some time now. The Peeps masthead feature AJAX load, homepage callouts horizontal scroll, main nav animation, icon hover animation, form validation and blog topics animation are a handful of examples where we employed jQuery. Additionally, we used plugins like cufón, UI, scrollTo, easing and carousel that are extensions of the core jQuery library.
Fonts
cufón was used to display Chunk, Interstate and some of our Avant-Garde fonts. We’ve received a good bit of questioning about our choosing this route over TypeKit or @font-face. The fact is, we did explore and prefer both alternatives, but after running tests, the rendering for the varying sizes we needed just wasn’t as good as cufón. The exceptions to the use of cufón are the grey subtitles/ breadcrumbs used throughout the site, and the position titles on the Peeps listing page.
Optimization
Goal: Reduce dry load time of any page to 3 seconds or less.
FIG. 3 - Firebug NET stats to measure performance.
Site speed is always important to us, and this goal can definitely have a rubber ruler at times. Our goal was a three-second load time for most folks at home or in the office with a “standard” high-speed connection.
There are a number of things we did to improve performance for paramore.is to meet this goal. A “dry” load is one where no cache has been established for the user, so that everything they need for the page to display is being downloaded on load. The most burdensome of these downloads is usually image, JS and CSS resources. By implementing the items below, we were able to reduce a dry load of any page on the site to 3 seconds or less (slightly more for the homepage), with many loading in a matter of milliseconds once a user’s cache was established. This may seem like a long time, but this time is to get to the “ready” state for the site (once all assets are loaded.)
One exception to these times is the Social Animals page, which loads a handful of external resources that more than quadrupled the load time. The core of the page loaded as quickly as any of the others, while these external resources were loaded in progressively. This makes the page seem to load more quickly than it actually does. While it may not reach its “ready” state for about 7 seconds, the page is loaded and “available” in a second or two.
CSS & JavaScript Assets
For the last year, we have implemented the AutoMin EE plugin written by our own Jesse Bunch. This plugin will take a group of asset tags (e.g. <script> or <link> tags) and generate one consolidated file containing the contents of each file it is passed. These contents are then “minified” and cached for snappy delivery. For JS, this gave us a 36% reduction in size and a 36% reduction in load time. For CSS, we were able to save 33% in size and 71% reduction in load time!
Caching
We utilized EE’s native caching features for queries and page templates. Template caching will basically store the composited rendering of a page as a flat file for quick delivery, instead of having to generate the rendering for each request.
Other
There were some other things that we did to tweak site speed along the way: properly setting expire headers, using gzip, &c. For more details about server-side optimization, checkout Jesse Bunch’s blog post on the topic.
Administration
Goal: Provide administration for as much content as possible.
FIG. 4 - Custom Callout module administration with draggable preview.
As a principle, we try to make it easy to edit any piece of content on a website. There are few instances where content should not be administrable. Such instances would include content that is static, or content that would somehow break the layout if altered. One such example is the CMT Story, where content for callout pieces should fit within specified constraints.
We used our go-to CMS, ExpressionEngine for this build. One of the core strengths of EE is its extensibility, whether you’re developing custom plugins, modules or extensions on top of the CI Framework, or using those already available in the community. We did both. This allowed us to shape the administrative experience around the content, and not the other way around.
One particular instance is the administration of the “Callout” pieces on the homepage, that features entries from our Think section. While the design of this piece looks very organic, there is actually a good bit of logic that goes into its display. Not only that, but the content of each piece must fit within certain constraints so that the presentation is preserved. To meet these requirements, we developed a module that allowed an admin to see the rendering of this piece before it was taken live. The admin could control the title, preview content, images, whether the author & date should be shown, &c. As config options were changed, the widget (that you could drag around anywhere on the page) would update immediately so that you could see your changes.
Whatcha Think?
Please let us know your thoughts. If you think we’re right or wrong, we’d love to hear about it.
Share Article
0 comments