Speeding up Email and Ditching buttons

Save people time and earn their traffic

This is where a email needs to evolve – both on the UI/UX side and the etiquette aide. The fact of the matter is, younger people dislike and do not use email as much …and for good reason. It feels like a slower form of digital communication. If it feels slower it is slower.

  • Emails often imply or demand inefficient and irrelevant ‘analog letter etiquette’ both in tone and formatting.
  • Enterprise email clients and best-of-breed web-based clients like gmail overwhelm you with options for formatting, cc boxes, draft saving etc.

Most of the time, all you want to do is dash off a simple one sentence line of text and fire it off to someone you know. SMS, baby.

We ditched the <vote> button on the poll product we built and have never received one complaint from end users despite serving over 500,000 polls a month. A vote occurs the moment you select a radio button. One click.  This may violate some arcane notion of “how a radio button is supposed to function” based on 1990s web interface rules but it also saves time.  Guess what matters more?

100,000 seconds is almost 28 hours. In other words, I’ve probably wasted a day of my life hitting that stupid button

Gmail Lite: If You Build It Google, We Will Come.

User Driven Development

wizard of oz - the man behind the curtain
Fake it Till You Make It

I like faking functionality and shipping quickly to gauge real world uptake prior to development. This is not always feasible but if it is, it has a lot of upside. Developers do not like to carefully build out features that are possibly going to get killed.  They often resolve this dissonence in two ways:

1. Build a partially implemented feature and push live as a ‘live prototype’ with the idea that the module can be refactored if it actually survives. The danger with this is that the ‘prototype’ might suck and that the planned re-factoring often never happens. Matt Mercieca makes the case that a badly implemented feature that is released into production should not be called a prototype at all.

2. Kill it in process – leverage the fact that correct implementation of an unproven feature would be time-consuming to force management to de-prioritize it against other initiatives that have proven value. This means that the feature may never make it in front of the user.

With a faked feature already in the wild and successful, Developer can be told to build it out smart, built it to last and to scale and s/he will believe that there is a reason for this effort beyond pure hope.


Posted from WordPress for Android

Great Introductory Video on Scalability from Harvard Computer Science

Before The Meltdown

The next time there is a substitute teacher on duty at your workplace, pull down the shades and gather all of the junior engineers and non-technical managers around for a great introductory video on Scalability from Harvard Computer Science. The core topics discussed in this video need to be well understood by anyone claiming to be an “internet professional”. (eew) That includes you too, Randi-from-BizDev btw.

Steam-Powered Record Player

Go ahead and stop paying ConEd

A friend of mine has a rustic summer cottage on a private island pm a river. There is no electricity. This lack of everything modern is one of the main charms of the place except when it comes down to music listening: You can go through dozens of batteries in a week just powering a portable stereo which is both environmentally suspect and expensive. If only i knew this thing was available.

Steam-Powered Record Player