matthew ephraim

Archive for the ‘usability’ Category

Usability, Browsability and…Sniffability?

Monday, May 3rd, 2010

As any cat owner (or roommate of a cat owner) knows, there are times when a scented candle becomes a crucial component of maintaining one’s own sanity. Recently, when posed with a situation in which I found myself lacking the proper oder masking equipment, I took a stroll over to my local big box retailer and made my way to the home and garden section. There I began my search for perfect flame activated cat stink deterrent.

Now, anyone who’s ever tried to choose a winner among a wide variety of competing scents knows that there’s really only one way to figure how a particular candle matches up with your own scent preferences. You pick it up. And you smell it. Unfotunately (as you will see below), with many candles this obvious scent comparision technique is difficult, if not impossible. Clearly, the companies who make the candles that are most difficult to smell are indifferent to or ignorant of how their target audience actually browses their products.

Perhaps it seems a little silly to analyze the usability (and sniffability) of scented candles. After all, candles come cheap. If you buy the wrong one, you can just buy another one next time. However, I would argue that a few simple packaging changes can make all the difference in the world when it comes to making a candle easy to smell.

And with that, I’d like to show you a few examples of what I found during my candle adventures.

First, the Good

The companies that make these first 3 candles clearly get it. The packaging is easy to open without breaking and one candle brand even includes holes to allow sniffing without opening the packaging. This is how candle packaging should be designed.

A good candle A good candle A good candle

Now, the Bad

I’m not a candle expert, so I can’t tell you why so many candles come in glass jars. What I can tell you is that glass jars that aren’t easy to open make for a bad candle browsing experience. Not the worst candle browsing experience, mind you. That experience is reserved for the candles below.

Some bad candles

And finally, the Ugly

Two types of candles, and two types of impossible to preview packaging. Let’s hope the description on the package is vivid enough to evoke an accurate scent in the consumer’s mind. Otherwise, you’re really rolling the dice when you choose to buy a candle that you can’t actually smell.

An ugly candle Some ugly candles

User experience is a hot topic in the world of web design right now. And usability certainly is key to making a good website. However, a good user experience is vital everywhere. Even when it comes to things as trivial as candle shopping. I’d like to think that the candle makers who took the time to truly consider how their customers would seek out their products will be rewarded with success.

And yes, I bought one of the easier to sniff candles.

Windows Contextual Menus Are Inconsistent

Tuesday, May 20th, 2008

One of the many little things that annoys me about Windows is the inconsistency of where items are placed in contextual menus. Case in point: the menu that pops up when you right click on a taskbar item or window. I haven’t done a scientific study, but I’m going to guess that 80% of the time or more the last item in this particular contextual menu is the option to close the window that is being right clicked on. This is what the majority of the contextual menus look like:

Having it as the last item makes sense. It’s probably the most commonly used menu item and it’s an easy target when it’s the last item in the list. The problem is: because that item is listed as the last item over 80% of the time, I start to expect that it’s always going to be the last item in the list. Unfortunately, that’s not always the case.

For whatever reason, some applications list other options below the Close option. Here’s an example of the right click menu for a cmd.exe window:

When I want to close that window, I right click on the cmd.exe item in the taskbar and choose the last item that pops up. But it’s not going to close the window. Instead it’s going to bring up the properties dialog for the cmd.exe window. Now, not only do I need to close 2 windows instead of 1, I also need to always remember that cmd.exe breaks the convention and lists Close as the 4th item up from the bottom of the menu.

Here’s another example:

That’s the right click menu for SQL Server Enterprise Manager. It’s outdated now, but it used to be the main tool for dealing with SQL Server databases. Like cmd.exe, this application also lists an item below Close in the contextual menu. What’s even more annoying in this case is that the item listed below Close is Help Topics. It’s another option that I will accidentally click on instead of the option I wanted, but, this time, choosing the wrong item will start up another application. And, no matter what computer I’m working on, the help application always seems to take a painfully long amount of time to open up.

Now, I would be able to excuse all of this if it was just 3rd party developers who weren’t following the conventions set up by other Windows applications. The problem is: cmd.exe is a integral part of Windows and Enterprise Manager was Microsoft’s official application for SQL Server Databases. So it’s Microsoft that’s disregarding an informal convention and randomly placing items below the Close option. I can only hope that Microsoft plans on dealing with this problem with Windows 7.

JavaScript Mouse Tracker

Saturday, October 20th, 2007

A while ago, I was thinking about software programs like Camtasia that allow you capture a user’s activity as they work on a computer. Screen capturing programs are useful for usability studies because they allow you play back a user’s activity later on when you are evaluating their performance on a set of tasks. I started to wonder if their were any options for capturing a user’s activity remotely through the browser. When I didn’t find anything I thought was compelling, I decided to try writing my own.

What I came up with was a JavaScript class I called MouseMovie that could be used to record the mouse movements a user made while on a page. The first draft is pretty rough, but it will allow you to create a new mouse tracker, start tracking the mouse movements a user makes on a page and then stop the tracker. Once data has been captured by the tacker, you can use the mouse timeline to replay the user’s movements or trace the path of the user’s movements.

JavaScript
/* Create a new tracker, 
start it and stop it and then use 
the timeline to animate 
and trace the mouse path. */
var MyTracker = new MouseMovie.Tracker(); 
MyTracker.start(); 
MyTracker.stop(); 
MouseMovie.Animate({TimeLine : MyTracker.TimeLine});
MouseMovie.Trace(MyTracker.TimeLine);

Currently, there is no way to persist the user’s movements to a file or database, but I’d like to make it possible to store the movements and play them back at another time. A simple demo of the mouse tracker can be found here