moved!

My blog has officially moved. Please join me over at http://jbshep.wordpress.com/. People with RSS aggregators should point to the new feed.

The family blog will remain here on blogger/blogspot.

This blog's content will remain here on blogger/blogspot as well. Who knows, I may be back!

pondering a move to wordpress.com

I've started a new blog on WordPress and am pondering a permanent move. I really like WordPress and its capabilities so far. Anyone have any experiences with WordPress they'd like to share?

If I do decide on a permanent move, I'll be sure to post a "farewell" along with the new blog feed (for those of you who use a blog reader).

guidelines for transitions (a.k.a. animated effects)

Bill Scott offers an interesting discussion on animated effects (or as he calls them, transitions). I first became interested in using animation when I was researching the visualization of dynamic networks. One of my favorite examples of animation in a UI comes from GnuTellaVision, a project of some students at Berkeley (Ka-Ping Yee was one of them). GnuTellaVision used animation to help the user orient herself as the network gained and lost nodes.

Anyway, in Bill Scott's blog post he offers an interesting write-up on how the brain processes movement. He also offers guidelines for using animation in user interfaces. I've reposted those guidelines here for safe-keeping. :-)

Guidelines for Transition Effects
From the discussion above we can extract some general principles for transitional effects.

1) The more rapid the change the more important the event.
2) Rapid movement is seen as more important than rapid color change.
3) Movement toward the user is seen as more important than movement away from the user.
4) Very slow change can be processed without disrupting the user's attention.
5) Movement can be used to communicate where an object's new home is. By seeing the object moving from one place to another we understand where it went and therefore will be able to locate the object in the future.
6) Transitions should normally be reflexive. If an object moved and collapsed to a new spot, you should be able to open it and see it open up with the reverse transition. If you delete an object and it fades, then if you create an object it should fade into place. This creates a concept of symmetry of action.

-- courtesy of Bill Scott

mi-3

Warning... beyond here be spoilers, ye maties!

I just saw Mission Impossible 3 tonight. I haven't been out of the house much since the twins were born (8 months ago already) so just getting to see a movie was nice. The movie was decent--probably better than MI-2. It seemed predictable, but maybe I've just seen too many espionage/spy films in recent history. Sometimes I think the genre has become too obsessed with plot twists, and all too often the plot twist involves the hero's boss being the bad guy.

The action and gadgetry in the movie was especially entertaining, but the best humor came not from the movie but from the people with whom I went. In the movie, there's a scene where Ethan Hunt (Tom Cruise's character) is trying to call out on his cell phone in Shanghai but can't seem to get a signal. My friend Matt leans over to me and says, "You can get a signal in a basement or an elevator in Shanghai. This is the most improbable part of this movie." (It's probably important to note that Matt lived and worked in Singapore and has traveled through much of the Far East.)

free klm calculator

I need to download and try this free Keystroke-level Model (KLM) calculator.

blogging chi2006

No, I won't be blogging on CHI2006 because I'm not there, but for those of you who couldn't make it this year (like ME!) you can follow along with these blog sites:

The Official CHI2006 blog
The UNofficial CHI2006 blog

Thanks to Rashmi Sinha for the pointers!

Update, 26-Apr-2006: The student volunteers' blog for CHI 2006 is probably the most interesting of all.

javascript kung fu

We've formed a user experience (UX) team at my client site. We're employing an iterative design process that involves a lot of prototyping, both low-fi and high-fi. In doing high-fi prototypes, I've found several new JavaScript libraries to be invaluable.

Yahoo! User Interface Library
Offers support for animation, connection management (AJAX), DOM traversal, Drag'n'Drop, and event management. The event management is really nice. If you try to attach an event handler to an element before the page is finished loading, the YUI Event API will store off the handler and defer its assignment until the page load is complete. Cool! The Drag'n'Drop API is also particularly awesome. I'm using it in one of my prototypes to create draggable content boxes (not unlikely Google's personalized home page).

JQuery
Some people use JQuery for its animation capabilities (pop-down/slide-down effects and transitions), but I use it more for its DOM traversal capabilities. JQuery allows you to select elements using syntaxes that resemble CSS selectors and XPath (yes, XPath!). For example, if you're looking for the child of a node 'A' that has a class called 'X', you'd normally have to get an element reference to the node and then iterate through its children using a for loop. With JQuery, this could be written more tersely as:

$("#A").find(".X")

This returns a list of all the elements that match. To grab the first, you'd just invoke .get(0).


I've started playing around with script.aculo.us, moo.fx, and Prototype too. We'll see what treasures those yield.

Side note: Anyone know if there's any documentation on Prototype? I haven't seen any.

stop indicting your users

A couple of weeks ago, I had trouble accessing a system I needed in order to do my work. Unable to resolve the problem, I submitted a support request to the company's support request database where it was fielded by a "Web team" engineer. It turns out that the URL I tried to use was wrong. "Strange," I thought, especially since I found the URL directly from the Web team's online documentation. It turns out they kept some of their documentation updated (the documentation that was less visible on their site) but not other documentation (the documentation for this specific system). Granted, it is not uncommon for documentation to deteriorate in an IT setting. It was a simple, easily correctable mistake (which they still haven't corrected, by the way).

Now for the funny/disturbing part. I glanced at my support request the other day. The Web team engineer had closed the support request with the diagnosis "USER ERROR." Excuse me? I had followed their documentation to a "T"--at least the documentation that was visible for the task I was doing.

The problem lies in how younger IT professionals are "programmed" by their peers to regard users as "stupid" and usually the root of the problem in any support call situation. This myopic view propagates from one generation of professionals to the next. So, how can we combat this view? I would suggest educating professionals early on in their careers (while they're still being educated/trained) with themes central to HCI and usability. When desiging an interface, maintaining a system, etc., one must remember that users perform tasks to meet goals using their knowledge in a given context. If each of these are not considered (users, tasks, goals, knowledge, and context), the interface or system will fail and it will be the fault of the IT professional, not the user.

Stop indicting. Start serving.