Amulets and Tailfins vs Pistons – Part I of the design sustainability of reveal, vs conceal


With my rant on the unsustainable concepts behind the marketing of Adobe Muse last year attracting some attention, I thought it was appropriate to provide my vision of the more sustainable alternative.

If Muse is bad, is there something better than hardcore editing of code in a text editor? Yes, and in fact, in a future post, I’ll consider the nasty unsustainability engendered by some “coder” tools. This post is about design tools, and how they conceal/reveal code to the detriment of sustainability.

According to sustainability principles, we want to find development methods that work best over the long run and for the greatest number, including that large segment of web designers who do some code, but are not dedicated front-end or back-end developers.

By leaving the code partly revealed in our design process, we extend sustainability thinking about the web as a machine (engineering layer) up into the design workflow. Without it, we will tend to design as if websites were “weightless,” or automatically “greener” than print or other media.  Incorporating some development into the design level also meets the goal of inclusiveness – it “gets” the “long tail” of freelance designers and smaller design shops with do some code into sustainable design.

Muse marketing, and similar promises of “one button” website creation, are part of a larger pattern of what I call “amulet design.”  Amulet design theory (which is the current reigning practice in computer hardware design) tries to hide the complexity of the system from the end-user, which is invited instead to think of their tech-toy as a magic amulet with magical powers.

At the design level, web authoring tools which hide the machinery of the web encourage magical thinking in designers, who then proceed to create less sustainable websites. It also creates a class structure with “higher” designers or creatives using these, and “lower” developers slaving away to fix the inefficient code which pours out.

In contrast, if we can open the hood as a designer (or the hood is opened for us as necessary during our design workflow) we flatten hierarchy, increase designer-developer communication, and get engineering, WPO, and SEO downstream insights feeding back into the design process.

In the latter case, we are lucky there are lots of promising “accelerator” tools which de-amulet web design without requiring you work in the basement with Morlock-like “codebeasts”. These tools conceal code when appropriate, and expose it to the design layer as necessary.

I was motivated to do this post after looking at a new “conceal/reveal” tool for CSS, DiagnostiCSS.

DiagnostiCSS – http://diagnosticss.github.io/

What this site does is show where your CSS code is  inefficient. To make it work , you just drag from the home page to the bookmarks toolbar on your browser – pretty easy. It doesn’t try to write CSS, or hide the CSS – instead, it flags problems in the CSS that a computer can’t really solve, and forwards it up into the design layer so a human with modest CSS skills can take care of it.

Why is this tool interesting from the Sustainable Virtual Design perspective?  As I said, it reveals, instead of conceals. You are mostly in the design layer, but the tool identifies where the underlying code has problems that a machine can’t automatically fix. CSS as a language allows for great clumsy code, and it is easy for a visual design tool to crank out reams of crappy CSS. A tool like this will reveal the “feet of clay” most “visual” web design tools have, as well as de-amulet-izing the design process for a website. Tools that completely hide code have to be doing the equivalent of “autocorrect” all the time.

HTML translators have to be doing this constantly..

Imagine those kind of mistakes in the equivalent of a translator or autocorrector embedded in a “code free” design tool’s guts. There are probably thousands of code gaffes like this in a typical web page created in a “conceal” tool.

Now, some might say it is the responsibility of engineers to make code efficient. IMHO, this is a great example of what makes for unsustainable design. Each design decisions by a designer automatically implies code that has to be written. Even if one hides from the code, the code was created in any case. And if that code is clumsy, it is typically because the designer, unaware of the way the web works, designed something that forces inefficient code out of the translator program.

This problem occurs in any design where there is a “machine” – Industrial Design, Interior Design, and Architecture all have a similar problem. You can make up any product or building you want on the computer, but you implicitly specify its green-ness, even if you don’t care about the underlying building materials or virtual parts needed for your “creative” work.

