Links and articles about technology, design, and sociology. Written by Rian van der Merwe.

An automated image upload workflow for Amazon S3

I have no idea if anyone else will find this helpful, but I’m so excited about it that I have to share it1. One of the most time-consuming and repetitive tasks in blogging is uploading images to my Amazon S3 account, generating the CDN link, and inserting it into the post. But I’ve now cobbled together a recipe that makes this really easy, and I’d like to tell you about it. First, here are the ingredients you’ll need:

  1. An Amazon S3 account for image storage (optional: Cloudfront CDN)
  2. TextExpander to handle the repetitive typing
  3. Hazel to automate the upload to S3
  4. Dropbox isn’t technically necessary, but it makes everything just a little bit smoother.

With that said, here are the steps in the recipe:

Step 1: Set up a Hazel workflow to upload new files to S3

First, we need to set up Hazel to watch a folder and upload any new files to your S3 bucket. The Macdrifter article Upload to Amazon S3 from Dropbox using Hazel is extremely helpful for this. I basically copied that script with some minor adjustments. Here’s what it looks like:

Hazel upload to Amazon S3

Note that you have to change the type of shell script you run to /usr/bin/python. The script I use looks as follows (again, see the Macdrifter article for the whole story):

import boto
from boto.s3.connection import S3Connection
import os
import sys
import urllib
from datetime import date, datetime
import subprocess

# This is how Hazel passes in the file path
hazelFilePath = sys.argv[1]

# Obviously, you'll need your own keys
aws_key = 'YOUR_KEY'
aws_secret = 'YOUR_SECRET'

