HTTP stands for Hypertext Transfer Protocol. It’s a stateless, application-layer protocol for communicating between distributed systems, and is the foundation of the modern web. As a web developer, we all must have a strong understanding of this protocol.

Let’s review this powerful protocol through the lens of a web developer. We’ll tackle the topic in two parts. In this first entry, we’ll cover the basics and outline the various request and response headers. In the follow-up article, we’ll review specific pieces of HTTP – namely caching, connection handling and authentication.

Although I’ll mention some details related to headers, it’s best to instead consult the RFC (RFC 2616) for in-depth coverage. I will be pointing to specific parts of the RFC throughout the article.

HTTP Basics

HTTP allows for communication between a variety of hosts and clients, and supports a mixture of network configurations.

To make this possible, it assumes very little about a particular system, and does not keep state between different message exchanges.

This makes HTTP a stateless protocol. The communication usually takes place over TCP/IP, but any reliable transport can be used. The default port for TCP/IP is 80, but other ports can also be used.

Custom headers can also be created and sent by the client.

Communication between a host and a client occurs, via a request/response pair. The client initiates an HTTP request message, which is serviced through a HTTP response message in return. We will look at this fundamental message-pair in the next section.

The current version of the protocol is HTTP/1.1, which adds a few extra features to the previous 1.0 version. The most important of these, in my opinion, includes persistent connections, chunked transfer-coding and fine-grained caching headers. We’ll briefly touch upon these features in this article; in-depth coverage will be provided in part two.

URLs

At the heart of web communications is the request message, which are sent via Uniform Resource Locators (URLs). I’m sure you are already familiar with URLs, but for completeness sake, I’ll include it here. URLs have a simple structure that consists of the following components:

The protocol is typically http, but it can also be https for secure communications. The default port is 80, but one can be set explicitly, as illustrated in the above image. The resource path is the local path to the resource on the server.

Verbs

There are also web debugging proxies, like Fiddler on Windows and Charles Proxy for OSX.

URLs reveal the identity of the particular host with which we want to communicate, but the action that should be performed on the host is specified via HTTP verbs. Of course, there are several actions that a client would like the host to perform. HTTP has formalized on a few that capture the essentials that are universally applicable for all kinds of applications.

These request verbs are:

• GET: fetch an existing resource. The URL contains all the necessary information the server needs to locate and return the resource.
• POST: create a new resource. POST requests usually carry a payload that specifies the data for the new resource.
• PUT: update an existing resource. The payload may contain the updated data for the resource.
• DELETE: delete an existing resource.

The above four verbs are the most popular, and most tools and frameworks explicitly expose these request verbs. PUT and DELETE are sometimes considered specialized versions of the POST verb, and they may be packaged as POST requests with the payload containing the exact action: create, update or delete.

There are some lesser used verbs that HTTP also supports:

• HEAD: this is similar to GET, but without the message body. It’s used to retrieve the server headers for a particular resource, generally to check if the resource has changed, via timestamps.
• TRACE: used to retrieve the hops that a request takes to round trip from the server. Each intermediate proxy or gateway would inject its IP or DNS name into the Via header field. This can be used for diagnostic purposes.
• OPTIONS: used to retrieve the server capabilities. On the client-side, it can be used to modify the request based on what the server can support.

Status Codes

With URLs and verbs, the client can initiate requests to the server. In return, the server responds with status codes and message payloads. The status code is important and tells the client how to interpret the server response. The HTTP spec defines certain number ranges for specific types of responses:

1xx: Informational Messages

All HTTP/1.1 clients are required to accept the Transfer-Encoding header.

This class of codes was introduced in HTTP/1.1 and is purely provisional. The server can send a Expect: 100-continue message, telling the client to continue sending the remainder of the request, or ignore if it has already sent it. HTTP/1.0 clients are supposed to ignore this header.

2xx: Successful

This tells the client that the request was successfully processed. The most common code is 200 OK. For a GET request, the server sends the resource in the message body. There are other less frequently used codes:

• 202 Accepted: the request was accepted but may not include the resource in the response. This is useful for async processing on the server side. The server may choose to send information for monitoring.
• 204 No Content: there is no message body in the response.
• 205 Reset Content: indicates to the client to reset its document view.
• 206 Partial Content: indicates that the response only contains partial content. Additional headers indicate the exact range and content expiration information.

3xx: Redirection

404 indicates that the resource is invalid and does not exist on the server.

This requires the client to take additional action. The most common use-case is to jump to a different URL in order to fetch the resource.

• 301 Moved Permanently: the resource is now located at a new URL.
• 303 See Other: the resource is temporarily located at a new URL. The Location response header contains the temporary URL.
• 304 Not Modified: the server has determined that the resource has not changed and the client should use its cached copy. This relies on the fact that the client is sending ETag (Enttity Tag) information that is a hash of the content. The server compares this with its own computed ETag to check for modifications.

