In looking at sustainability frameworks in physical design areas like industrial design and architecture, one thing has impressed me: Despite a “systems theory” approach, quantitative calculations of exact energy and resource use by products is rare. Instead, one keeps a scorecard of added “green ingredients”.
The reason is pretty easy to see. Any product created by a designer is in a larger system. Calculating the energy and resource impact of every part of the larger system throughout the product’s life cycle, like is done in Life Cycle Analysis (LCA, as well as derived methods like Cradle To Cradle) , is very difficult to get right. There are comprehensive LCA tools out there for physical design, but they are hard to use, and can be very expensive. .
An online tool like eiolca.net (http://www.eiolca.net/) lets you analyze the energy and carbon impacts of using Internet Service Provider (ISP) services by the money you pay – but it doesn’t help the virtual side. There are companies like LinkCycle (http://www.linkcycle.com) that can do LCA analysis for small business. This will help you compute your Green Office, but not your Green Code.
The other problem with LCA analysis is that it is a static snapshot. If your industry is changing quickly (and the web certainly is), it is difficult to get all the inputs and outputs in the model right. In the worst case, you do a lot of analysis and get an inaccurate model, because those inputs and outputs have changed.
So, sustainability frameworks frequently invoke a “green ingredient” model. This is a process rather than a snapshot. Instead of trying to calculating an absolute “green-ness”, we try to improve our current system. We record the progress to a greener goal. We measure progress by “swapping” in green ingredients for the current ingredients going into our product.
In this, we first look at the big sustainability goals identified for our area. This might include reducing toxic elements of a product, or improving its carbon footprint. After the goals are defined, components used to create the product are sorted by their green-ness. For example, in designing a new shampoo, one might look at one of the many databases defining the eco-friendliness of particular chemicals. The current product is then defined in terms of its ingredients.
In the next step, the designer tries to “swap out” less green ingredients, replacing them with more green ingredients.
In the final step, at the end of iterating the product prototype, the shift in green-ness of the product is tabulated. Since it is very hard to estimate the real value, often adding a green ingredient adds a “1” to the green-ness of the product. Taking one out subtracts “1”.
Further adjustment is possible after this basic “swap in green virtual ingredients” strategy is employed. We might adjust the impact of some ingredients based on their site-wide effects, compared to other green virtual ingredients that only affect a single web page. We might adjust based on site traffic, or the “global” versus “local” audience for a website.
We might also define cross-interactions. Two green virtual ingredients might combine to create a less efficient website. My guess is that the amount of “crosstalk” in virtual ingredients is less than those in the physical world, like medications or cleaning solvent chemicals.
What would constitute a “green ingredient” for a website? Well, for each aspect of development we can define an ingredient list. In an earlier post, I divided up the areas that a web design firm might explore to become more sustainable – some like other design, others unique to virtual cyberspace.
For the latter, here are some ideas for green ingredients. The list is not meant to be exhaustive; instead it is a start at a big ingredient list. I’ve listed some high-level sustainability goals that might be satisfied by the green ingredient.
Using a list like this would allow simple scoring of a website’s sustainability, as well as marking progress in making a site more sustainable. With time, the scoring might be tied closer and closer to actual energy/resource numbers.
- CSS optimize – effect at code efficiency and size level
- CSS strategy for organizing and ordering styles – effect at design team level
- CSS and JS minify – effect at download size level
- Concatenate CSS and JS files into one larger download – efficiency, fewer HTTP requests
- Maximize parallel downloading of CSS, JS, image and media assets – faster, so users complete tasks more efficiently
- HTML DOM simplification – reduces rendering cost
- Avoid vendor prefixes – long-term sustainability is improved by web standards
- HTML and CSS standards – avoid “quirksmode” (vendor prefixes are part of this)
- ARIA/role attributes for screen readers – more diverse audience supported by site
Green host (IT and webhost)
- Web server optimize (e.g. .htaccess directives) – speed up downloads, cache static content
- Static content domain – speed up download of non-changing media that may be cached permanently
- Host sources power from renewables
- High-efficiency servers
- CDN – reduces downloads, content may be more local to its audience (fewer “hops” through the Internet)
- Create gradients, patterns in CSS instead of downloading bitmaps (smaller number of HTTP requests and bytes transferred)
- Use PNG instead of JPEG (less energy needed to render bitmap)
- Mobile first design strategy – Keeps the interface simple, fewer elements to download/render, user able to focus on a few tasks and complete them quickly, “nudges” users to use low-energy mobile computers
- Progressive enhancement strategy – Keeps the interface simple, pushes rendering to the more-efficient server-side, makes sites accessible by default to the “browser-challenged”
- Responsive design strategy – Supports a diversity of use contexts, adapting to those contexts, allowing faster and more efficient use of site
- Accessibility – fits high-level goal of increasing diversity of audience
- Design for browsers that have lower energy consumption (IE9/10 instead of Chrome?)
- Avoid metaphorical “tailfins” interface – the web page should not try to look like a physical object
- Typographic interface – combine text (message) with art for an efficient, small-footprint interface
- Design in code (no intermediate graphic UI tools) – only one round of design, rather than two.
- Don’t burn code from graphic UI tools like Catalyst, InDesign
- Find plug-ins that “burn” efficient output files from Illustrator (e.g. SVG instead of JPEG)
- Use easily understood symbols (no “mystery meat”) in your interface – users understand, faster completion of tasks
- Favor iconic, simple designs versus complex, shaded, photographic
- Lower use of rich media (movies, animation) – it should be content, rather than presentaton
Green Paths (SEO or Search Engine Optimization)
- Add meta-tags to head region describing site
- Add alt and title tags onto cryptic images and links
- SEO information matches site function
- Effective keyword strategy (for sites that buy keywords)
- Use “hybrid” designer/programmers throughout the design process
- Avoid “siloed” job descriptions
- Allow feedback from below (coder) to impact above (designer)
- Use rapid prototyping
Green Community (teams and the larger web professional community)
- Giving back to the web community by communicating
http://movethewebforward.org/ (but optimize your website more than this one!)
After developing lists of green virtual ingredients, the next step is to develop databases. IMHO web developers should be able to create very sophisticated databases compared to those currently used in sustainability. Compared to the physical world, we can easily attach “reporter” code to analyze how a change in code affects the design. These tools are already in widespread use in Web Performance Optimization (WPO) and Search Engine Optimization (SEO). Results from websites could “feed back” into a central ingredients database, similar to Google Analytics or related “reporters”. We could see if specific green ingredients were useful, as well as identify cases of “crosstalk” between components amplifying or lowering sustainability.
My favorite idea thus far: Use an “object store” database like NoSQL MongoDB (no remapping of program objects to RDBMs tables), and hook it to Node.js. Create tools to scan websites for “green ingredients” in place, or suggest swapping points. Run the combined DB on the client-side, so designers can “fork” their own ingredient database, and/or consult central ones.
Unlike many of the ingredient databases found in physical design, there’s a good chance that this can all be done in open source and be free for basic services. For example, most of the databases listed here cost lots of money to use:
Figuring out which design and programming elements can also be done in the open, via Wiki and similar interactions.