Designers on the web are experiencing a bit of a revolution that is summed up in a few words: measure everything.  Led by the likes of Google, every click, every eyeball movement is tracked to see what the user does next, all in an attempt to answer the question: what works best?

Design no longer is the purview of instinct and feeling; it has become more analytical.  My characterization here is crude and not wholly correct.  There are shades of gray, as instinct has its place and measurement can’t tell us everything.  Since I am not a designer, I’m not enmeshed in the design world and can’t speak to everything that happens.  I only follow along from the outside as a curious and interested spectator.

I don’t think most designers would argue that design has become more and more about measurements, conversions, and click through rates.  And this isn’t necessarily a bad thing.

However, all this focus has fallen in the visual design and user interaction arena.  One place that still gets neglected is that of copy design.  For those of you not aware, copy is the term used to refer to the written part of a website or a magazine, as opposed to the images and layout.

The web is more words than images, although Flickr and YouTube are doing their best to change that.  Day in and day out, you get around the web by reading.  It stands to reason that what the web says is as important as to how it looks.

Typography gets a lot of attention and for good reason, as fonts matter.  A font can catch your eye or set the mood.  Often fonts are compared using the pangram “The quick brown fox jumps over the lazy dog”.  This is great for evaluating the font, but if a font isn’t used to say anything, what use is a font?

Shouldn’t copy – what a website says – be given as much attention as how it looks?  Changing copy can quickly fix problems that otherwise would be difficult to deal with, as Joshua Porter shows.  Copy can affect conversion rates.  Dustin Curtis tweaked the words that pointed to his Twitter account and saw a measurable difference in click though rate: a 173% difference.

The design world already knows the work of Edward Tufte.  It should also know the work of his wife mother, Virginia Tufte. She wrote the book Artful Sentences: Syntax as Style.  It’s a book that does nothing except examine sentences.  The fact that this can be done speaks to the richness of language and suggests that we all should pay more attention to it.

So I ask: where are the copy designers?  I expect that over the next few years we’ll see them appear.  If they don’t appear explicitly, current designers will add copy design to their repertoire.

Words matter just as much as looks.  How much opportunity is your site passing over just because your copy lacks power or style?

Two sentences highlighted by Viginia Tufte in Artful Sentences: Syntax as Style:

I feel – and the anxiety is still vivid to me – that I might easily have failed before I began.
- V.S. Naipaul, Literary Occasions, 195

The desire to move on, to metamorphose – or perhaps it is a talent for being contemporary – was given to me as life’s inevitable and rightful condition.  To keep becoming, always to stay involved in transition.  It was all she and my father had ever known.
- Arthur Miller, Timebends: A Life, 4

Thanks goes to Jason Rudolph for the conversation that sparked this post.

Where Are The Copy Designers?

Looking back, I don’t remember all the points Nathan highlighted, however, at the time the ones that most struck me I wrote down in my moleskine.

One of the points was that of the smallest effective difference.  This is where elements are separated by the smallest distinction possible, so that they are distinct and easy to follow, but so that the eye isn’t overwhelmed by the divider.  An example of this would be having a thin gray line dividing boxes, as opposed to a thick black bar.  This principle stuck out to me because I realized it often shows up in calendar grids.  Google calendar uses this to great effect.  Each block is marked with a thin blue line in Google calendar.  This also has the side effect of maximizing space.

The other principle that struck me from Nathan’s talk is that content influences design.  Nathan used an example from his own design company to showcase this.  He talked about how as they designed the website for Peace College the Alumnae Affairs department at Peace College the homepage design was designed last and was influenced by the content of the second level pages.  How could they have known what needed to be highlighted on the homepage without knowing the content of the other pages?  The hierarchy of the second level pages also influenced how the layout and navigation of the homepage was to work.

Once it is shown to you, realizing that content influences design seems obvious, yet as most of us go through our lives we continually ignore this fact, leading to suboptimal designs.  What tends to be designed is one size fits all, and while there is a place for systems like that, more often than not they lead to inefficiencies.