4xx: Client Error

These codes are used when the server thinks that the client is at fault, either by requesting an invalid resource or making a bad request. The most popular code in this class is 404 Not Found, which I think everyone will identify with. 404 indicates that the resource is invalid and does not exist on the server. The other codes in this class include:

• 400 Bad Request: the request was malformed.
• 401 Unauthorized: request requires authentication. The client can repeat the request with the Authorization header. If the client already included the Authorization header, then the credentials were wrong.
• 403 Forbidden: server has denied access to the resource.
• 405 Method Not Allowed: invalid HTTP verb used in the request line, or the server does not support that verb.
• 409 Conflict: the server could not complete the request because the client is trying to modify a resource that is newer than the client’s timestamp. Conflicts arise mostly for PUT requests during collaborative edits on a resource.

5xx: Server Error

This class of codes are used to indicate a server failure while processing the request. The most commonly used error code is 500 Internal Server Error. The others in this class are:

• 501 Not Implemented: the server does not yet support the requested functionality.
• 503 Service Unavailable: this could happen if an internal system on the server has failed or the server is overloaded. Typically, the server won’t even respond and the request will timeout.

Request and Response Message Formats

So far, we’ve seen that URLs, verbs and status codes make up the fundamental pieces of an HTTP request/response pair.

Let’s now look at the content of these messages. The HTTP specification states that a request or response message has the following generic structure:

message = <start-line>
              *(<message-header>)
              CRLF
              [<message-body>]
    
    <start-line> = Request-Line | Status-Line 
    <message-header> = Field-Name ':' Field-Value

It’s mandatory to place a new line between the message headers and body. The message can contain one or more headers, of which are broadly classified into:

• general headers: that are applicable for both request and response messages.
• request specific headers.
• response specific headers.
• entity headers.

The message body may contain the complete entity data, or it may be piecemeal if the chunked encoding (Transfer-Encoding: chunked) is used. All HTTP/1.1 clients are required to accept the Transfer-Encoding header.

General Headers

There are a few headers (general headers) that are shared by both request and response messages:

general-header = Cache-Control            
                   | Connection        
                   | Date              
                   | Pragma            
                   | Trailer           
                   | Transfer-Encoding 
                   | Upgrade           
                   | Via               
                   | Warning
    

We have already seen some of these headers, specifically Via and Transfer-Encoding. We will cover Cache-Control and Connection in part two.

The status code is important and tells the client how to interpret the server response.

• Via header is used in a TRACE message and updated by all intermittent proxies and gateways
• Pragma is considered a custom header and may be used to include implementation-specific headers. The most commonly used pragma-directive is Pragma: no-cache, which really is Cache-Control: no-cache under HTTP/1.1. This will be covered in Part 2 of the article.
• The Date header field is used to timestamp the request/response message
• Upgrade is used to switch protocols and allow a smooth transition to a newer protocol.
• Transfer-Encoding is generally used to break the response into smaller parts with the Transfer-Encoding: chunked value. This is a new header in HTTP/1.1 and allows for streaming of response to the client instead of one big payload.

Entity headers

Request and Response messages may also include entity headers to provide meta-information about the the content (aka Message Body or Entity). These headers include:

entity-header  = Allow                    
                   | Content-Encoding  
                   | Content-Language  
                   | Content-Length    
                   | Content-Location  
                   | Content-MD5       
                   | Content-Range     
                   | Content-Type      
                   | Expires           
                   | Last-Modified  
    

All of the Content- prefixed headers provide information about the structure, encoding and size of the message body. Some of these headers need to be present if the entity is part of the message.

The Expires header indicates a timestamp of whent he entity expires. Interestingly, a “never expires” entity is sent with a timestamp of one year into the future. The Last-Modified header indicates the last modification timestamp for the entity.

Custom headers can also be created and sent by the client; they will be treated as entity headers by the HTTP protocol.

This is really an extension mechanism, and some client-server implementations may choose to communicate specifically over these extension headers. Although HTTP supports custom headers, what it really looks for are the request and response headers, which we cover next.

Request Format

The request message has the same generic structure as above, except for the request line which looks like:

Request-Line = Method SP URI SP HTTP-Version CRLF
    Method = "OPTIONS"
           | "HEAD"  
           | "GET"  
           | "POST"  
           | "PUT"  
           | "DELETE"  
           | "TRACE"

SP is the space separator between the tokens. HTTP-Version is specified as “HTTP/1.1″ and then followed by a new line. Thus, a typical request message might look like:

