Project OMEGA: Technical Research

February 12, 2012

Password Close-up

Although Project OMEGA was far less technically challenging than past projects (the “technology” was already put in place for us), that didn’t stop me from incorporating some slightly more complex elements into the mix. While we were planning out the types of riddles and clues that would be scattered throughout the experience, I noticed we had gotten a bit “lock box-heavy.” In fact, we included three different types of locks (and corresponding boxes) in the final experience – a classic combination lock, a single-digit number lock, and a key. Eager to introduce a bit more detail and complexity to the piece, I suggested that we include a password-protected web interface of some kind.

Although I’ve been doing web design as a job and hobby on numerous fronts for several years, my expertise hasn’t gone much further than front-end development. Things like password fields don’t necessarily scare me, but getting them to actually work is a whole other story. Despite this tiny bump, I assumed the process would only require a bit of Javascript that was easily Google-able.


Above: Just a few lines of Javascript was enough to get the password field working with an actual password.

Our password was hard-coded for this experience (Dr. Valentine’s daughter’s names, “clarice”). It turns out that this method isn’t the most secure in the world (or at all), but for our purposes it worked beautifully.

During my testing, I noticed that if the user entered a password incorrectly, they had to manually click inside the form to begin typing again. Since the only function of this page was to type in a password, I took it upon myself to make the experience that much smoother by making the form auto-focus when the page loads. With a bit of research, I found that this was easily doable with another short line of Javascript (as you can see above, “window.onload = formfocus”).

Now, what if the user capitalizes the first letter of the password (following traditional grammar conventions, someone would typically type “Clarice” rather than “clarice”)? To combat this, I wrote a little note beneath the form that indicates lower-case characters are only accepted.

The rest of the process was simple. Building the site took no more than a couple of hours, including time for mocking up the design and implementing it.

Bio Page

Of course, once the password is entered the site needed to go somewhere. This process was technically simple, though figuring out the best kind of clue to stick into the next page took some thinking. Since the interface was being masked as a company employee portal, I first decided it would make sense to have an employee bio appear.

From there, the clue practically wrote itself – I wrote Jill Valentine a bio, and then highlighted certain characters to spell out the clue. Though this approach is a little bit “in your face,” I decided that from a user experience point of view, the participants would already be working quite hard at coordinating each other and clues shouldn’t be intensely cryptic. Luckily during the final run-through of the experience, the participants made the connection with these letters almost instantly and spelled out the next clue: “the key is in the office above the door.”

You can still see this fictional employee portal hosted on my site here.