The Copycopter logo process

My process for designing logos isn’t much different than the process that I use to design for the web. It starts with a bit of research and sketching and then a whole lot of refinement. The Copycopter logo will serve as a case study as I travel through my process.

Stage 1: Research & information gathering

I start by gathering information, a description and a list of adjectives, about the company, product, etc. As the client talks, I take down notes of words or phrases that I feel are important themes. I ask a ton of questions ranging from stupid to hard to answer. Why do they need a logo? What kind of personality should it have? Where is it going to be used?

Then I start looking for real world examples—photography, illustration, typography and design—that convey the attitude, personality, and any relevant visual elements. I stay away from looking at any other logos as it tends to give me tunnel vision on those examples. When I’m done, I’ll throw all these files in a folder for reference later in the process.

In the case of Copycopter, this was a bit easier. I had already designed the interface for the app so I already knew a good bit about what it was and the personality we wanted associated with it. It needed to have a helicopter or at least part of a helicopter in some way since it wasn’t reflected in the apps interface. This direction allowed me to really focus my search.

Stage 2: Sketching & idea generation

Sketching is the most important step in the logo process for me. It allows me to document a bunch of logo ideas really quickly. I get rid of the attachment that I have for my first idea and get all the bad ideas out of my head.

I fill up between two to four pages in my sketchbook with concepts. It’s a habit that I picked up at my first design gig, my art director demanded at least three pages. Each sketch should only take a half a minute and it should only take you an hour or two to get all your ideas down. While sketching I usually have the reference material that I just collected in-front of me and often continue the research while sketching. Don’t worry about the quality of your sketches or the quality of the concept while doing this. The time it takes to do one sketch allows for a shotgun approach. I’ve found doing this dump of ideas produces a better overall product.

I stop when the ideas that I am generating seem consistently useless. If I am struggling with ideas or want to dig deeper into an idea, I’ll start word association drills. This, then, leads to more sketching and research.

Stage 3: Selection

At this point, I narrow down the sketches to 3–5 of my best concepts and fire up Illustrator (my vector tool of choice) to mock them up. I’m still trying to work through these quickly so I’m not being exact with my vector points just yet.

I’ll stick to a dark gray usually during this process, which makes me concentrate on quickly seeing which concept could be the one that I really want to move forward with instead of focusing on color. This process also assures the logo will work in one color. If I do need two colors, I will use shades of gray. If the logo is a symbol, I will also start to pair it with typefaces.

In the case of Copycopter, I thought that one of my sketches was so on target that I took a photo of it with my phone and traced it in Illustrator. For the type, I was sticking to chunky sans-serifs and handwritten scripts. Both have a quirky friendly feel which is what the goal of the logo was. I used the color scheme that had already been defined in the web app instead of starting with gray.

At the end of this stage, when I have something that I think resembles the direction I want to go, I show the client. I only show the client one concept—the one I know is the best choice. The client was in-house for Copycopter and I was already showing the concepts that I had going.

Stage 4: Refinement

The refinement stage is all about fine-tuning the nitty-gritty details. I start adding color, refine the vector points and hone in on the other details in the logo. I really focus on the type, editing any characters that I don’t like or think could fit better with some simple edits. Most importantly, all the characters in the logo need to be kerned properly.

I really tried to refine the angle of flight for the Copycopter logo. The copter needed to be somewhat dynamic but not so much that it looked odd. It started out on a more drastic slope so I rotated it slightly. Getting the right angle and thickness right for both the blades and the tail made big improvements to the symbol.

This is of course an ideal process flow, it rarely is as linear as I have made it sound here. For example if I don’t feel any of my mockups I did in Illustrator are working, I’ll go back to sketching. I did this multiple times while trying to do the Copycopter logo. Also, because this was a thoughtbot project, I did not have to deal with the demands of a client. Dealing with demanding clients and the feedback they provide, the logo design process will often change from the example stated above.

If you haven’t already, check out the Copycopter logo in its environment at copycopter.com.

Copycopter’s client: so fast

We recently launched our latest product to great critical acclaim. We’re happy to see people climbing aboard the Copycopter, and feedback has been largely positive.

However, one question we’ve had to field a few times is, “how will Copycopter affect the performance of my application?” The answer is a good one: it won’t. However, that answer may seem too good to be true to some folks, so let’s find out how Copycopter manages to stay out of your application’s way.

Integration

One of Copycopter’s nicer features is that the Ruby client is deeply integrated into the Rails stack the second you install it. This is made possible by the excellent Rails I18n API. We hook in our own I18n backend so that whenever Rails looks for a string, we use the text you’ve set up on Copycopter. This all happens in copycopter_client’s I18nBackend class. If you read quickly through that class, you’ll see that fetching or storing copy doesn’t make a request to the Copycopter server; it looks for content in the hash-like sync object.

def lookup(locale, key, scope = [], options = {})
  parts = I18n.normalize_keys(locale, key, scope, options[:separator])
  key_with_locale = parts.join('.')
  content = sync[key_with_locale] || super
  sync[key_with_locale] = "" if content.nil?
  content
end

Behind the scenes

The client’s performance is acheived by using a background thread. When your Rails application starts up, the client spins up a thread in the Sync class.

until @stop
  sync
  logger.flush if logger.respond_to?(:flush)
  sleep(polling_delay)