GET /articles/http-basics HTTP/1.1
    Host: www.articles.com
    Connection: keep-alive
    Cache-Control: no-cache
    Pragma: no-cache
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Note the request line followed by many request headers. The Host header is mandatory for HTTP/1.1 clients. GET requests do not have a message body, but POST requests can contain the post data in the body.

The request headers act as modifiers of the request message. The complete list of known request headers is not too long, and is provided below. Unknown headers are treated as entity-header fields.

request-header = Accept                   
                   | Accept-Charset    
                   | Accept-Encoding   
                   | Accept-Language   
                   | Authorization     
                   | Expect            
                   | From              
                   | Host              
                   | If-Match          
                   | If-Modified-Since 
                   | If-None-Match     
                   | If-Range          
                   | If-Unmodified-Since
                   | Max-Forwards       
                   | Proxy-Authorization
                   | Range              
                   | Referer            
                   | TE                 
                   | User-Agent

The Accept prefixed headers indicate the acceptable media-types, languages and character sets on the client. From, Host, Referer and User-Agent identify details about the client that initiated the request. The If- prefixed headers are used to make a request more conditional, and the server returns the resource only if the condition matches. Otherwise, it returns a 304 Not Modified. The condition can be based on a timestamp or an ETag (a hash of the entity).

Response Format

The response format is similar to the request message, except for the status line and headers. The status line has the following structure:

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

• HTTP-Version is sent as HTTP/1.1
• The Status-Code is one of the many statuses discussed earlier.
• The Reason-Phrase is a human-readable version of the status code.

A typical status line for a successful response might look like so:

HTTP/1.1 200 OK

The response headers are also fairly limited, and the full set is given below:

 response-header = Accept-Ranges
                     | Age
                     | ETag              
                     | Location          
                     | Proxy-Authenticate
                     | Retry-After       
                     | Server            
                     | Vary              
                     | WWW-Authenticate

• Age is the time in seconds since the message was generated on the server.
• ETag is the MD5 hash of the entity and used to check for modifications.
• Location is used when sending a redirection and contains the new URL.
• Server identifies the server generating the message.

It’s been a lot of theory upto this point, so I won’t blame you for drowsy eyes. In the next sections, we will get more practical and take a survey of the tools, frameworks and libraries.

Tools to View HTTP Traffic

There are a number of tools available to monitor HTTP communication. Here, we list some of the more popular tools.

Undoubtedly, the Chrome/Webkit inspector is a favorite amongst web developers:

There are also web debugging proxies, like Fiddler on Windows and Charles Proxy for OSX. My colleague, Rey Bango wrote an excellent article on this topic.

For the command line, we have utilities like curl, tcpdump and tshark for monitoring HTTP traffic.

Using HTTP in Web Frameworks and Libraries

Now that we have looked at the request/response messages, it’s time that we learn how libraries and frameworks expose it in the form of an API. We’ll use ExpressJS for Node, Ruby on Rails, and jQuery Ajax as our examples.

ExpressJS

If you are building web servers in NodeJS, chances are high that you’ve considered ExpressJS. ExpressJS was originally inspired by a Ruby Web framework, called Sinatra. As expected, the API is also equally influenced.

Because we are dealing with a server-side framework, there are two primary tasks when dealing with HTTP messages:

• Read URL fragments and request headers.
• Write response headers and body

Understanding HTTP is crucial for having a clean, simple and RESTful interface between two endpoints.

ExpressJS provides a simple API for doing just that. We won’t cover the details of the API. Instead, we will provide links to the detailed documentation on ExpressJS guides. The methods in the API are self-explanatory in most cases. A sampling of the request-related API is below:

• req.body: get the request body.
• req.query: get the query fragment of the URL.
• req.originalUrl
• req.host: reads the Host header field.
• req.accepts: reads the acceptable MIME-types on the client side.
• req.get OR req.header: read any header field passed as argument.

On the way out to the client, ExpressJS provides the following response API:

• res.status: set an explicit status code.
• res.set: set a specific response header.
• res.send: send HTML, JSON or an octet-stream.
• res.sendFile: transfer a file to the client.
• res.render: render an express view template.
• res.redirect: redirect to a different route. Express automatically adds the default redirection code of 302.

Ruby on Rails

The request and response messages are mostly the same, except for the first line and message headers.

In Rails, the ActionController and ActionDispatch modules provide the API for handling request and response messages.

ActionController provides a high level API to read the request URL, render output and redirect to a different end-point. An end-point (aka route) is handled as an action method. Most of the necessary context information inside an action-method is provided via the request, response and params objects.

• params: gives access to the URL parameters and POST data.
• request: contains information about the client, headers and URL.
• response: used to set headers and status codes.
• render: render views by expanding templates.
• redirect_to: redirect to a different action-method or URL.