# This is where I store my log file for these links. It's a Dropbox file in my NVAlt notes folder
logFilePath = "/Users/~YOUR_COMPUTER_NAME/Dropbox/Notational/Link_Log.txt"
nowTime = str(

# Method to add to clipboard
def setClipboardData(data):
    p = subprocess.Popen(['pbcopy'], stdin=subprocess.PIPE)
    retcode = p.wait()

# This is the method that does all of the uploading and writing to the log file.
# The method is generic enough to work with any S3 bucket that is passed.
def uploadToS3(localFilePath, S3Bucket):
  fileName = os.path.basename(localFilePath)

  # Determine the current month and year to create the upload path
    today =
    datePath = today.strftime("/%Y/%m/")

   # Create the URL for the image (Add your own path here)
    imageLink = ''+urllib.quote(fileName)

    # Connect to S3
    s3 = S3Connection(aws_key, aws_secret)
   bucket = s3.get_bucket(S3Bucket)
   key = bucket.new_key('images/'+fileName)
   logfile = open(logFilePath, "a")

       # %% encode the file name and append the URL to the log file
       logfile.write(nowTime+'  '+imageLink+'\n')

# Add your bucket name here.
uploadToS3(hazelFilePath, 'YOUR_BUCKET_NAME')

Here’s what the script does in my case: Whenever I add a new file to the Img folder in Dropbox, it uploads the file to S3, copies the URL to the clipboard, and also adds that URL to a Link_Log text file in my nvALT folder for later access if needed (or if I add multiple images in one go).

Step 2: Set up TextExpander shortcuts

Once the image is added to S3, the rest is handled with TextExpander. When I want to add an image to a blog post I type:


That expands to:

<p><img style="display: block; margin-left: auto; margin-right: auto;" title="%fill:image title%" src="%|%fill:image source%" border="0" alt="%fill:image title%" /></p>

It asks me to give the image an alt tag, and then it places the cursor where I’m going to add the source file. Since the source URL is already in my clipboard, I then just ⌘-V and I’m all set.

They call it magic

That’s it. It might seem like a lot of work, but now that everything is set up my workflow is extremely simple:

  1. Add new image to the Img folder
  2. Type the TextExpander shortcut and paste the Image URL where I want the image to appear

I think it’s going to save me at least as much time this year as it took to write this blog post.

Oh. Wait.

  1. It also gives me an opportunity to pretend I’m Dr. Drang, but I digress. 

Just another distributed team workflow with Trello and InVision

Working with people can be hard. Designing with people can be even harder. Designing with people who are not in the same location can be almost impossible. There’s no perfect solution for working in distributed teams, but if there’s one tool that seems to get our community further than most, it’s Trello. I’ve seen some really great Trello workflow posts over the past few months:

We have a distributed team across Portland, OR and Dallas, TX, and we use a workflow similar to the ones above, but different enough to make me think it might be worth sharing.

As background, we have a team of 5 UX Designers who split their time across 3 main products as well as our internal Pattern Library. Each product has a Design Lead (this role can rotate), and we define the Lead’s responsibilities as follows:

  • Understanding and documenting user needs, business goals, and technical constraints before any design work starts.
  • Being the single point of contact for any design questions by Product Managers or the rest of the business.
  • Making sure Trello is updated with latest priorities, due dates, and artifacts.
  • Making tie-breaker design decisions as needed and required if there are design disagreements and we can’t reach consensus.
  • Designing interactions and screens, and/or implement those designs in the pattern library, and distribute the workload to other designers as needed and capacity allows.
  • Explaining and defending design decisions, even at 8:30am before having a cup of coffee.

Granted, that last requirement is a bit harsh, but we set high standards for ourselves here.

Anyway. Our week starts on Thursday mornings with a Design Pipeline meeting where we go through our upcoming tasks as a team, give each other design feedback, and play with the animations in Google Hangouts. Here is a typical Thursday morning view — Trello on the left, Google Hangouts on the right:

Trello workflow

Each Design Lead comes to this meeting with an understanding of their Product Manager’s main priorities so that we can discuss how to divide up the work. As you can see above our Trello board has 6 columns:

  • Backlog: Work that’s coming down the road, prioritized every week by the Design Lead after talking to their Product Manager.
  • Up Next: What we’re going to work on next once current tasks are complete. We use our Pipeline meeting to pull cards out of the Backlog and into the Up Next column.
  • In Progress: In typical Kanban fashion we try to limit work-in-progress, so for a card to be in this column it really has to be in progress. During our Thursday meeting we have an opportunity to give feedback and help each other out on any questions we might have.
  • Waiting/Blocked: If something can’t move forward it can’t just sit in In Progress gathering dust — we have to move it into this column. This gives me an opportunity to know where I need to get involved to unblock things if necessary.
  • Done (current quarter) and Done (previous quarter): We keep two quarters of completed cards in the history, and archive further back. If everything goes into one big Done column it just becomes really unwieldy.

A couple of other random points:

  • We use Trello’s color labels to indicate who’s responsible for each card, since it’s not possible to assign a single point of contact to a Trello card (unless you remove the watchers, which kind of defeats the point of, you know, collaboration software).
  • We all dial into Google Hangouts separately from our desks. I find that if you have two rooms and a single dial-in it’s easy to get distracted or for side discussion to start happening. This approach puts everyone on the same playing field, and as an added bonus we can all update Trello together.

During the week we use Trello as a running News Feed of what’s happening on each of our tasks, but sometimes that’s not enough. For ad hoc design feedback during the week we using InVision, a tool I dearly love, and not just because they sent me this nice coaster in the mail (thanks guys!):

InVision is more of an internal scratchpad — a safe place where we can work together as a team and ask each other tough questions about our designs. In contrast, Trello is the paper of record for each of our revisions that we share with anyone who’s interested. It works well for us to separate those spaces out.

The combination of Trello, InVision, and Google Hangouts don’t make up for in-person time (I hope for at least some of us to be in the same space every couple of months), but it sure makes it easier than email and Lync, which is THE BIGGEST PILE OF CRAP SOFTWARE EVER CREATED.

The kicker is that our organization is finally moving to JIRA and Confluence, so we’re currently messing around with Kanban boards in JIRA to replace the Trello bit of this workflow. If we ever figure that out, I’ll write another post about. But for now, this is how we work. I’d love to see how you do it. Write a post, send it to me, and I’ll link to it here.

Typos arent taht bad

In A Corrected History of the Typo Adrienne LaFrance argues that maybe print errors aren’t such a bad thing:

What we’ve lost, in many cases, online, isn’t the integrity of print, but the traceability of its weaknesses. Centuries ago, “errata lists became, paradoxically, markers of well-made books.” The made in “well-made” is a key word here. Mistakes can serve as reminders that books are made at all—the physicality of the process, the “connection between the book going wrong, momentarily, and a sense of the process of production being briefly revealed, or implied,” as Smyth put it in a recent paper about print in Early Modern England. It’s why readers relish newspaper typos—they represent the lifting of a veil, and hint at the human (and that human’s fallibility) on the other end of the object. 

If this kind of thing is of interest to you, it reminds me of post I wrote a couple of years ago called The unnecessary fear of digital perfection. It cites a bunch of articles that lament the fact that we don’t let ourselves make mistakes any more.

Newsletters: not dead yet

David Carr in For Email Newsletters, a Death Greatly Exaggerated:

Email newsletters, an old-school artifact of the web that was supposed to die along with dial-up connections, are not only still around, but very much on the march. [...]


Email is a 40-year-old technology that is not going away for very good reasons — it’s the cockroach of the Internet.

Well, I confess that I have also succumbed to the lure of this particular cockroach, and have been experimenting with a revamped newsletter. If you’re keen, join in…

Why hyperlinks are blue

I don’t quite get the style of John Herrman’s Internet, Why So Blue?1, but this bit about why hyperlinks started out blue is quite interesting:

The man who invented links2 was writing them to a grayscale screen. The first popular browser, Mosaic, later turned links blue because it was the darkest color available at the time that wasn’t black; they needed to stand out, but only just. Blue was the best alternative. Blue always survives the focus group. Blue wins the a/b test. Which is convenient, because blue is usually already there.

  1. It’s probably, once again, because I’m old

  2. AKA Sir Tim Berners-Lee. 

The intent and design of messaging apps

Mills Baker wrote one of the best analyses I’ve seen on the the design of messaging apps in his comparison of Slingshot and Snapchat:

Snapchat seems eager to support naturalness in communication, which can be considered in terms of deformation. It wants to combat draining formalities, make it possible for all parties in an interaction to behave as they wish without anxiety, without fear of publicity or permanence, without the burden of modal moments. In other words: it wants the full range of technologies our smartphones enable to support honest, authentic, spontaneous interaction.

In contrast:

Slingshot makes demands of you for the sake of novelty, without having any organic justification for doing so, whereas Snapchat seeks to support your communicative intent without asking for justification, without even prioritizing things — like a social graph — that would be profitable for it to develop. Snapchat seems interested in helping you communicate; Slingshot seems interested in mandating engagement and experimenting with game-mechanics and arbitrary friction, in service not to your ends but to Facebook’s.

As I read this I kept thinking of Jared Spool’s view that design is the rendering of intent. Even though I don’t understand either of these apps because I’m old, it’s clear that Snapchat understands its intent and the design renders it effectively. Slingshot, on the other hand, appears to be a shot in the dark.

Breaking grammar news

In Punctuated Equilibrium Joe Pinsker reports on an atrocity that doesn’t get nearly enough press — the death of the apostrophe:

A battle is being waged over the apostrophe, and the names of two of the online factions—the Apostrophe Protection Society and Kill the Apostrophe—suggest an extremism usually reserved for blood, rather than ink or pixels. The former, founded by a retired British copy editor, provides a gentle guide to deploying the apostrophe. “It is indeed a threatened species!” the site warns, a little preciously. The Web site Kill the Apostrophe, meanwhile, argues that the mark “serves only to annoy those who know how it is supposed to be used and to confuse those who dont.”

This important article comes hot on the heels of a report on another alarming trend. A recent poll discovered that 43% of Americans don’t believe in the Oxford comma.

We should all know this by now, but just a reminder — this is why the Oxford comma is important:

Why Oxford Comma

Image source

Technology breeds impatience

Two recent articles about technology and our perception of time make some interesting related points. From the clickbaity (yet surprisingly good) Feeling More Antsy and Irritable Lately? Blame Your Smartphone1:

Our gadgets train us to expect near instantaneous responses to our actions, and we quickly get frustrated and annoyed at even brief delays. I know that my own perception of time has been changed by technology. If I go from using a fast computer or Web connection to using even a slightly slower one, processes that take just a second or two longer—waking the machine from sleep, launching an application, opening a Web page—seem almost intolerably slow. Never before have I been so aware of, and annoyed by, the passage of mere seconds. [...]

More interesting is [a recent study of online video viewing's] finding of a causal link between higher connection speeds and higher abandonment rates. Every time a network gets quicker, we become antsier. As we experience faster flows of information online, we become, in other words, less patient people.

Turns out this phenomenon isn’t new — technology just makes it worse. We’ve always adjusted to our circumstances quickly, and we respond by wanting more. From Elizabeth Kolbert’s No time:

“Most types of material consumption are strongly habit-forming,” Gary Becker and Luis Rayo observe in their contribution to Revisiting Keynes. “After an initial period of excitement, the average consumer grows accustomed to what he has purchased and . . . rapidly aspires to own the next product in line,” they write. By Becker and Rayo’s account, this insatiability is hardwired into us. Human beings evolved “so that they have reference points that adjust upwards as their circumstances improve.”

The more we have, the more we want. The faster the internet gets, the faster we want it. What can we possibly do with 1000Mbps that we can’t do just as well with 50Mbps? It doesn’t matter. 50Mbps is the standard now. We’re adjusted. And so up we go…

  1. This is at least better than the original title, which was — I kid you not — You are an impatient monster—but you weren’t born this way. Guess what’s to blame? 

Using technology for healthcare intake

Tom Jacobs discusses some new research that shows people are more comfortable sharing their medical information with virtual people in I’d Never Admit That to My Doctor. But to a Computer? Sure. The implications are interesting:

When it comes to fixing our healthcare system, very few people would agree that part of the answer lies in less human interaction. Patients generally want more, not less, contact with health professionals. Yet this study suggests that, at least for the intake interview, a little less of the human touch — and a little more perceived privacy — may be precisely what the doctor ordered.

It was all yellow

Two articles on the color yellow caught my eye this week.

The first is Object of Interest: The Yellow Card — Rob Walker’s history of the yellow card as it’s used in soccer. In a 1966 World Cup game a referee apparently failed to adequately communicate a penalty warning, which resulted in the birth of the card:

As objects go, it doesn’t look like much. It’s, you know, a yellow card. But when theatrically brandished by an official, almost literally in the face of a player who has done something uncool, it has wild power. It sets off a stadium-full of whistling, and cartoonish arm-flailing from the carded player and his colleagues. A yellow card has real consequences: Possession, a free kick, and the possibility that if the carded competitor blunders again he’ll leave his team understaffed for this match, and will sit out the next. [...]

The cards are a such a brilliant solution to the problem of making sure a penalty has been adequately signaled — they transcend language; they’re clear not just to everyone on the field, but in the stadium, or watching on a screen — that it’s hard to imagine the game without them.

The second is Dan Saffer’s ode to a ubiquitous object in cities: The Hidden Genius and Influence of the Traffic Light.

The yellow light is by far the most sophisticated and cognitively challenging part of any traffic light. Red and green lights have had to consider timing, namely: how long should one side of the intersection remain green, the other red. This creates the “capacity” of a signal: how many vehicles can move through on a single change of the light. [...]

The yellow light doesn’t really control capacity, but instead creates an ephemeral Zone of Decision around the intersection. When a light turns yellow, nearby drivers have a choice to make, quickly: do I speed up and drive through the yellow light, or do I slow down and stop? Driving instructors will of course always tell you that a yellow light means slow down and prepare to stop, but on the street, that’s not always how it works. Sometimes it really would be more dangerous to stop than to run the yellow. And sometimes those driving instructors are right: running the yellow is a terrible, dangerous idea. How do you know which is which?

So here we have two yellows, the one extremely clear (“I’ve made a huge mistake…”), the other an object of anxiety (“Should I stay or should I go?”). And yet we all know what the color means based on history and context and common understanding. I don’t know why that strikes me as fairly remarkable, but it does.

Also, apropos of nothing, does anyone else remember this?

Mello Yello