web_based

Another project of mine went live today:

Playground: The Cache at Union Creek. This was a pilot .NET project for us, and I was the lead interface developer on the project (actually, I was the only iDev on the project, so I'm claiming lead by default). The design and Flash work were done by Matt, and I stitched it all together using standards-compliant XHTML, CSS, and JavaScript. There is not a table on the entire site, not even on the Get In On The Secret page. It's not a particularly big project, but because it was a pilot project it took some extra time and effort. Matt definitely bore the brunt of the content and programming with the requirements for the Flash modules, and there's still more to come for later versions of the project.

Next up: National CineMedia. I already have a fantastic design in my hands and I'm doing it all in CSS-based layout. I'm going to try using sIFR to keep things pretty and accessible, so that'll be a fun challenge. This is also a .NET project, with much heavier backend programming (we're on Version 7 of the backend wireframes already). Projected launch is mid-March. 

 Today marks the launch of the project I've been devoting most of my time to:

http://soloquote.rmhp.org/home

This tool enables you to compare health insurance plans, get a quote, and apply for coverage. The tool takes all of the necessary information for determination of elegibility, and even allows you to log in later and return to an unfinished application, or see the status of your application. (It's safe to play with up until the "Yes, Apply Now" button on the Confirm Plan Information page, if you want to see the first few screens. There's about eighteen more pages after that.)

On this project I was responsible for implementing the User Interface. I did not have a hand in the design or the information architecture. I tried desperately to make it as usable and accessible as possible within the constraints of a pre-existing design.

During the QA process I must have squashed on the order of 150 bugs...almost half of the bugs reported for the entire project. (There's a long story behind that, which basically can be summed up as me coming on board the project as a johnny-come-lately. If I'd been involved from the start, there wouldn't have been nearly so many bugs.)

Passwords are...well, let's just say they're a pain in the ass. They are a fine example of the Usability vs. Security dicotomy, where the more usable things are the less secure they are, and the more secure they are, the harder they are to use. In the case of passwords, passwords that are easy to remember are typically forbidden, as are standard methods for remembering random passwords (such as writing them down). It's almost a Catch-22 situation.

In the past while, several people on my watchlists have been ranting about passwords, so I figured it would be a good idea to explain how it is possible to have passwords that are secure, re-usable, and easy to remember.

It's actually fairly easy to make a strong password that is easy to remember. The trick is to use two facts about human cognition:

• Systems are easy to remember
• Phrases are easy to remember

So what you have to do is have a simple system that can take any phrase and make a strong password out of it. Now, yes, you are technically remembering much more this way than just a set of characters. But you'll remember it longer and more accurately, and as a side benefit you can design the system so that the passwords it generates are re-useable (so when your bank website starts pestering you to change your password, you can change the existing password rather than making a new one).

Here's an example of a good system:

1. Pick a phrase that has between five and ten words in it. (We'll call this the "passphrase.") It should be something that you can easily remember: a favorite saying, a quote from a song, a line from a movie, etc.
2. Strip out all punctuation from the passphrase, and put all letters in lowercase.
3. Take the first letter of each word and place them together.
4. In the middle of the resulting set of characters, place the number 1.
5. At the end of the resulting set of characters, place the number 9.
6. Replace one or two of the characters with punctuation that is visually similar, e.g. $ for the letter "s" or + for the letter "t" or 0 for the letter "o."
7. To re-use the password, increment the digit in the middle by 1, and decrement the digit at the end by 1.

For an example:

1. Open the pod bay doors please, Hal.
2. open the pod bay doors please hal
3. otpbdph
4. otp1bdph
5. otp1bdph9
6. 0+p1bdph9
7. 0+p2bdph8, 0+p3bdph7, etc.

These may not look like "easy to remember" passwords. But you're not going to be memorizing the generated passwords, you're going to be memorizing the system and passphrase that generated them. In the example, you'd be remembering, "My password is the first letters from each of the words in 'open the pod bay doors please hal' with a 1 in the middle and a 9 at the end, except anywhere there is an o I'll substitute 0 and anywhere there's a t I'll substitute +." Again, yes, that's a lot more to recall than just a string of ten random characters, but because it is a system it is easier to remember, and you'll remember it more accurately.

You can customize the system, of course. Step 6 may be non-intuitive for some people, so you could replace it with a step that alters capitalization ("every other letter") or punctuation ("place an underscore after the second character"). Just keep the number of steps in the system to seven or fewer so that it is easy to remember. Avoid making steps that will create passwords containing disallowed characters, which are typically quotation marks (single, double, or back), slashes (of any direction), spaces, and metacharacters (like function keys or control combinations).

Once you have set up a system like this, you should record it somewhere and keep it safe, just for future reference. You still should not write down your passphrase anywhere, but chances are you won't need to.