ActionDispatch provides fine-grained access to the request/response messages, via the ActionDispatch::Request and ActionDispatch::Response classes. It exposes a set of query methods to check the type of request (get?(), post?(), head?(), local?()). Request headers can be directly accessed via the request.headers() method.

On the response side, it provides methods to set cookies(), location=() and status=(). If you feel adventurous, you can also set the body=() and bypass the Rails rendering system.

jQuery Ajax

Because jQuery is primarily a client-side library, its Ajax API provides the opposite of a server-side framework. In other words, it allows you to read response messages and modify request messages. jQuery exposes a simple API via jQuery.ajax(settings):

By passing a settings object with the beforeSend callback, we can modify the request headers. The callback receives the jqXHR (jQuery XMLHttpRequest) object that exposes a method, called setRequestHeader() to set headers.

$.ajax({
        url: 'http://www.articles.com/latest',
        type: 'GET',
        beforeSend: function (jqXHR) {
          jqXHR.setRequestHeader('Accepts-Language', 'en-US,en');
        }
      });
    

• The jqXHR object can also be used to read the response headers with the jqXHR.getResponseHeader().
• If you want to take specific actions for various status codes, you can use the statusCode callback:

$.ajax({
      statusCode: {
        404: function() {
          alert("page not found");
        }
      }
    });
    

Summary

So that sums up our quick tour of the HTTP protocol.

We reviewed URL structure, verbs and status codes: the three pillars of HTTP communication.

The request and response messages are mostly the same, except for the first line and message headers. Finally, we reviewed how you can modify the request and response headers in web frameworks and libraries.

Understanding HTTP is crucial for having a clean, simple, and RESTful interface between two endpoints. On a larger scale, it also helps when designing your network infrastructure and providing a great experience to your end users.

In part two, we’ll review connection handling, authentication and caching! See you then.

References

• HTTP specification
• HTTP Definitive Guide

The team of UMBC computer science professor Yelena Yesha and alumnae Karuna Joshi M.S. ’99, Ph.D. ’12, computer science, and Lily Bengfort ’93, English, has been selected for the NSF Innovation Corps (I-Corps) program for April.

The NSF I-Corps is a set of activities and programs that prepare scientists and engineers to extend their focus beyond the laboratory and broadens the impact of select, NSF-funded, basic-research projects. Combining experience and guidance from established entrepreneurs with a targeted curriculum, I-Corps is a public-private partnership program that teaches grantees to identify valuable product opportunities that can emerge from academic research, and offers entrepreneurship training to student participants.

The UMBC group’s focus is on “cloud based broker services which will allow organizations, like federal agencies, to discover and acquire cloud services that match their data, security and compliance needs,” said Dr. Joshi, who explained the group will also be looking at commercial feasibility. Learn more about the project here.

If we look at email from a signal-to-noise perspective, then one-to-many emails are undeniably in the “noise” category; people are exceedingly good at ignoring them. Even Gmail and Hotmail are helping us ignore them by providing smart inboxes that sort incoming messages.

Emails from our families, friends and coworkers, however, are “signals.” We go out of our way to read them. But those emails aren’t the only ones — on occasion, we’ll happily read messages from businesses or complete strangers. Why? Because these emails are interesting, engaging and, most importantly, full of personality.

We’ve become very selective of what we consume in order to keep from drowning in our overfilled inboxes. Emails from Dad or a lifelong friend take priority, because they’re people we know and trust. Emails from outside our circle? Not so much. Our brains have an upper limit; we don’t have the capability to focus on an unlimited number of things, and our mental ability to care about the things that do interest us wanes over time.

But ultimately, we crave interaction, whether it comes from a trip to an unfamiliar part of the world, from conversations with friends or from the deluge of stories delivered by the 24-hour news cycle. We need to be engaged by ideas and people. It’s built into our psychology.

So, what can we do to make our email more engaging? How can we make sure that people are eager to read it? What gives an email personality? Before we can answer those questions, we have to overcome a couple of problems.

Information Overload

The first problem, as unintuitive as the notion might be, is the inability of humans to multitask. In “The Myth of Multitasking,” Christine Rosen shows that more and more evidence is being found to indicate that our brains simply aren’t wired for it. Despite what many believe, performing several tasks at once (like sitting at a computer and browsing the Web while talking on the phone and taking notes) isn’t multitasking, because we aren’t actually doing all of those things simultaneously.

What we’re actually doing is moving laterally, and switching quickly from task to task. Because of this, we end up in a state of “continuous partial attention,” a term coined by Linda Stone to describe the broadening of our focus from one task to many. Whether or not this sort of divided focus is a bad thing depends on the context; it serves us well at our desks, but take that phone conversation behind the driver’s wheel, and the effect is detrimental.

