Skip directly to content
Bite-sized thoughts about the web and the people who use it.
April 10, 2014

It's not often that you see the words "Don't Optimize Performance" in a sentence on a web developer's blog, but alas, here they are.

Let me be clear. I like fast-loading websites and snappy smartphone apps. I like using Google Chrome, Sublime Text, and Dropbox because they are faster than Safari, PHPStorm, and swapping out flash drives.

But if you are performance-tuning your website before you even know how slow it is, then you're making a mistake.

It feels good to improve performance because it's discrete and measurable. Shaving milliseconds off a page load can be addicting. But most of us aren't in the business of optimizing page loads… we are trying to optimize an entire web experience, of which performance is only a tiny part.

Yes. People don't like slow websites, but has anybody actually mentioned that your website is slow? Every minute you spend building image sprites, minifying Javascript, and tuning for-loops is time you could be spending on issues that users are actually complaining about, or features they are clamoring for.

Your performance tweaks may fulfill your personal desire to express cleverness or scratch a mental itch, but wasting your client's time and money solving a problem that doesn't exist yet is nothing to be proud of.

When your users are noticing slowness, then yes, of course, fix it. Solve their problem immediately!

Because solving users problems is the business you're actually in.

April 02, 2014

As a web developer, my education has been strongly influenced by information that was freely shared and published online by those who came before me. I read Mark Pilgram's Dive into HTML 5, Jonathon Snooks SMACSS, and Why's Poignant Guide to Ruby. Each of these books was written by a developer, and in the spirit of open source, they were published online so everyone in the community could benefit. I thought it was noble and generous, and I wasn't alone. Thousands read these books and the developers went on to become leaders in their respective communities.

Anyone could publish a book like this (indeed, several of you have), but the barriers are formidable. Instead of just writing the book (which is challenging enough), you'd also have to build the website, do you own design work, get hosting, and provide ongoing maintenance. If you want any special functionality, like the ability to download it in various formats, or support for translated versions, you'd be on your own to build and maintain the tooling to do that.

Enter Bitbooks

I'm currently working on a project called Bitbooks, which aims to make that whole process easier. Bitbooks will be a service that allows developers of any experience level to write and publish a copy of their book online.

How it works

If you've ever used Github pages, then you already know how it works.

You write your book in Markdown, put the files on Github, and point Bitbooks at your repo. Bitbooks will then read the files and use them to build a tastefully designed website -- an online version of your book. This site is pushed to Github pages, which provides free hosting and the ability to use your own domain name. If any updates are made to your content repository, Bitbooks will update your site on Github pages automatically. This lets you make updates or accept changes via pull requests without having to worry about constantly updating your site.

Like Github pages, Bitbooks will provide you with a choice of themes you can use. Here's an early look at what I have in the works:

Glide Theme

Epsilon Theme

Epsilon Theme

Hamilton Theme

Of course, all themes will be fully responsive.

Responsive Themes

From a feature perspective, I'm heavily influenced by what I consider to be the best implementation of an online book: Scott Chacon's Pro Git. Everything about it, from its SEO awareness to its support for downloads in multiple formats are examples to me of what a well implemented build could produce for you.

Why it works

If you're a technical author, then Github is the ideal place for your book, because that's where your audience is. Just look at Getify's You Don't Know JS or Addy Osmani's Developing Backbone.js Applications. Putting their book content on Github lets them write iteratively, get feedback, and collaborate with others. They can go straight to the community instead of working to persuade the community to come to them.

Everything about this authoring process is designed to put you in control. You don't need to create another login or put your stuff in another walled garden. Your content is yours. Your site is yours. If you wanted to use Bitbooks to generate living documentation for your open source project, you could do it. If you wanted your community to collaborate on a written collection of best practices, you could do it. If you want to write fiction you could do it. It's all up to you.

The Open Source Way

This project is founded on the principle that open source makes everything better. Books like Pro Git, and PHP the Right Way have such a wide impact because they give away information freely, opening up the content and source code for anybody to use and share. Paradoxically, the physical versions of these books continue to sell very well.

So, in the spirit of open source, I'll be releasing the static site framework that runs Bitbooks as an open source project called "Franklin."

If Octopress is a static site framework, optimized for blogs, then Franklin will be a static site framework optimized for books. I'll have more details coming soon, so subscribe here if you want to stay in the loop.


I don't believe in The Big Reveal, and that's why I'm talking about this now, while the project is in the building phase. After a couple months of weekend work, I think I'm about 60-70% of the way to an alpha launch. The first round of sites will be made by invitation only, so tell me if you want to participate (and if you do, I will hook you up).

If you're still reading then you probably have some interest in a project like this, so in closing, I have a favor to ask of you: Tell me what you think

Would you use something like this? Is it missing something? Shoot me an email, and help me know if I'm on the right track. You could also tweet at me or leave comments below. However you do it, just say what you're thinking. The more good feedback I get on where this ought to go, the better it will turn out.

And with that, I'll get back to work. With the right tools in place, I believe we can kick off a whole new series of great books and documentation to the benefit of our various technical communities. Let's build something cool, together.

March 31, 2014

I was using an email service for some work I was doing, and I hated it.

The service worked alright. At least, it got the job done. But even as a technical person, I was frustrated by its password policy, which required:

  • A minimum of 12 characters
  • A combination of uppercase & lowercase letters, numbers, and symbols
  • Not reusing any of the last 24 passwords
  • An automatic password reset every 2 weeks
  • Logging in from a specific network with whitelisted IP addresses

If my credentials were incorrect, it didn't specify which part was wrong. I couldn't access it from home, and I couldn't log in from any devices, since this network wasn't WiFi accessible. Too many incorrect guesses and I'd get locked out of my account. If I do something else for 15 minutes then I'm logged out automatically. If I forget my password, I have to get it reset.