All human-computer communication requires a metaphor, since all a computer can do is shuffle symbols around according to abstract rules. Tools and design/develop environments just build an interface in which to shuffle those symbols. From that perspective, so-called “code” is just a text-based metaphor. Text is not more “basic”  than a visual – just different, and differently useful. If I am changing the size of an object in a drawing, a visual interface that lets me “drag” the size is best. But if I’m designing a website, with it complex understory of HTML, CSS, WPO, SEO, Usability, Accessibility, Interaction Design, User Experience….well, it is pretty much impossible to convert that to a visual metaphor.

The conflict over code versus visual tools is one of conceal/reveal. Everything you do on a computer “codes” it, you can just do it in a way that is consistent with your design goals. Your choice is to conceal it behind an “amulet” interface, or to reveal it in a way which can effectively “feed back” on design. Tools which conceal, rather than reveal, always give your design “tailfins.”

As an example, think of how 1950s style car tailfins metaphorically imply a car is something that it is not. In fact, you could make a case that this kind of design doesn’t provide an “affordance” (meaning it doesn’t help you understand the function of the car), and actually lead designers to create big inefficient gas-guzzlers.

1950s caddy viewed from rear showing tailfins and tail lights designed to look like wings and a jet engine
Trying to be something it is not

Contrast the 1950s Studebaker – a car designed as a car. Earlier Studebakers had “Dagmars,”  and the grille tried to look like part of a 1940s torpedo or plane motor. But this design, (despite some tailfin) is design of a car as a car. It doesn’t try to conceal what it really is.

Studebaker Silver Hawk from the 1950s, viewed from the front
Studebaker Silver Hawk

Contrast Victorian Train Engine design – the mechanism is deliberately revealed, and not made into an “amulet.”

Small steam locomotive, viewed from front, showing its working mechanism.
Doesn’t try to hide how it works

Even when trains got faster, they didn’t try to hide the fact that they were engines with parts that required energy to move – streamlining was part of the functional product, improving energy efficiency.

1930s train engine with dreamline design
Dutchess of Hamilton

Certain things are hidden on these designs, e.g. stuff that would slow down the train via wind resistance. The functional covering is an escutcheon rather than a fully-concealing system.

Now look at our current “amulet” fetish in computer tech.  The computer is implied to be something almost spiritual, like a piece of magic jewelry.

iphone 5 as a magic amulet giving not clue to its place in the ecosystem
Magic Amulet, giving no clue to its place in the Internet Ecosystem

In fact, the computer is still a dirty machine underneath. We conceal the dirt, and in its hidden space beneath the amulet’s shell, and as a consequence, even more dirt accumulates. Design tools that try to hide “dirt” of the the underlying web code make it dirtier, with consequences for sustainability.

Amulet design, and the design thinking it inspires, goes beyond Skewomorphism – it claims it is something it is not, instead of just hinting at an “affordance” or function, which is what good Skewmorphic design does.

If you don’t know how a medium works,  you’re liable to create media that are less sustainable. So, if you conceal, like Muse does, you’re forced the “creatives” to design in the dark as to the consequences of their work. The back-end translator software can’t make good enough choices to engineer truly sustainable design. Good translator software will alert the designer, as DiagnostiCSS  does, when a change in thinking is required to make a design more sustainable.

DiagnostiCSS is an important program. It points to the future of design tools that help use create easily and naturally, while not trying to “amulet” or “tailfin” what we are doing, as designers.

This is a boon for sustainable design. Keeping understanding of the system alive at the highest and earliest levels of design will ensure that sustainable thinking isn’t an WPO afterthought, but informs the whole of the design workflow.

But we haven’t considered the other side of sustainability – coders who work exclusively in code, with minimal tools. In my opinion, these guys are even worse for Sustainable Virtual Design.

And if some design tools are are bad, coding tools are REALLY MESSING THE WEB UP.

In my next post, I’ll consider why leaving out design in programming leads to unsustainability, and consider what a User Experience expert would think when confronted with today’s popular programming languages.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s