Our failure to maintain a high level of interest in a subject can be traced to what’s known in psychology as “secondary traumatic stress disorder,” colloquially known as “compassion fatigue” (see the chapter by Charles R. Figley in the “Sources” section below). You’ll find compassion fatigue in just about any caregiving profession — therapists may eventually need therapists of their own, and doctors’ bedside manner might cool over the years. You’ll also find it in customer service, where burnout is common. The growing cynicism over the state of news media is another clear example, as people become wearier of the “always on, always a scoop” environment. To combat that fatigue, news outlets double down on their tactic, and the problem turns into a cycle. So, compassion fatigue is our second problem.

To capture someone’s attention, we have to overcome these issues. For email, it lies in convincing people to take that first look, and then getting them to care enough to hang on for the long term. As people become more exacting of what they allow in, we creators need to become just as discriminating about what we put out.

The Subject Line

Getting people to take that first glance at an email can be difficult. Inboxes all seem filled to the brim, so finding a good hook is important. Writing captivating email content arguably starts in one place: the subject line. There’s no shortage of theories on what tone works best, or which words to avoid, or how long a subject line should be. It’s not an exact science, and a wealth of studies out there prove it. One of the more interesting looks at subject lines comes from the recent re-election campaign of US President Barack Obama.

Back in November, Bloomberg Businessweek published an article by Joshua Green on the short, familiar subject lines used in the Obama 2012 campaign emails. “Would love to meet you,” “Do this for Michelle” and “Hey” are three examples of subjects the campaign used.

Some of them read more like subject lines you’d find in spam than anything from the President’s camp. They’re not much better than what I’m seeing in my own junk folder today: “Let’s hang out!”; “Check this out”; “Hey!” In fact, I recall receiving the “Hey” email from the Obama campaign and immediately marking it as spam. Seriously? The Obama campaign sending an email that opens with “Hey”? Get real. That’s absolutely spam.

As it turns out, I was in the minority.

“Hey” was incredibly popular, and that email raised quite a bit of money for Obama. The single-word subject, incredibly light in tone considering its source, came out of left field and snagged the attention of millions of people. A casual tone for a decidedly non-casual topic worked as a hook and got people to open the email. Green goes on to highlight how the Obama campaign team didn’t stop there — it kept iterating and testing and running with different quirky subject lines, and in turn raised a large portion of its $690 million worth of online donations through emails. But the subject lines always kept that simple slant.

The Content

The success of the Obama for America emails didn’t just come from the subject lines, and the team didn’t reach everyone it targeted on the strength of “Hey” alone. The subject lines were the initial draw, but the content of the emails, written in a familiar and conversational tone that belied their lofty source and that subverted expectations, made them effective. (See “Message Machine: Reverse Engineering the 2012 Campaign” by Jeff Larson and Al Shaw in ProPublica.)

An archetypal example of an email driven by great content is Dave Pell’s NextDraft. Pell crafts each issue of NextDraft daily, with content curated from the day’s most important or interesting news, along with a smattering of related stories. What Pell does with NextDraft is undeniably successful: Today, the newsletter goes to more than 25,000 readers, and every month more than 2,000 new ones sign up. The open- and click-rate numbers for NextDraft remain so consistently high that they put the rest of his industry — media and publishing — to shame; the average open rate for NextDraft hovers around 57%, compared to an industry average that checks in at around 17%. Click rates are similarly impressive at around 30%, versus a industry average of just 4%. By all measures, Pell’s doing it right.

Much of the reason why NextDraft works so well comes down to the way he handcrafts each issue. Pell takes a different tack on writing, blurring the line between one-to-one and one-to-many emailing. “I am writing my content to be read as a newsletter,” he told me. “It’s not a repurposed blog. I write it as I would write an email to anyone.” The distinction that website and email content should be handled in fundamentally different ways is spot on. The contrast between the two is stark, yet many of the emails arriving in our inboxes today can be considered “website, extra small,” when they should instead be purpose-built to better suit the more personal environment that email makes possible.

Pell also likes the relative permanence of email “in this era of Facebook and Twitter streams, where the news seems to flow by in the blink of an eye,” and he says there’s a benefit to the fact that “a newsletter is right where you left it.”

The Audience

Crafting kick-ass subject lines and content won’t get you anywhere, however, if you’re writing to the wrong people. Recognizing your audience and what they expect is an important factor in crafting a successful email. In Pell’s case, NextDraft emails are written in a voice and tone of familiarity, which resonates with his readers and makes each issue valuable to them.

Knowing your readers is easier when you have a narrowly defined audience, like Pell does, but it’s not always clear from day one who your audience actually is; the readers of the Obama for America emails had all, at some point, opted in to receive the emails, whether through a petition, a donation or any of the million other ways there were to land on the campaign’s list. But over time, not everyone stuck around.

