Slackers

This article had me rolling this morning:

The Seven Habits of Highly Effective Slackers

Does anyone else feel called out?

Buttons in Physical and Virtual Environments

While using the self-service postage machine at the Post Office today, I noticed what appeared to be a pretty high latency between when I punched a button on the keypad (a real keypad, not touchscreen) and when my action was acknowledged and processed. The feedback came in the form of a "chck" sound, much like an old typewriter.

Eventually, I realized that the "latency" was due to the fact that button presses were not registered until my finger came up, as opposed to when the key was depressed. The system was behaving exactly how it was designed, but it presented a false sense of latency and sluggishness.

Why?

Event handling on the automated postage machine was that of a virtual button, where click events are not fired until the button is released (think: onmouseup). Conversely, a physical button's click event is fired when it's pressed (think: onmousedown). Don't believe me? Open up TextEdit/Notepad and press a key on your keyboard. Imagine if the keypress didn't register until the button popped up; wouldn't that be annoying as hell?

Here's an example. The following button uses the virtual button event paradigm:



Notice how you can move the mouse off of the button before it pops back up, and the event is cancelled.

This button uses the physical button event paradigm:



Kind of annoying, huh?

Using the physical paradigm in a virtual environment doesn't give the user a way to change their mind. Using the virtual paradigm in a physical environment adds the effect of latency.

Why do I think about stuff like this? I'm weird, I guess.

Building Better Mockups

A mockup or simple prototype is the first chance stakeholders have to get a grasp of a designer's vision. First impressions are everything, so you wanna do this right.

Here are some tips I've learned (the hard way) over the years:

1. JavaScript is your friend.

As a designer, half of your job is to convey an Experience. Don't be afraid to spice up your work with interactivity; leverage a framework such as Prototype, Script.aculo.us, or jQuery. If your design involves an expanding or collapsing component, then hard-code the animation. If your design involves an AJAX call, "fake" the call by displaying a spinner for 2 seconds.

A modern mockup should involve HTML, Images, JavaScript and CSS.

2. Widgets Suck.

When writing fake copy text, avoid the term "Widgets" like the plague. Everybody has, sells or needs widgets. I suggest using Cats or Weasels.

3. It's OK to write imperfect code.

The mockups I build typically work in only one browser. The lifespan of a set of mockups is so short that you don't need to stress about too many inline styles, HTML tables, un-namespaced JavaScript functions, etc.

And, you know those custom CSS directives, like -moz-border-radius? Use'em!

The goal of a mockup is simply to convey a design and degree of usability; the code driving it will be scrapped and rewritten when the project begins.

4. Copy Text is more important than you think.

What's wrong with "[ blah blah copy text here blah blah ]"?

The answer is two-fold. One, it fails to convey a level of usability. If copy text is required in order for the user to understand how the page works, this forces your design reviewers to conceptualize what that copy text should say before they can accurately review your design.

Second, and more importantly, mistakes happen. Sometimes placeholder copy is unknowingly pushed to production without being rewritten. This makes your company look like amateurs. Amateurs, dude.

Ultimately, you want your stakeholders to understand your design as fast as possible. Fake or unclear copy text inhibits this process.

5. Jettison your ego.

It's inevitable that people will disagree with you; you're not a Design Princess. Know when to take criticism with a grain of salt, and know when to listen and react.

And above all, be able to rationally justify your ideas.