Usability problems become security problems

Was the site secure?


Well, maybe it was secure from a business perspective (read: no lawsuits) but it wasn't holistically secure. With such an inhumane password policy, people in this organization were writing down their credentials on a "Passwords" paper in their desk drawer. That's not secure, and when you strong-arm them into that kind of behavior, it's not your user's fault. It's yours.

Who carries the burden of security?

Every once and a while, us technical people laugh and scoff at the average user, who doesn't have the "common sense" to create a secure password, or doesn't know how to securely manage the 20+ usernames & passwords they inevitably use. We send tweets like...

"Top 25 most common passwords chosen by idiot users. LOLOLOOLOLOLOL!!! -"

...and we have a collective laugh at those among us who can't keep up with the times. And we're totally backwards.

Because we've forgotten that it is not the user's job to make sure your web application is secure. It's your job. By passing the security burden onto your users, you're making your life easier at their expense. How secure their account is, is none of their business.

Let me repeat that again: How secure their account is, is none of their business.

That may seem like a radical notion, but look at your business card. It says something like "Web Developer," or "Application Architect" right? What do theirs say? "Truck Driver." "Tax Accountant."  "Student." "Mom."

It's not Mom's job to make sure her telephone wires aren't being tapped, or her self storage unit is safe, or her mail isn't being intercepted. That's just expected. How did we get to a place where the security of her account depends on the password that she, a non-security professional, chooses? It's like asking automobile owners to cut their own keys. We've designed a "weakest link" in our security methodology by making it depend on user training. From a usability perspective, that's never been acceptable.

If your sales department only went halfway and expected their customers to meet them in the middle, it would be a disaster. Likewise with customer support, or manufacturing. The rest of the business goes all the way, and meets the customer on their terms. Security has the same imperative.

The usual suspects

You are, likely, familiar with the online security techniques that are common today. Security is usually achieved through layers of protection erected at each potential vulnerability. Some of these layers, however, have a particularly severe impact on the user's experience (which, again, is not ok). Here are some of the worst offenders:

Most people know that CAPTCHA's are evil, but they are still being used all over the place.

Aggressive password policies
The more aggressive they are, the more frustrating they are

Secret questions
Examples include: 1) "what's your Mother's Maiden Name," and 2) "what's your favorite TV show." The problem is, humans like question 1 because it's easy, and companies like question 2 because the answer is always changing. Some organizations will force you to choose from a fixed set of questions like question 2, which is especially frustrating.

2-factor authentication
This can be implemented many ways, but one example is when you enter your password, and then the service sends you a code by phone or email to finish logging in. Security conscious techies applaud the use of 2-factor authentication (probably because they know how secure it is), but the fact is, you're making the user jump through more hoops.

Your session has expired due to inactivity
This one is better than many because if there are no delays in your work, you are unaware that the clock is running. Still, nobody likes getting booted off a site over and over again when they are hopping between tasks.

A lot of these aren't surprising. We run into them all the time. But just because they are the status quo doesn't mean they are ok. Remember, usability problems become security problems.

What's the solution?

Our goal should be zero impact security. Today's techniques may not be there yet, but we are starting to see more solutions going in that direction, like the following:

Honeypot form solutions
Provides a "bait" field that is hidden for humans but not for bots. If it is filled, then the form submission is considered illegitimate.

Password input innovation
Examples include facial recognition, fingerprint, key card, voice recognition, or pattern matching. One good example of this is Microsoft's picture passwords, where a user authenticates by tracing a pattern over an image with their finger. Our brains aren't optimized to remember a meaningless jumble of letters, numbers, and symbols. The key to better passwords is making the software do the hard work so the user doesn't have to.

Smart detection
These are services that determine the likelihood of something being spam, based on a variety of factors, like time to complete form, hidden form fields, server-side spam detection, and machine learning algorithms. Some providers include Akismet, Mollom, and Keypick.

Notably, Google uses smart detection for authentication as well. I was once notified that somebody used my username and password while attempting to access my Gmail account, but they were denied because the request came from a IP address at discrete location in the middle of the night. It's similar to how credit card companies will lock your account, when they notice uncharacteristic spending. How's that for a slick and low-impact security measure?

Third-party Authentication
Buttons that say things like Login with Facebook / Login with Twitter. Not a huge leap forward, but it prevents users from creating yet another username and password, and it prevents admins from having to securely store those credentials.

Password Abstraction
Google Chrome lets you set up browser-level profiles, which means you need to log-in to your web browser. Once you're in, you can tell chrome to save and auto-input all your passwords for your various services. There are also services like 1password or Lastpass, that manage your passwords with a single master password. The problem with these solutions is that they are like novocaine for pain. They treat the symptoms (for those technical enough to implement them), while masking the underlying issues.

Universal Online Identity
The idea is to have a ubiquitous "Log in with X" that serves an independent identity across the web. The first attempt was OpenID, and some newer experiments include Mozilla Persona or WebID. Watch this space… I think it's very promising.

This isn't comprehensive because the best solutions haven't been invented yet. We need to try some crazy ideas. Revaluate our assumptions. How is there a low-impact way to secure our homes, automobiles, and checking accounts, but not for securing our growing number of online accounts? Is there a way to authenticate with Smartphones? RFID? Keyfob? What would a web authentication API look like, and how could we make integration so simple that developers will be itching to move over to it? We may not know the best path forward, but lets move forward.

Security is hard.

No doubt, keeping an web application secure is a difficult job. If that's your job, then kudos. I don't envy you.

But remember, it is your job. The current solutions won't scale, and this problem will only get worse as software continues to eat the world. User training isn't the answer. We're looking to you to agitate for the next generation of online authentication.