There’s a certain level of attrition in any audience. When I received my first Obama for America email, I immediately marked it as spam. Those “Hey” subject lines matched a pattern that I considered spammy, especially coming from a source that I didn’t believe would use such casual language. That doomed the endeavor from the start; working at MailChimp, I’m already preoccupied with junk email, so the notion that I’d mark the email as such isn’t really unusual (unless “Democrat 30-something user-experience designers working for an email service provider” is a segment of the population they’re specifically targeting — in which case, the subject line shows a lapse in judgment). So, admittedly, I’m probably not a good representation of who the Obama folks were trying to snag with those subject lines.

But the majority of their readers didn’t go anywhere. In this case, the remaining audience was very likely composed of Democratic and independent supporters of the President. That audience is part of what’s known in psychology as an in-group: a cluster of people who share a collective identity (see Henri Tajfel’s article listed below). Taking this into account, the notion that “Hey” worked makes a lot more sense when you also consider what your average email recipient expects. Obama’s “Hey” and a spammer’s “Hey” both work because we see “Hey” from our friends all the time; as an audience of social animals, people are already receptive to these short titles.

There’s a quote that reads, “I don’t know the key to success, but the key to failure is trying to please everybody.” The remaining readers were already predisposed to open any email coming from the Obama camp. They made up a more narrowly defined audience that was emotionally invested in these campaigns, and they were exactly the right group to target.

The Source

Over the long haul, the combination of a catchy subject line, interesting content and an ideal audience will certainly get an email opened and read, but it also nets something else that contributes to long-term success: trust. When people subscribe to a list, they’re actively seeking a relationship with the creator and trusting that the communication they receive will have some value.

Here again, NextDraft is the perfect example. Dave Pell’s readers rely on him to curate, summarize and deliver each day’s important or compelling news stories. That’s a big responsibility for Pell, especially considering that some of those readers might be using NextDraft as one of their few news sources.

In a world where everyone has too much to worry about, many people can’t keep up with current events by seeking out stories from specific news websites, and instead rely on aggregators — be they friends, blogs or half-hour comedy news shows like The Daily Show and The Colbert Report. Given this, we can see how Pell himself acts as a news source. He isn’t simply forwarding content from various sources; he’s selecting meaningful stories, offering commentary and helping the reader to digest each item — much like an anchor you’d see on a nightly news round-up.

Pell has developed a trustworthy voice with a sense of gravitas, but he can also be funny and lighthearted, and his tone changes to suit the news he’s summarizing. Pell’s personality, combined with his interesting and reliable emails, builds trust. His emails resemble something we’d receive from a friend. Pell says there’s “a certain level of intimacy to the exchange… People let me into their inboxes, and if they have something to say, they can just hit reply.” This openness to discussion makes his readers trust him even more, and his conversational style of writing makes him more accessible as a creator.

Practical Application

The principles followed by Obama for America and Dave Pell are building blocks that we can apply to any other email campaign.

Knowing the audience might be the most important piece of data to have before that first campaign goes out, although we may not know who exactly that audience is. In the beginning, casting a wide net is OK. Eventually, defining the audience more narrowly will be essential; that broad view that we start with makes it harder to find what works moving forward. Specialization is key. We can begin to focus on a more narrowly defined audience simply by asking ourselves who we’re writing for, by finding our in-group. Is that group comprised of industry peers? People with similar cultural interests? Friends? We can adapt our content and style based on this better understanding of the audience. We can come to a place where we’re sending them email they actually want to read over and over because, in the end, it’s something we’d read ourselves.

Once we’ve defined our audience, then crafting subject lines that work is about fitting the right peg in the right hole. It’s not an easy task, but we can home in on what piques our readers’ interests and develop a good hook by using our own preferences as a baseline. What would I like to see? What would get me to open this email? From there, we can iterate. Just talking to family, friends and coworkers to get an idea of what subject lines hit the right note for other people is a great place to start. Once the audience is a little larger, something more formal, like A/B testing, is a logical next step. With feedback from others, we then have a chance to develop our voice and tone and write in a way that keeps people interested and that fosters the relationship between creator and consumer.

Panic uses beautiful emails with a friendly and helpful tone and voice. Larger version. (Image Source: Lucien W. Dupont)

Writing good email content is a craft of its own, and one that isn’t easy by any stretch of the imagination. We can start with some good baselines, however. Email isn’t a long-form medium, and in a world that’s becoming increasingly mobile, lengthy and wordy often does more harm than good. Write like the audience is distracted. We’re dealing with small screens, busy lives and short attention spans — every email benefits from being short and sweet. What we write should be focused, clear and concise. We can better serve our readers by formatting content into digestible sections. If we have a lot more to say, then linking to external content or even returning to the topic in the next email might make sense; the semi-permanent nature of email allows for some episodic risks to be taken. Remember, too, the importance of design in email. Presenting content in a beautiful way, whether through images or typography, can also improve how readers respond to emails.

