Green “Boilerplate Part I – Sustainable web design templates

As described in the previous post, is online over at

At present, it is just a placeholder while I work out some principles that a ‘sustainable’ boilerplate might have, and how it would differ from something like The following summarizes some preliminary thoughts on the topic.


A Sustainable Virtual Design Boilerplate, a.k.a. a Green Boilerplate should have as its goals:

  1. Sustainable development and maintenance of code & assets
  2. Optimized delivery of page data (minimum bits transferred)
  3. Efficient rendering on most computers (avoid energy-wasting CPU grinding)
  4. Efficient UX (reduced energy/resource use by the sites’s audience, fast, repeatable, non-frustrating task completion)

Basic Structure

As I see it, Sustainable Virtual Design boilerplates need to combine features of two other popular design “best practices”, plus some of a third:

  1. Responsive Web Design (Ethan Marcotte,
  2. Progressive Enhancement (Steven Champeon and Nick Finck,
  3. Mobile First (implied,Luke Wroblewski,

Responsive design tries to adjust for a variety of computers, screen resolutions and sizes – but there’s no mention of efficiency. The resulting boilerplate is ready for anything, and quickly adapts to present an optimum experience on the particular device. Multiple layouts are implied, for example an iPad tablet display might use a two-column “question answer” design pattern, while the same page might be rendered in three columns on a larger desktop screen. Making this work requires a mix of CSS Media Queries and JavaScript “polyfill” libraries. The boilerplate may start simple, but doesn’t have to – many are full-featured with every possible combination of stylesheets and polyfills.

Another feature of these boilerplates is that everything happens on the client side with JavaScript and CSS – there’s no server-side component.

Alas, there’s no description of how many devices we have to support – Responsive Design wants us to support multiple devices, but there’s no hard criteria for accepting/rejecting a particular device. Most template are there to support smartphones and tablets – they are often vague on what to do about old systems, featurephones, or large-formate devices like flatscreen TVs. The reason? Too many media queries and/or polyfills.

In contrast, the older Progressive Enhancement pattern asks us to look back in time, design for old simple browsers, then slowly add extra features in an almost evolutionary process. The equivalent of Responsive Design exists here, though it was called “device detection” in the early 2000s when Progressive Enhancement was first discussed.

Under Progressive Enhancement, the most “browser-challenged” user will still get information. Stuff will work everywhere, but all you know is that the information will be available. Typically, older, small-screened, or slow web displays will create a “barebones” design that might be harder to use than the animated, nudge-filled display on a desktop. In contrast to recent work, the typical Progressive Enhancement shifts the load to the server-side for simple rendering devices.

Thus, a Progressive Enhancement boilerplate might use JavaScript/Ajax to update pages on recent desktop browsers – but shift to PHP writing custom static pages for a old featurephone that may have JavaScript turned off.

The problem with Progressive enhancement is that, while it does consider client and server-side computing, it only does it in the context of client capability. So, a Progressive Enhancement template might overload the server to support the base level of computing, or the client to support high-end interfaces. There’s no gurarantee that we will minimize the amount of data exchanged between client and server, or the the total CPU cycles used to generate a page.

The Mobile First pattern is implied here, mostly because today’s featurephones are a bit like a 1990 Win 2 computer, and today’s smartphones are similar to 1990s desktops in their capabilities. So, going back in evolutionary time is like going mobile. This breaks down partly today because mobiles have good HTML5 support, while desktops are often deficient – the mobile is not a simple version of the desktop, which is how they were treated in the past.

Unique features of Sustainable Web Design / Sustainable Virtual Design

Sustainable Virtual Design requires that we download the minimum number of bytes, and render with minimum CPU cycles on the client and server alike.

So, the unique feature of the Green Boilerplate is an emphasis on bootstrapping to minimize downloads. Features like maximum cross-browser compatibility, or cutting-edge rendering are secondary, though possible.

For the best bootstrapping, the boilerplate should use both client and server-side programming, picking one over the other on the basis of efficiency and download.

The sequence

In Green Boilerplate, when the request is received, an initial server-side “bootstrapping” downloads what is required at a minimum.  Once the page is being assembled on the client side, additional bootstraps may fire to complete the page. Once again, the additional downloads are themselves bootstrapped. Each bootstrap has a different criteria – ranging from byte counts to semantic information.

Bootstraps act to “dress up” the page. Some if not most, happens on the server to avoid downloading big default libraries (e.g. JQuery with a bunch of plugins) or long “fix” stylesheets intended for obsolete browsers. This also minimizes HTTP requests.

The second level of “dress up” happens on the client. The client may have better knowledge of its local rendering environment, so “trumps” the server in these cases.

To avoid unsightly “flashing” of the web page as it is updated and maintain UX, the Sustainable Design boilerplate should create a visual enhancement which lets the user know what’s going on to some extent, and minimize user disruption. A page that slowly fades in – something like an interlaced GIF – is appropriate.

Like Responsive Design, the page should adapt – but the adaptation will be more extreme. As we’ll see below, the template adapts to time, history and network conditions, as well as the end-user’s computer configuration.

Like Progressive Enhancement, the page ‘evolves’ as it goes through the process of download and rendering. The page starts simple and is “dressed up” to the extent that is possible for the system without blowing up byte transfers or rendering complexity.

A client-server mix of bootstraps

What fixes the amount of client versus server-side enhancement? Overall CPU cycles, and their carbon footprint, which are either computed in advance, or dynamically calculated. In many cases we may prefer CPU cycles on the server, but once again, other considerations might shift it to the client. Consider the following:

  • Servers these days are optimized for “green” compared to desktops, so we may want to use server-side for at least some of the required CPU cycles.
  • Building the whole page on the server would result in more bytes being downloaded (the extreme being a bitmap of the rendered page), so even if the server is efficient, we may want to shift to the client-side.
  •  The client-side may have better tools for detecting browser and device capabilities. This implies that more efficient bootstrapping might happen on the client.
  • On the client-side, many rendering operations may be preformed at the markup level in HTML and CSS. Since this is happening in native browser code, it is likely to be more efficient than an equivalent server-side interpreted languages like PHP – there is no equivalent of markup driving native code on the server.

When to stay static

In some cases, the designer, creating a site at a particular time and place will already know that certain browsers or systems are unlikely to ever visit their site. For example, a corporate intranet may be unlikely to have Google Chrome as the default browsers due to corporate policy standardized on IE8. In these cases, Sustainable Virtual Design should put in a hard “cutoff” after which we don’t run bootstrap code, but just go with a static default. The chance that we will be wrong should be low.

This implies that any boilerplate will need micro-configuration to be useful, with the default mostly dynamic, and the final templates mostly static. Boilerplate will need to be compiled with a lot of conditions in mind, with static-ified versions preferred if possible.

A great example of this principle in current development may be found in shopping carts. Running the cart and generating catalog pages is generally an intense, dynamic process requiring lots of database and rendering code. To reduce server load, many carts allow the pre-generation of static catalog pages. When a page is changed, a new page is generated when there’s time.

Biomimicry and the concept of precomputed “lifetimes”

Sustainable design in other fields often applies concepts derived from studies of nature, collectively referred to as Biomimicry. This doesn’t imply that “Nature always has the best solution”, but sometimes it does. In addition, natural systems are often understood by all “stakeholders” in a interactive/web design project, as compared to code, which is only understood by the developers.

Therefore, the Biomimicry description may be highly appropriate for developing a sustainable template.

The key concept from Biomimicry we take for Green Boilerplate is a concept of “species” and “lifetimes”.  Each block of code or media can be imagined as having a “life cycle”. Individuals in a species come into being, then exit the stage upon death, in a manner similar to objects created with the “new” operator and destroyed when the program terminates. At a higher level, species come into being, then go extinct after a certain amount of time.

In some cases the “death” of a particular module, polyfill, or element may be unknown, and we will need dynamic checking to minimize its use. But in other cases, we can make a very good estimate of when an element or polyfill goes obsolete, and provide code that “wipes” it from the boilerplate, even if it is not re-uploaded. This is a key feature of the Green Boilerplate – adaptation and reconfiguration over time.

The equivalent of a “world car”

In the real world, machines like a Prius are assembled via a globalized manufacturing process – parts are created in one country, assembled in another, then shipped to a third for final work and sales. This process, along with the energy and resources used, make may devices less “green” than one might think. In the case of the Prius, more than one study has shown that the “embodied energy” of the car’s globalized manufacture outweighs fuel savings, unless you keep the car for man years. I look at a website, with it hosts, networks, different parties contributing code and assets, as a “virtual globalized” system. This analogy, like Biomimicry, may help to guide design decisions in the template.

Template with a timer

In a Sustainable Virtual Design template, our dynamic bootstraps are uniquely sensitive to time. Each time code tries to determine whether to add a polyfill, it checks the calendar. After certain dates, some bootstraps may be dropped. Other bootstraps may be faded in. Thus the template becomes sustainable by adapting to the past AND THE FUTURE. Obviously, we’ll need a mechanism to load upgrades into the bootstrapper as they become available. This might be something in the build on the developers computer, or (more interestingly) part of the uploaded boilerplate itself.

Doomed for extinction

In the real world, an “endangered species” is something we worry about, and we try to bring its population numbers up. In the virtual world, “endangered species” are old browsers or pages that use obsolete code. By looking at Internet traffic, we can determine a “timeline” – a curve for adoption or non-adoption. A good example would be various versions of Internet Explorer, for which use curves are well-known. Using these curves, we can confidently predict when IE8, for example, falls below the 1% market penetration which justifys excluding it from consideration.

In fact, the Green Boilerplate should have its own timer! Based on research, we can predict when the current features of web markup and programming will have changed so much that the core templates are no longer valid. Green Boilerplate should detect this, and destroy itself, possibly providing reports as its age advances. A possible target for the boilerplate itself might be 20 years from now – in 2032.

This isn’t just life emulation – we are just being honest about how people work. Most designers and developers are likely to set up a template, which they don’t constantly update, and they don’t go back to old clients to update them. To the extent possible in code, we can increase sustainability if we have the code check for its own upgrades, or gracefully bow out if they’re not needed anymore.

A way to mutate

Instead of letting a template go extinct, we can extend its life by “evolving” it to the new conditions. The development side of a Green Boilerplate therefore needs a way to add in upgrades, AND define their lifetime. New builds can “reset” the lifetime of particular elements, past and future.

“Quirks” are OK for virtual living fossils

Old browsers have one feature that is missing from new ones – they are reliable. No, not in their rendering, but in their behavior. They aren’t being upgraded anymore, so we can be confident that they aren’t changing. Methods to detect them and fix them won’t change either, and “brittle” hacks should continue to work.

For this reason, quirky or ad hoc detection methods – even the dreaded HTTP_USER_AGENT may be acceptable in these cases. The quirky methods may be faster, more efficient, run on the server – all which gives us greater flexibility in our design and programming. Without mutation, they will slowly die out over time, leaving modern code.

In the next section we’ll consider some other desirable features in the template, and also look at sustainability in the development cycle and User Experience.

1 Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.