The ignorance of content influencing design even shows up in programing.  All to often, we programmers build the scaffolding of our programs first and then later insert the all important content, squishing it into the scaffolding we’ve built.  This leads to logic that is warped to account for the scaffolding, instead of the scaffolding changing to accommodate the logic.

DSLs (domain specific languages) are one way that content influences design in programming.  The content becomes the design of the language.  While it’s still possible to have a badly designed DSL, a DSL is closer to the content than a generic language will be and this should lead to greater efficiencies in design.

Nathan’s points were well taken.  While I’d heard of Tufte, not being a designer myself I’ve never taken the time to read his works.  I’ll need to rectify that, as it’s clear that principles that apply in the design world also have applicability to the world of programming.

Content, Design, and Tufte

You should try browsing the web with Javascript turned off and observe how broken many things are.  If you run your own site, see how it responds.

At the least, if your site can’t function without Javascript, put in a check to see if a visitor has Javascript disabled, and if so, give a warning that functionality is not guaranteed.

I’m running with NoScript installed in Firefox.  It’s pretty eye opening.

Take, for example, TokBox.  If you visit there with NoScript turned on, you’ll be greeted by a blank page.  While NoScript blocks more than just Javascript, it’s still embarrassing that with scripts turned off, an entire site results in a blank page.

Don’t let this happen to your site.  Degrade gracefully.

Surf with Javascript Off

Service Oriented Architecture is only achievable through message passing.

It’s a simple concept that makes sense when it is articulated, but unless you consciously think about it is easy to miss.

Often, when different services are built for an application, they end up sharing the same database.  While this might seem like a good initial idea, ultimately it becomes a single point of failure as well as a bottle neck for the entire system.  The only way to avoid this is to split the application into two entire different systems that communicate through message passing, not through the database layer.

There are other benefits to this approach.  When each service is entirely separate from any other, then no service is bound by the technological decisions made for the others.  The development team is free to explore different technologies and options for each service.  The only requirement is that each service be able to talk to the the others, and protocols like HTTP make this easy, if not entirely trivial.

There is also the benefit that by decoupling services to the point that all that is needed is message passing, more creative ways to leverage the entire system might be found.  Each time a new service is incorporated, the only technical hurdle preventing it from talking to any other service is enabling it to pass the right messages.  This makes for a modular and reusable design at the service level, a further abstraction up from the code and library levels.

The proof that message passing works can been seen in languages such as Erlang.  Erlang nodes only communicate through message passing, not through shared memory, enabling Erlang’s exceptional concurrency handling.  Message passing at the service layer also provides the same benefits that Erlang enjoys at the language layer; redundancy, concurrency, and stability are all made easier by message passing.

The end lesson is this: Service Oriented Architecture is Message Oriented Architecture.

Message Oriented Architecture

I’ve also been following the various discussions and arguments on REST that seem to frequently flair up, although I’m lurking more for knowledge than contributing anything to what is being said.

It seems to me, based on my limited knowledge of REST, that Tim Bray describes a perfectly RESTful Interface when he talks about how he envisions a search API being designed, although he never mentions REST.

Very worth the read, as it provides a concrete example of what a RESTful interface can look like, which I find helpful so that I don’t drown in abstract details and descriptions.

A RESTful Interface

Tesler’s Law is this:

The Law of Conservation of Complexity: Every application must have an inherent amount of irreducible complexity. The only question is who will have to deal with it.

In the interview Bill de hOra links to, Tesler further enumerates on his law:

If a million users each waste a minute a day dealing with complexity that an engineer could have eliminated in a week by making the software a little more complex, you are penalizing the user to make the engineer’s job easier.

Whose time is more important to the success of your business? For mass market software, unless you have a sustainable monopoly position, the customer’s time has to be more important to you than your own.

I agree. I think if we look at some of the most successful applications in history, we’ll find Tesler’s law at work behind their success.

Tesler’s Law