Even given great content, the importance of creating a two-way relationship with readers can’t be overstated. Building a connection and making an email something that our subscribers have a stake in is necessary for success. Trust is at the root of that connection. If we’re able to provide readers with something of value that doesn’t just add to the background noise of life, then they’ll find the time and commit to hearing what we have to say. This bond is the ultimate goal for creators. A little personality goes a long way when it comes to making email interesting and worthwhile. People don’t want neutral email; they want intriguing and familiar. If the Obama campaign can get away with a “Hell, no” in its subject line, we can all find a way to pour a little bit of our own personality into what we write. Humans are social animals by nature, so why not make emails more sociable?

One-to-many mass email is, by definition, a largely impersonal venture, so email often ends up boring and lacking in character. But with care and attention, we can buck that trend and create emails that mean something to people. By getting to know your audience and writing to them in a personable and conversational way, your email can rise above inbox noise. It can be about human connection.

Sources

• “The Myth of Multitasking,” Christine Rosen, The New Atlantis
• “Beyond Simple Multi-Tasking: Continuous Partial Attention,” Linda Stone
• “Compassion Fatigue as Secondary Traumatic Stress Disorder: An Overview,” Compassion Fatigue: Coping With Secondary Traumatic Stress Disorder in Those Who Treat the Traumatized, Charles R. Figley, Routledge (1995): pages 1–20
• “The Science Behind Those Obama Campaign E-Mails,” Joshua Green, Bloomberg Businessweek
• “Message Machine: Reverse Engineering the 2012 Campaign,” Jeff Larson and Al Shaw, Pro Publica
• “Social Identity and Intergroup Behavior,” Henri Tajfel, Social Science Information, Vol. 13.2 (1972): pages 65–93
• “Mobile Email Opens Increase 123% in 18 Months,” Justine Jordan, Litmus

(al)

© Fabio Carneiro for Smashing Magazine, 2013.

A design founder is a founder of a company who happens to be a designer or makes sure to create a large role for design in their business.

Design is extremely powerful — it influences what we see, what we feel and even what we do. As old, salesy techniques are being thrown out the window, business have to find new and creative ways to solve problems. What better way than with design?

Why are they important?

Design founders have evolved ways to create new and innovative products while changing the way we interact with things. Some of favorite design founders are guys like Steve Jobs and Charles and Ray Eames.

Right now, markets are changing. People are responding poorly to being sold to, and other slimey, push marketing techniques. People want to be able to make connections and feel like a part of other businesses and brands. Researchers, marketers and strict businessmen are having a hard time with the concept of creating a connection and putting the customer first.

Design founders are not just making pretty websites and products, but they’re solving problems and making everyday life easier for consumers. Below, we will spotlight some popular as well as up and coming design founders that are changing the way we do things.

Evan Sharp, co-founder and developer at Pinterest

Pinterest is one of our newer social media sites that gets us closer to the things we’re interested in. I recall that in the beginning, Pinterest wasn’t a public site you could just sign up to, you had to have an invite. That exclusivity created a bit of buzz and desire for people who thought they may have been interested in what Pinterest was. Evan Sharp, for that alone, was a genius in creating some excitement for a new social platform.

The Internet is all about sharing and is especially mundane if you don’t do so. Pinterest is a place where sharing is caring and feels more mature and common-sense than places like Tumblr or even Reddit for that matter.

Sharp was an architecture student who started Pinterest as a fun side job, but eventually it grew and he now works full-time on the front-end development of Pinterest.

Christina Brodbeck, CEO of theIceBreak

There’s a lot to do online if you are trying to get into the dating scene. Take your pick — there’s so many different niche’s of people you can find online. But what about the folks who aren’t looking for their significant other, but want to keep the one they have happy?

There’s not a ton of that out there, but Christina Brodbeck (former UI designer at YouTube) decided she wanted to change this. TheIceBreak is an app (and soon a website) that creates a space for couples to interact with each other.

They can answer questions, send pictures and even suggest things to do with each other. It’s a fresh, new approach to keeping connected and communicating with your honey.

Matias Corea, co-founder and chief of design at Behance

Artists and designers needed a space on the web that was theirs. It wasn’t shared with teenagers who liked to draw and folks who just picked up an illegal copy of Photoshop a few weeks ago. They needed a place where they could showcase their work, connect with other designers and possibly be discovered by new clients.

Matias is a graphic designer who claims to be heavily influenced by electronic music and its culture. He is in charge of every piece of visual brand and identity for Behance, including the Behance Network and the ever popular 99% Conference and Magazine.

Rob Kalin, founder and former CEO at Etsy

