So the combination is... one, two, three, four, five?

SplashData recently released a list of the most commonly used passwords on the Internet. (Based on published lists of stolen passwords.)

(Geek challenge! Name the movie and the TV show that are the source of two of the passwords on the list.)

So, in the interests of doing my part to halt the usage of easily hacked passwords, I thought I would share my password system. And some links, if you want to try it, too.

The tools you'll need:

• KeePass
  
• Dropbox
  
• Optional: Google Chrome
  

KeePass is the key (ahem) of the whole system. This open source password manager fits my needs perfectly, as it works in Windows, Linux, and Android. (Also Mac and iOS.)

KeePass in action.
KeePass will generate random passwords, includes keyboard shortcuts to copy passwords (and then clear the clipboard after a set amount of time), and stores everything in an encrypted file using one- or two- factor authentication. Whenever I create an account on a website, I fire up KeePass and generate a random password for it. (Sample password: Egz0B2GC4pZf2u5VBVYi)

So now I've got an encrypted file, accessible only via the KeePass application using my master password (and/or a keyfile). But I want to access that file from anywhere! Enter ... the Dropbox.

It's a box. For dropping.

Dropbox has added some policy updates of late that have made me a little nervous, but I'm still OK using their service to store encrypted data. Simply place your encrypted file in your free Dropbox folder, and now you can access it from any computer, phone, tablet, or computerized llama you use. (Note: Dropbox may not yet be compatible with computerized llamas.)

Finally, for the lazy (like myself), Google Chrome can help with your all new fully random and completely nonsensical passwords. (You know, the ones you'll never, ever remember.) Chrome will remember passwords just like most modern browsers, but, in a twist, will also let you sync that data across all your Chrome installations.

Score! Your information is encrypted on Google's servers, too!

Before and after time! Before, I was using one or two passwords on every site. And frequently the same username. These passwords, while not dictionary words, were also not the most secure. I did this primarily because 1) I needed passwords I could remember because 2) writing them down is a Pretty Bad Idea^TM.

Now, every account I have has a different password (though usually still the same username), but I only have to remember two - my KeePass file's master password and my Dropbox password. The second is not strictly necessary, unless you ever want to access your password file from a computer that is not your own. (Bonus protip: throw the KeePass installer in there, too. It's small.)

Yes, using a password store takes just a little more time and effort, but, with the number of security leaks in the news, and the lists of accounts available in the seedier parts of the Internet, it may well be worth it to keep your accounts secure. Added comedy trope bonus: tell people your password is so secure, you don't even know it.

Usability Testing in the Wild

When you test your product (software or otherwise), you should perform a usability test with people who share some characteristics with your user base. For example, when testing your new website, this characteristic can be "people who use computers". But you may have a particular feature that is very specific. In this case, you should probably test with a more representative group.

For example, your ATM design may include aids for the visually impaired. Your test group, then, should probably include at least one person who is, in fact, blind. This will help to avoid situations where it takes an actual user almost five minutes just to find a headphone jack. And posting a video of it on Youtube.

Ferret What Now!?

There are a thousand million different ways to make your website mockable. The very least you can do is make sure that your domain name isn't one of them. Remember that URLs are case insensitive. Also remember that while parsing words with no spaces, people mentally insert spaces between easily recognized words first. Try it yourself. Here are two examples.

• kidsexchange
• ferrethandjobs

If you're snickering right now, the very nice people at Kids Exchange and Ferreth & Jobs may take issue. I humbly request that you add the following Rule Zero to your website deployment checklist.

Print your domain name in all lowercase using a console font. Show it to five random people. (When using surnames as domain names, these people should not be relatives.) If three laugh, consider changing it.

The $300 Million Button

Someone asked me recently how to justify the expense of a usability test to those people who would need convincing. Stories like this one should help with that.

In Which Someone Else Makes a Really Good Point

Engineer Thinking, by Matt Legend Gemmell, is so full of good things that I really want to re-quote the whole thing. But I won't. Here's the penultimate paragraph that makes the broad point:

If you’ve exposed underling complexity or unnecessary choice in your software because you see those things as inevitable, it’s because your job isn’t finished. If you’re going to write GUI software for other people to use, do it properly, and treat those people like human beings instead of software engineers. If you want to expose complexity to the user and wash your hands of it, write command-line tools – or utilities that are used exclusively by other machine processes.

Push the button, Frank!

One thing that some interface designers sometimes overlook is button text. In a lot of contexts, buttons are given default values that seem "good enough". But consider your button text carefully. I'll give you the negative example that spawned this very thought process.

I'm installing a program with the standard Windows installer dialogs. There is some setup to do, and when it is finished, I'm presented with a screen that informs that everything is kosher and the install can commence. The default button that will kick everything off reads "Finish". Erroneous! I'm finishing nothing! Adding to surreal nature of the dialog is the descriptive sentence above the button: "Click Finish to begin installation."

"Click finish to begin" is going to be my new "get up to get down".

Verbs are good words for buttons. Buttons do things, and the word should describe what's going to happen. "Submit" is a popular, though vague, button word. "Cancel" is another popular one. In my example, the answer was staring the programmer right in the face when he wrote the description: the word should have been "Install", since that's exactly what's going to happen when the user clicks the button.

Give some thought to your button labels and make their purpose clear. If whatever IDE you're using provides defaults ... well, try to make it not to. Forcing yourself to fill in that text won't be a bad thing.

Order Up!

A quick note on form elements and tab ordering: if you are going to include links inside the form to provide more information on what a field is doing, you MUST unequivocally and without question, absolutely with no exceptions, positively set the tab ordering on your form so that those links are not included in the ever-popular keyboard shortcut of tabbing to the next item in the form.

Breaking the flow of "enter data - tab - enter data - tab" by highlighting help text interrupts the user's expectations, possibly to such an extent that said user will stop mid-form to write about it on his blog!