Venn Candid discussion on building a design-development agency

Revisualizing Charity Donations

I recently came across an interesting graphic, but I was left with more questions than answers.

Original Graphic

The most important question to address when visualizing or analyzing data is: does this create the correct mental model for readers? I do not think that this infographic does.

First, it uses circles for comparison. Humans are good at length comparisons, average at area comparisons, and weak at everything else. Worse, comparing the relative size of circles in this particular chart is misleading because quantities are actually represented by radius rather than area. Without reading the numbers, the relative differences between quantities appear much greater than they actually are.

Furthermore, the infographic only covers a single fundraising program per cause, which warps the analysis into punishing programs that are the most successful.

In any case, here is my redesign of the infographic:


What I would really like is a better data source so we can properly compare which causes have the most immediate need.

Building a juicy progress bar component in Ember

Over the last week I have been working on building an image uploader for an open source project I am working on.

For this application we are making use of circular profile images. I wanted users to see how the image they are uploading would be used in the application while also showing the progress of the upload. By combining the two we get to reinforce that the bar indicated upload progress, and also allow for a very tight aesthetic.

You can see the final version below. Hit the simulate button to see it in action.

Creating this effect is not possible in CSS as far as I know, so I decided to build it using SVG. Here is the basic SVG setup:

<svg {{bind-attr viewBox="viewBox"}} xmlns="">
  <circle class="bar" {{bind-attr

The user supplies a diameter which we use to size the SVG container and to draw a circle that fill it. We then make use of a dashed line for the stroke, with each dash being the length of the circle’s circumference. Then, by shifting the starting point of the line we can show how much progress has been made.

dashOffset: Ember.computed('diameter', 'percentage', function() {
  var percentage = this.get('percentage') * 0.01;
  var circumference = this.get('circumference');

  // We have to factor in strokeWidth here because we are using a rounded edge
  // on the stroke that makes it appear to be further along than it really is
  var strokeWidth = this.get('strokeWidth');

  return circumference - (circumference * percentage) + (strokeWidth * 2);

The styling itself happens via CSS, so it is very easy to customize the colors and animations.

Edit: I removed the rotate transformation from the circle itself because Firefox uses a different origin point than Chrome. Instead I apply the rotate to the div that contains the svg element. The rotate is necessary because the dash starts at the 90deg point and we want to shift it to 0deg.

.circular-progress-bar .bar {
  stroke: #1787e5;
  fill: none;
  stroke-linecap: round;
  transform-origin: center;
    stroke-dashoffset 0.6s,
    stroke 0.6s;
} {
  animation: circular-progress-bar-complete 1.3s 1;
} .bar {
  stroke: #8fd713;

@keyframes circular-progress-bar-complete {
  0% {
    box-shadow: 0px 0px 0px 0px rgba(143, 215, 19, 0.4);

  100% {
    box-shadow: 0px 0px 2px 40px rgba(143, 215, 19, 0);

The Ember code is pretty basic since you are just doing basic math to calculate radius, circumference, and progress percentage. I haven’t yet decided if this is a significant enough component to make it into EmberUI, but it could be pretty useful if made more customizable.

You can see the full component code here:

Switching to vim

You have likely encountered dozens of posts wherein the author extolls the virtues of their new and Vi IMproved life. They save thousands of tedious trips between mouse and keyboard each day. They edit text at the speed of thought. They can perform emergency hotfix heroics becuase vim is installed on every production server.1

There are also posts describing the elegance of conceptualizing text editing in terms of text objects and motions.

These are all merits of vim but not what made me switch.

Plays well with others

A while ago I started pair programming more often with vim users and my rudimentary skills soon became an obstacle. Sure there are setups where each pair can use their own editor but they require too much setup and as such tend to ruin impromptu sessions. Even though I knew it would be a lot of work, I wanted to become at least competent with vim.

That other editor only crazy people use

I have been using emacs as my primary editor for about 10 years and I am fairly productive with it. vim is well-known for having a steep learning curve but I expected it would be especially difficult coming from such a different editing paridigm.2

Easier than I thought to pick up

Rather that hindering I think my emacs experience actually helped me to pick up vim faster. I suspect that learning how to work without a mouse, graphical file tree, etc. is a significant part of vim’s learning curve for most people.

But not too easy

I still have a ways to go. I am not yet as fast with vim as I was with emacs. I’ve also rewired enough of my muscle memory that switching back feels painful and cumbersome even though not doing so can be slow at times. The surprising thing is this doesn’t bother me as much as I would have expected. I actually prefer to edit in vim even though I only know how to do a fraction of the things that I could do in emacs and a fraction of the things most other vim users can do.

The interesting bit

Despite having so little practice and so little knowledge of various operations I’m nonetheless nearly as productive in vim as I was with emacs. I struggled to understand this but I have a theory: having only a small set of operations that compose well goes a lot farther than a large set of operations that do not.

Before I got to see people working with vim I had the mistaken impresison that they learned thousands of little keystroke combinations that let them do very specific things. This might be true for some really nerdcore developers but most people just learn efficient ways to perform common manipulations and do them over and over again until they are editing without thinking about it.

emacs is an incredibly rich development environment and supports some really powerful types of operations. However, remembering all of the little details is difficult. One often has to use the built-in help system or try out a few practice edits to make sure something works the way you expect.

The problem with this is that it takes you away from the task at hand. Thinking about a way to make the exact transformation you need in one shot is a waste of time when you can just make a handful of simpler modifications that accomplish the same thing.

Furthermore, once you start making these edits mechanically, without really thinking about what you are doing, your mind is freed up to think about the actual problem your code is trying to solve.

Understanding this made me feel strangely liberated: I don’t have to become an expert with my editor in order to be able to use it well.

  1. Don’t ever do this.

  2. Fear of being excommunicated from the emacs community was another risk.