Lots of guy want to go into business by trying to sell a product or service to as many people as possible. Think about how many platforms there are for e-commerce and selling whatever you want. Now, think about how many are created with simple, specific niches in mind. Enter Etsy, the selling platform for vintage and handcrafted goods.

Though Rob Kalin has recently stepped down from his position at Etsy, you cannot help but give him major props for what he’s done.

The greatest thing with platforms for selling is building trust for buyers as well as sellers, and he’s done just that.

Jack Dorsey, co-founder at Twitter/founder at Square, Inc.

If you haven’t heard of Jack Dorsey, it may be time to start paying attention. This guy is really a great innovator for this time and is really changing the way we do many things.

You’re already very familiar with his body of work as he’s the guy who introduced the world to Twitter. The micro-blogging platform almost single-handedly changed how we interact with peers and companies as well as how we share the web.

Jack is back with his new company called Square. It allows the traveling businessperson to accept debit or credit cards with their iPhone or Android phone. He’s continued to develop the small device into an app called Square Register which is the most intuitive cash register ever created for small businesses.

Square just makes sense and since its introduction, has seen lots of copycat devices pop up.

Brian Chesky, CEO and co-founder at Airbnb

We live in a world where it’s easy to be paranoid and think the worst of people. You can’t just make friends with everyone or even trust postings on Craigslist and the like. I mean, wouldn’t it be nice to travel to new cities and be able to crash on someones coach or stay in their extra room? It’d be a lot more affordable and could even end up being more comfortable.

Fortunately, Brian Chesky at Airbnb has found a way to make this happen. It’s easy to find cheap accommodations and to trust people enough to stay with them for a few.

Brian drives the vision of Airbnb and is a former industrial designer. To help him establish the visual brand of Airbnb, he gave up his apartment and stayed in various places available at Airbnb. That’s right folks, he’s been living with other, random people since June 2010. Talk about commitment! 

Jesse Pickard, CEO and co-founder at Mindsnacks

I’m rather old-school (though I’m pretty young) and I recall when I was much younger, I played board games or even went outside to play. I must say I was absolutely floored the first time I saw a 2 year old request their parent’s phone, only to play a quick game of Angry Birds. And I must say, he was pretty good.

Technology is great, and if we are going to let our kids use it to play games, well, wouldn’t it be nice to let them play educational games?

Wouldn’t it be nice for YOU to play an educational game, just to keep your brain and thinking fresh. This is exactly what Jesse Pickard over at Mindsnacks did. He’s created several addictive games to help learn languages, do better on SATs and much more.

Maurice Woods, designer and co-founder at Convozine

Anyone can start a blog. But you have to be a different type of, self-motivated person to manage and maintain the blog. You have to be dedicated to that blog so that it can create some traction and grow with subscribers and daily visitors. Many people will tell you it’s easy, but trust me, it takes a lot of work. Some of which, people aren’t too fond of.

However, what do you want to do if you want to have a voice online and share the things you like and maybe even start a community from it? Well Maurice Woods and his friends over at Convozine are trying to fix this problem.

Over at Convozine, you’re able to make an electronic magazine (which we call ‘zines’) that can easily be created and published with new or shared content. You can have people contribute and collaborate based on interests. And the best part is the Convozine network puts your zine in a place where anyone can discover it and become interested subscribers. That’s web publishing with a TON of work taken out.

Dan Parham, designer and co-founder at Neighborland

Everyone wants the best for their community and neighborhood. Sometimes, the powers that be don’t always get the job done or take issue with the things others do. Sometimes people in your own neighborhood don’t take issue with the things you do. So how can you tell what needs to happen and what doesn’t?

Dan Parham and his team built Neighborland on this entire premise — what if we could see what our neighbors really wanted? And then what if they decided to do something about it?

Neighborland empowers people to be the change they want to see in their community by sharing ideas and promoting action.

Jeff Veen, vice-president at Typekit

It’s no secret that it’s much better to use live text on webpages than to create graphics for large headlines and even links. There’s so much we can do with different coding languages now to counteract that type of thing.

If we want to use reall nice fonts, we have to buy each one individually and quite frankly, that can get expensive. There are also free alternatives, like Google Webfonts, but there aren’t a ton of high quality fonts in there.

Jeff Veen saw this problem and created a solution; a subscription based service for high quality webfonts.

Conclusion

These guys are using the full potential of design to create emotion, relationships and provide ease for consumers all across the world. What must be said is all of these guys just took a creative approach to what was a common problem that kept surfacing in other ‘solutions’. Design founders are showing every business owner and CEO that it’s time to look at things differently and to create a bigger a role for design in business.

What do you feel are the position of designs in business? Are you into the design-founder hype? Share your thoughts in the comments section.

Get Certified Adobe Training for Web Design – 50% off!