end

Every five minutes, the background thread synchronizes with the Copycopter server. It uses mutexes to make sure it isn’t updating copy while the application is using it. However, the mutex is only locked when already downloaded copy is being swapped in, so the main thread won’t be waiting for a lock to release.

def download
  client.download do |downloaded_blurbs|
    downloaded_blurbs.reject! { |key, value| value == "" }
    lock { @blurbs = downloaded_blurbs }
  end
rescue ConnectionError => error
  logger.error(error.message)
end

HTTP friendly

We also don’t want to waste any bandwidth or cycles by repeatedly downloading unchanged copy. The Client class is responsible for actually talking to the Copycopter server, and it speaks fluent HTTP.

def download
  connect do |http|
    request = Net::HTTP::Get.new(uri(download_resource))
    request['If-None-Match'] = @etag
    response = http.request(request)
    if check(response)
      log("Downloaded translations")
      yield JSON.parse(response.body)
    else
      log("No new translations")
    end
    @etag = response['ETag']
  end
end

Each running client tracks the latest ETag when it downloads copy, so most requests simply return a 304 Not Modified response without sending any copy data.

when Net::HTTPNotModified
  false

Developing

It should be mentioned that this passive behavior is only used in production environments. During development and on a staging server, we found a five minute delay between copy updates to be unacceptable. During development, we wrap each request using a little piece of Rack middleware:

def call(env)
  @sync.download
  response = @app.call(env)
  @sync.flush
  response
end

Although this could potentially add a slight delay to local requests, we found that the faster feedback was worth the tradeoff, and the smart HTTP handling, caching, and timeouts ensure that developing still feels snappy.

Putting it all together

By integrating with I18n, using a background thread, and using the HTTP protocol to our advantage, we achieve a number of performance and stability benefits:

• Slow copy downloads don’t mean slow applications
• Server errors don’t mean application errors
• Lots of application traffic doesn’t mean many Copycopter requests
• Up-to-date copy doesn’t cost much in terms of bandwidth
• Rails uses the I18n stack, so Rails engines and plugins support Copycopter by default

If you haven’t given Copycopter a try yet, don’t let apprehensions about performance stop you. Check out the code, install the client, and see for yourself.

Get to the choppa!

Introducing Copycopter: let your clients do the copy writing

We’ve worked with quite a few clients in our time and a repeated issue we run into is managing what we affectionately call “copy.” These little blurbs of text barely make it into the peripheral vision of most programmers, but headings and marketing descriptions can be vitally important from the site owner’s perspective. While developers are obsessing over the best way to create pages, clients are often obsessing over the wording on those pages. Here’s a familiar scenario for most developers:

Developer: Okay, the sign up page is live now. Just click “Sign Up.”

Client: Looks great, but can it say “Sign Up Now?”

This is a simple request, but now you have to change the text on the page, possibly correct a few Cucumber scenarios, rerun your test suite, and deploy to staging. Here’s my favorite:

Developer: Okay, it says “Sign Up Now.”

Client: Actually, I think we should change it back.

Actually, I lied - that’s a fun scenario, but it’s not my favorite. My favorite is when you get this after another month of development:

Developer: Alright, the sign up page is deployed to production.

Client: Speaking of sign ups, I talked to a few more people, and I really think it should be “Sign Up Now” after all.

At this point, do you try to explain that your master branch has features that aren’t ready to go live yet? Do you create a new branch based on the previous stable branch, change your text, deploy that, and then back port the change to master? Do you tell him he’ll just have to wait until the next deploy?

These examples may seem trivial or absurd, but I bet you’re nodding your head in agreement right now. The truth is there’s a lot of development time wasted on this kind of mindless coding. Copy is important and all of these clients requests were simple, so why is this so hard?

Copycopter saves the day

We wanted a better experience both for ourselves and for our clients, so we created Copycopter.

Copycopter allows you to write default copy in the application that can later be edited by clients without changing the application code or issuing a new deploy. Setting up an application with Copycopter is simple.

Sign Up

Creating a new project takes only a few minutes, and you can try Copycopter for free.

Install

Copycopter comes with a client gem for Ruby applications, so just add it to your Gemfile:

gem "copycopter_client"

Configure

All you need to configure is your project’s API key:

CopycopterClient.configure do |config|
  config.api_key = "81caded18444fc3b60e56622f927bcce"
end

Add

Once your Rails application is linked to a Copycopter project, you can add blurbs using the standard I18n API.

<%= link_to t(".sign_up", :default => "Sign Up") %>

Edit

As soon as a you view a page with default copy, the client will create the blurb with the default copy in Copycopter.

Any changes you make from Copycopter will automatically be reflected in the live application.

Deploy

Copycopter is intended to fit the natural rhythm of developing locally, testing on a staging server, and publishing to production. All blurbs start in a “draft” state, which will be displayed during development and on staging servers. The Copycopter client comes with a deploy task, which will mark all blurbs as published. Adding this task to your production deploy scripts will allow you to naturally move new blurbs to production as you deploy the pages that use them.

Of course, if you want to directly change any copy in production, you can do that, too.

Get to da choppa!

If you’re tired of doing the copy text tango with your clients, sign up for Copycopter and leave the copy writing to your clients. We hope to see you on the chopper soon! Sign up now now!