Making a Thing for People to Use

At Joel‘s patient urging, I finally got around to reading Will Oremus’s piece about Facebook’s news feed algorithm in Slate. I found it to be a really rewarding “long-read”. Here are my thoughts.

It’s always exciting to find faithful portraits of what I do for a living, since it can be difficult to describe to people. The art and science of it is basically:

  1. Put an initial stake in the ground in terms of the functionality we think is going to be useful.
  2. Gather data on the usage of that functionality.
  3. Interview real people about how they are using it and how they feel about it.
  4. Revisit the functionality with the data and human insights we’ve gleaned and improve it.
  5. Repeat.


Numbers 2 & 3 above barely scratch the surface of a key tension in this work: What users do, what they want, what they think they want, and what they tell you they want are four different things. There’s some overlap, but not as much as one would hope or expect!

We need more solid, narrative descriptions of the limitations of machine learning (AI) at present. I find that non-technical people tend think machine learning can do both more and less than it currently can. The reality seems to be that in some ways our dystopian future is already upon us, but in other ways it’s further away than ever.

The article suggests a subtler point about making products that is generally overlooked: Luck and randomness are built into this process, but that doesn’t mean we shouldn’t approach it analytically.

Each person on a team like FB’s product team brings something different to the table, and each one of them has their own stuff going on that makes it harder or easier for them to hear their teammates’ views. The fact that feature development begins in such a chaotic place, but can end up with real, testable product recommendations that, once implemented, are frequently successful is amazing. It speaks to the fact that trying to do something methodically and scientifically, while never perfect, is better than the alternative.

If the Facebook employees featured in this article are a representative sample, Facebook is a very young, white, male place. That’s not entirely surprising, of course, but the fact that this cohort is setting the standard for technology of this kind globally is problematic.

Making a Thing for People to Use

WaPo’s Police Shootings Graphic

First off, it is awesome and you should go look at it right now:

I am struck in particular by their focus on individual human beings; each victim* is represented as a single figure in the timeline graphic the Post leads with:

Screenshot 2015-07-25 11.22.05

Below the original graphic space, the Post shows each victim as an individual, with details about the circumstances as well as a photo when possible. This further emphasizes the humanity of each person.

Screenshot 2015-07-25 11.47.55

That all said, I feel like some key context is left out of the graphic that just as easily could have been included, and would have made the racial aspect of these numbers manifestly more obvious.

Screenshot 2015-07-25 11.30.45

Almost twice as many white people as black people have been killed by police so far this year. This figure alone, without context, dramatically undercuts the assertion by civil rights activists that blacks are unfairly targeted and killed by police.

Had the Post included census data with those numbers, the impact would be quite different:

Screenshot 2015-07-25 11.41.56

Whites are underrepresented by a third, blacks are overrepresented by half. Only Hispanics are being “fairly” represented in these statistics.

9/23/16 Update: Turns out there was a suitable alternative out there all along! Peep The Guardian’s on-going vigil “The Counted: People killed by police in the US” which has a much better way of showing proportionality:


Thanks to BJ Warshaw for sussing it out.

* I realize how charged it is to use this word, but the police involved in these events might also be termed victims; when deadly force is used, everyone loses.

WaPo’s Police Shootings Graphic

Same App, Different Experience

Why oh why, Twitter? You control both and, yet each has a completely different workflow for adding a handle to a list!


Add-to-list on Twitter


Add-to-list on Tweetdeck

But it’s not just that there are two different workflows; it’s that they are similar enough for me to constantly confuse them! Here’s what my brain sees each time I’m presented with one of these dialogs:

Twitter Lists (Brain View)

…which is perfect if I’m inside Tweetdeck (the second image above). But if I’m on, I’m suddenly (and confusingly) inside of the “Make a new list” workflow:

Create-new-list on TwitterWhat happens when I click out of that? Will I have a new “untitled” list? What happened to my original selections from the previous screen? I basically have to click ‘x’ and start over to find out.

So I ask you, Twitter: Why settle for this cludgy and confusing experience when you already have a usable experience in Tweetdeck?

Same App, Different Experience

Why I went back to one monitor

While the idea that more desktop real estate means higher productivity seems sound, in practice I found it mostly just invited distraction.

The fact is, I can only look at one monitor at a time, so whether I’m turning my head or using a keyboard shortcut, I’m not ever going to be able to see code and output simultaneously without putting those two windows on the same monitor.

So more often than not I just used the extra monitor to keep email or social media open constantly, inviting those things to distract me or, worse, trigger a stress response via peripheral vision.

In short: Mo monitors, mo problems.

Why I went back to one monitor

Help me find the flaw in this authentication paradigm

Recently, I tweeted this:

It prompted a discussion with my super-colleague, Mark, about why no one has implemented that as an authentication process yet. Consider a process like this (I’ve bolded steps that the user would actually see):

  1. User enters email address, clicks LOGIN.
  2. User is prompted to close their browser tab or window, then go check their email.
  3. Cookie is set on user’s browser.
  4. User clicks time-sensitive, encrypted link in the email which opens a new tab or window.
  5. Cookie and link are required to actually be logged in.
  6. User is logged in.
  7. Server is flushed and encryption algorithm changes.

Four steps.  No passwords.

So, what is the flaw in this process? How is it not both as quick and as safe, if not safer, than the existing authentication paradigm of creating a new password every time you go through the forgot password flow?

Just to be thorough:

  • What if I type in the wrong email address? That would send an email to an account you don’t have access to and would thus prevent you from signing in as that account-holder.
  • What if my email gets hacked? First of all, the links in these emails are active for a brief window of time, say 30 minutes at the very most.  Second, if your email has been hacked you are already screwed because the hacker can reset your password to every account in the current paradigm anyway.
  • What if your server gets hacked? Again, the generated url is valid for a very short time and is then completely erased from the server.  Also, logging in requires not just that url, but also the presence of a cookie on the same machine.  Further, the algorithm changes constantly. Thus, it would have to be an inside job performed in under a minute, just to gain access to a single login. Not a very economical way to make a living.

Help me find the flaw in this because, for the life of me, I can’t figure out why every website doesn’t already work this way, saving us all from the utter farce of passwords.

3/4/2013 Update:

Thanks to @andystalick for pointing out the post I had been searching for before writing this one: Is it time for password-less login? Its follow-up is also essential: More on password-less login.

And more on why we need SOMETHING other than the current password system: 30 years of failure: the username/password combination

Help me find the flaw in this authentication paradigm