To me, a lot of this UI complexity stems directly from a lack of separation between the UI and business logic layers.

Proper separation

As developers, we’re accustomed to the best practices of modularity and separating the implementation from the interface. This has lead to such patterns as MVC and Interface Oriented Design. However, when it comes to designing the UI layer, these rules sometimes aren’t followed. This is why we end up with overly complex “Search” pages, offering every option under the Sun, and configuration dialogs/screens with a one-to-one relationship to settings files or some other underlying implementation detail under the guise of “letting the user decide what they want”.

Without clear UI planning, this one-to-one relationship tends to rear its ugly head more often. Take our first example of a “Search” page. In most applications, the search functionality is interacting with some sort of a database backend, most likely a SQL RDBMS. The lazy approach is to design the search form based on the format of the SQL query itself. This is how we get search forms with multiple fields, drop-down boxes and so forth – because this format translates almost directly into a SQL query; i.e. of the form WHERE col1 LIKE... AND col2 LIKE...

Just because this is easier for the developer, doesn’t mean it’s the best solution for the end user. In fact, it’s often the case that this is the exact opposite.

Thinking like a user

In general, users don’t care about the implementation of your application or how it stores data. They shouldn’t have to know about the columns of the table where the data is stored, so why make a search form that exposes this? Instead, you need to understand what your users want and how they’re most likely to use your application. This isn’t an easy task, as many have pointed out.

This is where I think most UI problems come from – a misunderstanding of what users want. This isn’t to say that these developers are dumb or careless; but just that when it comes to empathizing with their users, they often are unable to because they know their own software and have such an intimate view of it from a coder’s perspective.

Take the example of QTTabBar, a Windows Explorer extension written in .NET that adds many useful features such as tabs, etc. to the interface. It is an excellent extension and does things very well, but the options page is a complete nightmare.

There are just too many options on this one page; what do they all mean? Furthermore, there are nine more tabs, each with roughly the same number of additional options! This is far too complicated, and I’m guessing most people will never have a use for all of these options.

Of course, it’s completely unfair of me to pick on QTTabBar in this manner, considering it’s written by one guy who has chosen to give it away for free. And, as I mentioned before, it’s a very useful utility that I can wholeheartedly recommend.

A simple story

Take a simply example, where we want to search a set of items, each of which have four separate properties – name, description, URL and tags. The items are displayed on screen with all of the four properties shown. The naive way would be to provide a search form that had fields for each property and allow users to search that way.

But with this simple (albeit contrived) example, there is an obviously simpler solution. Since all of the four pieces of information about an item are shown onscreen, it would be much better just to provide a single search field whose input would be used to search all four properties, returning all items that had a match in any of the properties. From a user’s point of view, this makes sense, since they are searching through what they know they can see and interact with.

If an advanced search was needed, it could be added later, but I would only do this if I knew it was absolutely needed by users, since the simple case is likely good for >90% of your users.

There’s an interesting article out that points to the fact that every day there are 10,000 canceled installations for Firefox; this meaning that each day 10,000 people download the Firefox installer, “fire up” the *.exe and then click “Cancel”. (A further 40,000 apparently downloaded the setup file, but didn’t even make it far enough to start and then subsequently cancel the installation)

Even more interesting were the reasons why the 10,000 canceled their install. A large part of the respondents were “confused” with some part of the install process (nearly half) while most of the other half identified that they did not have the proper permissions to complete the install.

Not simple enough?

The results seem to indicate that the installation process is not as easy as it could be. However, it’s dismiss the results by saying that Firefox is already easy enough to install, because after all, how hard can it be to just click “Next” a few times? But this ignores the central problem, that is, assuming everyone is technically proficient enough to find such things routine.

For example, to a mechanic an oil change would likely be an easy five-minute operation. For someone like me, who’s rarely popped open the hood of a car, much less done anything underneath it, such a task would likely entail reading a manual (or just Googling for the answer), then carefully following the steps one-by-one; I’d be lucky to get the whole thing done within 30 minutes.

The same can be said for software installation. Something that seems routine for most developers or power users may only seem routine because we’ve dealt with it countless times, or because we’ve dealt with more daunting situations that required manual workarounds and hacks in order to get things working. One person’s routine can be another person’s out-of-this-world experience.

The value of feedback

This is why Mozilla is actively taking steps to improve the process by collecting feedback from users who canceled the installation.

Users who canceled could optionally provide the reason why they canceled, how the installation made them “feel” as well as any suggestions or comments they had. This formed the basis for the feedback results Mozilla compiled:

The fact that a significant percentage of the respondents were “confused” shows that they are some issues that the installer could make easier. The vast majority of this confusion stemmed from the fact that installer could not close an existing/running Firefox process, a step required for the installation/upgrade to proceed. This is a legitimate technical issue that can hopefully be solved.

Installation rights

The other significant factor, based on user feedback, was the lack of permissions required to install Firefox. Normally, Firefox requires administrative privileges on the machine in order to install it. This wasn’t a problem during the days of Windows XP, when users by default had these rights, but with the advent of Windows Vista this is no longer the case. Instead, users will typically be hit with a UAC prompt when trying to install software, which may deter them from completing the installation if they are unsure or unaware of what it means, something that is exacerbated by a user’s inexperience.

This article by TG Daily shows how some other browsers have simplified the installation process. Apple has started to bundle Safari as an “update” in an aggressive attempt to gain market share, while Google’s Chrome uses a lightweight online installer to speed up the installation process.

Easy or flexible?

Chrome’s installation approach is particularly remarkable in how it works. It requires less user intervention and furthermore, installs itself in the current user’s Application Data folder, which does not trigger a UAC prompt. (This also means that it must be installed for each user on a system, rather than being installed on a system-wide basis) Google also installs its updater, which runs in the background to keep any Google software up to date on the target system. Such a system is highly convenient for non-technical users, who don’t want to be bothered with manually keeping things up to date, but has drawn complaints from those more technically-oriented.

This highlights the differences a developer faces when creating an installation procedure. Typically, developers will lean towards providing the end user with as many options as possible because it’s the easiest way to solve a design decision. Can’t decide between X and Y? Let the user choose! This also goes along with the philosophy of power users, (a group that developers are pretty much a subset of), who like to know exactly what’s being installed on their system and what’s being done to it.

This contrasts with the needs of the typical user, who just wants the software to install as seamlessly as possible. I’ll have to admit, the Chrome installation procedure irked me a little, as I was more comfortable with the “normal” Firefox installation procedure, which gave you the option of where you wanted to install the software, etc. But ultimately, the Chrome installation process likely worked for 95+% of the users, so in the end that way wins out.

Lowering the barrier

Much can be learned from these results if you’re trying to get users to sign up for a service. In many ways, the process for signing up a user is like the process of getting the user to install software. Both require the user to entrust their resources to your service, and both require them to go through a series of steps. If the user really wants your service, they’re likely to put up with more of a hassle, but in general your aim is just to get them to try out what you’re offering, so you have to make things as simple as possible.

This is what I’ve tried (not sure if I’ve accomplished) with the RunTrackr registration process. Obviously, there are changes/improvements to be made. If the service were to get more popular, I’d have to implement more anti-spam/anti-bot measures, some of which might impede usability. But in general, I like the one-step registration process.

One of the things I decided from the get-go was to allow users to create routes without registering; this lowers the barrier required for them to create content and allows them to try out the service before committing to registration. However this has resulted in a lot of “unowned” routes created as an initial use. Following this, even if the user registers, they are unable to “claim ownership” of the route. One improvement I’d like to make is to tie in a “quick registration” option after the unregistered user has created their first route, allowing them to register and claim ownership of that route. I haven’t figured out the best way to do this, though.

However, I’ve been looking at Kijiji as an example of how this might be done. Kijiji is a localized online classified ads site, owned by eBay, and it allows users to post wanted/for-sale ads without registration. (The user must enter an email address to provide confirmation, as an anti-spam measure) However, after posting an ad, Kijiji makes it easy for that user to quickly register in one step and claim ownership of the ad they’ve just created. I suppose this is easy, since they already have the user’s e-mail address, but I would still like to implement something similar to improve the user experience.

Delegation

Delegation is a fairly well-known design pattern. In short, it is a way for a method to produce its result simply by calling a method on another object, thus delegating responsibility to that object to provide the functionality needed by the method. For example, a Cashier object could store a delegate object called Calculator. Calling Cashier.addToTotal(value) would simply delegate to the contained object, calling Calculator.addToTotal(value).

How is delegation different than inheritance? With inheritance, the subclass inherits all of the functionality/behaviour of the parent class. You may not want or need this; in the preceding example, it would not make sense to have Cashier extend from Calculator simply because we wanted the addToTotal() behaviour/functionality. Delegation allows the behaviour advertised by a certain object/class to be provided by another.

Traditional Event Handling

In order to understand event delegation in JavaScript, we should first look briefly at how events are handled traditionally. When I talk of traditional event handling, I am referring to the model that most will know. In this model, functions are individually bound to events of certain elements. For example, to make all links turn bold upon clicking them (and prevent them from being followed), we could use some JavaScript like this:

window.onload = function()
{
  links = document.getElementsByTagName('a');
  for (var i = 0; i < links.length; ++i)
  {
    links[i].onclick = makeBold;
  }

}

function makeBold()
{
  this.style.fontWeight = 'bold';
  return false;
}

The key point with this example is that the function makeBold(), our event handler, is bound to each and every a element. From a resource point of view, this is may be a bad thing because the more event handlers that are attached, the more memory that is used, in general.

Of course, I promised I’d be using jQuery, and doing so cleans up the above code substantially, as well as making it cross-browser compatible: (Besides adding a ton of other abilities and making life easier)

jQuery(function()
{
  jQuery('a').click(makeBold);
});

function makeBold(e)
{
  e.preventDefault();
  jQuery(this).css('font-weight', 'bold');
}

While this code is cleaner, it still does basically the same thing as above, that is, the event handler function makeBold() is bound to each matched element, that is, each a element.

As a final note, don’t confuse my use of the term traditional with Peter-Paul Koch’s excellent guide to JavaScript event registration, where he uses the term traditional to refer to one method of event registration, distinct from inline registration and the later W3C and Microsoft “Advanced” event registration models.

Event handling using delegation

By contrast, event delegation uses a single (or comparatively few) event handlers to implement the behaviour required. This takes advantage of two key features of JavaScript events, namely event bubbling and the target event.

Event bubbling is a model for how events take place on the page. It grew out of a need to resolve the order in which events were triggered on ancestor and descendant elements. For example, assume that I have two event handlers, one attached to the “click” event of a div and another attached to the “click” event of an a element within that div. If I click the a element, which event fires first? Event bubbling is one way to solve that question: It states that the event on the inner element happens first, and then the event “bubbles” upwards to trigger events on ancestor or container elements. There is another opposing model that works in the opposite way, but bubbling seems to be better supported and is more relevant for this article.

Here’s a crude diagram of event bubbling, using a pseudo-CSS box model of sorts:

Event bubbling diagram

The event target is the DOM element that issued the event, or the originating element. This is why I believe it’s a confusing term, since it would make more sense to called it the event source. But I digress. The event object, passed to an event handler as an argument (or available via window.event, though jQuery normalizes this) contains a property, event.target, that allows you to get the reference to the “target” element that the event started bubbling up from.

How it’s implemented

All of this is typically accomplished by registering a single event handler to a “container” element that holds all of the elements we wish to react to events for. When an event is triggered on one of the inner elements, it “bubbles up” to the container element, where it triggers the event handler function. From there, we can inspect the source of the event (confusingly called the event target) and then react accordingly.

This is where the delegation aspect comes into play. Since the container element may hold many inner elements, it is unlikely that we would want the same behaviour for each element when an event was triggered on it. For example, we might want certain a elements to trigger one action when clicked, while wanting another set of a elements to trigger another action. We’d typically differentiate these links by using separate class names or by context and then attaching event handlers as appropriate.

Using event delegation, process is similar, but instead of attaching multiple event handlers we have one on the overall parent element. When this event handler is triggered, we determine which element triggered the event and then based on this, delegate the remainder of the processing to another function. An example would be helpful now, as our previous examples with making some text bold weren’t too useful. Here’s the XHTML fragment for the container and elements.

<div class="container">
<ul class="top">
  <li>
    <a href="#" class="expandList">Item A - Click to toggle</a>
    <ul class="hide">
      <li>Sub-item 1</li>
      <li>Sub-item 2</li>
    </ul>
  </li>
  <li>
    <a href="#" class="expandList">Item B - Click to toggle</a>
    <ul class="hide">
      <li>Sub-item 1</li>
      <li>Sub-item 2</li>
    </ul>
  </li>
  <li><a href="#" class="remove">Item C - Click to remove</a></li>
  <li><a href="#" class="remove">Item D - Click to remove</a></li>
</div>

And here’s the JavaScript:

jQuery(function()
{
  jQuery('div.container').click(handleEvent);
});

function handleEvent(e)
{
  // Obtain the source element through event.target.
  var target = jQuery(e.target);

  // Now decide what to do with it.
  if (target.is('a.expandList'))
  {
    // We use Function.call() to set the context for the `this` keyword.
    return expandList.call(target, e);
  }
  else if (target.is('a.remove'))
  {
    return remove.call(target, e);
  }
  else
  {
    // Otherwise, allow the default action to take place.
    return true;
  }
}

function expandList(e)
{
  e.preventDefault();

  // The `this` keyword now references the jQuery object representing the
  // target, since that is what we set the context to.
  jQuery(this).parent('li').find('ul.hide').slideToggle('fast');
}

function remove(e)
{
  e.preventDefault();
  jQuery(this).parent('li').fadeOut('normal', function(){jQuery(this).remove()});
}

With this example, the steps are clearly outlined. First, we attach the overall event handler to the container element; events that take place on its inner or children element will bubble up to it. When an event is received, we inspect event.target to determine the origin and based on that, “hand off” to another function to carry out the proper behaviour.

With some standardization of the CSS class names you use and the associated event handler function names, you can clean up this code to reduce duplication and turn it into a design pattern of sorts. In fact, that’s exactly what Dan Webb has done.

More advantages of event delegation

Besides potentially using less resources by having less event handlers bound, event delegation brings one other significant advantage: The ability to have event handlers “auto bind” to new DOM elements. For example, let’s say we were to dynamically update the DOM and add more list items to our previous example; this sort of action happens frequently during Ajax operations where you want to present new content to the user.

In the “traditional” event handling model, the new elements would not automatically respond to events as you would like. This is because the events were individually bound to each element. This is a well known problem. However, in event delegation, since there’s only one event handler bound to the container or ancestor element, the newly-created elements will respond to the event properly! This is because an event on them “bubbles” up to the container element just as for the original elements.

Demo of Event Delegation

Perhaps a little demo is needed. With this demo, you can see both the implementation of event delegation as well as the effect of adding new elements.

Drawbacks of event delegation

I’ve already talked about some of the benefits (fewer bound event handlers, so less resources used and the ability to adapt with DOM changes), but it’s worthwhile to iterate over some of the drawbacks.

1. Firstly, not all elements “bubble up” in the way described. The blur, focus, change and submit are notable exceptions so you will not be able to use event delegation with these events in the manner described in this article.
2. Furthermore, the code developed to maintain event delegation can be more complicated to understand than with just using the traditional model. Indeed, there is an initial investment time everyone must make to get going. This should obviously be considered since code maintenance is always important.
3. Because there’s one event handler being called for all events on inner/descendant elements, there can be some performance implications. If you’re calling expensive functions within this event handler, the event processing could slow down significantly. Careful optimization may be required.

However, some of these drawbacks can be mitigated by using solutions developed by the jQuery community. Even though event delegation is somewhat new, there are already plugins available that take a lot of the grunt-work out of event delegation, abstracting away the details and making things easier for you. Even jQuery itself also supports event delegation through a built-in function as of v1.3. Here are some options for pre-built solutions:

• Dan Webb’s Delegate Plugin
  This is a fairly straightforward way to implement delegation and it’s easy to setup and understand.
• jQuery’s built in live() function
  This supports a subset of events but is good enough for most uses.
• The Live Query plugin
  This is your best bet if you need the most functionality, though I haven’t personally tried it out yet.

Conclusion

Delegation nicely solves the problem of having to rebind events after adding new elements to the DOM. For that reason alone, I’ve started to use in my work more often. At its heart, it’s a useful design pattern, but should be only with full understanding of the pros and cons. I hope you enjoyed reading this article!

References

1. Event Delegation Made Easy
2. Event delegation without a JavaScript library
3. JavaScript Event Delegation is Easier than You Think
4. Why do my events stop working after an AJAX request?

Revisions

• 2009-02-20: Added a crude diagram of event bubbling

When developing any application, getting proper user feedback during the early stages is essential if you want to have the application suit your customers’ needs. Often this is done with staged tests, but with web applications you can have the benefit of using an online method of retrieving your users’ opinions.

However, doing so can be tricky. If you want to get feedback, you can implement your own system for soliciting it, however, this takes up extra time that could be used to further develop your core web application. Alternatively, there are some existing online services that can provide survey-like questionnaires to users, but honestly, these present more trouble to the user than they’re worth.

When I first started using Stack Overflow, I noticed that the feedback service they had been using, UserVoice, was an elegant and functional solution to this problem.

UserVoice takes care of the problem for you, by providing you with an easy-to-use comment and feedback forum. (It can also be a place where users can submit bug reports, as well) However, it’s more than just a forum: By allowing users to “vote” on particular topics, it allows clustering of the most popular ideas/requests, thus bringing them to your attention the most. It also helps prevent duplicate topics from being submitted, and is a great “Digg-style” way of using the “wisdom of the crowds”, as they say.

There are some drawbacks, of course. If you’re using it to allow users to submit bugs, I wouldn’t rely on it as your sole bug tracker. Instead, I’d use it to receive the reports, then parse through and verify them before adding them to a proper bug tracker (like Trac) where they can be better integrated into your development work-flow. Furthermore, if you have a popular site, the feedback forums can still become deluged in too many requests/ideas, but that is a problem no matter what type of system you’re using for feedback. And, as mentioned before, the voting system helps to bring to your attention the most popular ones so that you can further make a value judgment.

I’ve since launched a feedback forum for RunTrackr, my side project for the past little while. I encourage you to give UserVoice a try, since it’s so easy to get started – you’re literally up and running inside of two minutes. At a minimum, give their home page a visit – it does a great job of explaining the process in a simple and easy-to-understand manner.

On Thursday, Google rolled out an update to its personalized home page service, iGoogle. Among other UI updates, the major new features were increased flexibility in what “gadgets”, the personalized “chunks” that make up an iGoogle start page, can do. This, in turn, allows developers much more freedom with what they can provide to the user through an iGoogle gadget.

Previously, gadgets could only occupy a small box that took up only a third of the screen. While this was okay for reading headlines or perhaps glancing at stock prices, it limited the usefulness of gadgets and the information that could be provided. For more detail, users would often have to click a link in the gadget that would take them away from iGoogle. While this is perhaps the proper use of a “start page”, Google may now see things differently.

Life is a great big canvas

Gadgets now offer a near full-size “canvas” mode, where the gadget is expanded to take up most of the screen. This allows more information to be displayed and makes the iGoogle page less of a start page and more of an aggregator – like an RSS reader, but with much more.

Speaking of RSS readers, any RSS feeds on iGoogle can now be expanded into a full-feed view, using a layout/interface not unlike that of Google Reader, their specialized RSS reader product. All of these enhancements are designed to help you get the information you want, without having to leave iGoogle.

Some good examples of gadgets taking full advantage of the new functionality offered by the new iGoogle include the GasBuddy gadget, which display a small labeled map of local gas prices in the “mini” mode, which expands to a fully-searchable map complete with a clickable legend in the full-screen canvas mode.

Google’s own products, such as the Gmail and Google Calendar gadgets, have also been updated to nicely take advantage of the new abilities. In canvas mode, each gadget expands to fill the screen with pretty much the same UI as their respective web applications. This makes accessing your various Google Account services easier and decreases load times.

Content and Money

Others include the Wall Street Journal’s gadget, which in canvas mode looks similar to a start page of its own. Interestingly, ads are shown in this mode, presumably from the WSJ itself. This highlights another important aspect of gadget development: Income.

This is really the crux of the iGoogle update, in my opinion. By allowing giving more power to developers and allowing more content to be shown on iGoogle, developers can have more flexibility with their creations. In return, Google is apparently willing to allow them to show ads so they can make money off of their creations, which clearly add value to iGoogle.

It’s hardly an original idea. Facebook has had their own applications platform for well over a year, with much of the same ideas. Facebook Apps are made by third party developers, and mostly run “within” the confines of the main Facebook site, keeping users on the site. In return, developers can also choose to run ads in their application to generate revenue. It’s a very similar model. (Facebook recently awarded some of the best apps through their fbFund initiative, with the promise of more money to come – perhaps Google will do the same? They’ve already done something similar with Android in order to spurn development)

Not so fast

Unfortunately, the changes were not all good. For one thing, the vast majority of existing gadgets haven’t been rewritten to take advantage of the full canvas mode. In all likelihood, many will not, since third party developers may do as they like. Gadgets that haven’t been updated will merely be displayed besides a huge “You might also like…” list of recommended/related gadgets when displayed in full-screen canvas mode.

Furthermore, some users have complained about the UI updates. In particular, the mandatory left sidebar now in place has caused some to lament the loss in screen real-estate. Previously, tabs were only shown on top if you had defined more than one; now the list of tabs, along with the iGoogle gadgets in each one, are shown in the sidebar no matter what.

Indeed, such a display might be superfluous if there’s only one tab. At the very least, Google should have allowed the sidebar to be collapsed or tucked away. (I won’t be surprised if they implement this change in the next few days, or already have it planned)

Also surprising is how Google rolled out the new version so suddenly, effectively forcing all users to adopt it. A better approach would have been to roll out a “beta” version (we all know how much Google is in love with beta) and allow users to preview it and optionally switch. This would allow them to get more feedback before switching everyone over, like Facebook did with their new redesign, which effectively took months to take effect.

However, given that iGoogle’s user base is likely a very small percentage of all the users who have Google as their start page (with most just preferring the stripped-down original search page as their starting point), perhaps Google believed that rolling out the updated site would affect so few that a beta period wasn’t really needed. In any event, the changes are not so ground breaking to warrant serious concern.

Okay, so maybe I’m being a bit melodramatic or maybe I’m just a bit stressed out. I had previously talked about how website purchase forms that require you to enter a credit card number in a specific format (e.g., no spaces) were poorly designed since most people don’t deal with large groups of numbers very well. Furthermore, it’s trivial to format the number server-side, so why require the user to? Well, today, I ran into a form that not only required you to enter all of the numbers without spaces, but also punished you if you did not.

A bit of background

I am a member of the IEEE. They’re a great organization, and I find some of their publications such as IEEE Spectrum to be fairly interesting. You also sort of need to be a member if you want to publish anything in the field (I did two summers of research while in university), and since I’m an Electrical Engineer, I feel that I need to be part of the largest organization dealing with the field.

So, when a renewal notice arrived in my mail recently, I didn’t hesitate to pay my dues to remain a member. (Well, actually, it sat on my desk for a week before I did anything, but my procrastination is another topic) I thought that renewal would be painless process; it started out great, because as soon as I logged into the site, there was a big button/link for renewing. Clicking it added a “Renewal” item to my cart.

Checkout, or, things take a turn for the worse

Clicking “Checkout”, I thought I’d just have to enter my CC number and a few details, and things would be done. After all, I’ve ordered a ton of stuff online and have never really had a problem. That was, until I encountered the payment form from hell. Just how bad was it? Well…

I enter my CC number in my usual fashion – groups of four digits, separated by spaces. I like to do this just so it’s easier to double check that I entered the correct numbers. I don’t really care if the server “requires” you to enter without spaces, since I usually just remove them myself before submitting. However, as soon as the credit card number field lost focus, after I tabbed to the next field, the form submitted!

After the page had reloaded, there was a warning in red text, “INCORRECT NUMBER OF DIGITS”, or something to that effect, pointing to the CC field. And, the field was empty. That’s right, it just blanked out the field without even giving me the faintest hint that it would. All my hard work of entering in a 16-digit number was gone, and I’d have to do it again. I didn’t even remember seeing an initial warning telling me that I couldn’t use spaces!

What really happened, of course, is that the form did not really submit. They had some messed up event handler tied to the blur event of the field which sent the value server-side, validated it by their stringent rules, and then loaded the page again if the entered number did not conform to their rules or if the planets did not perfectly align or something like that. That is just whack.

If you actually enter the number the way they want you to, no spaces, it still sends the value server-side, and the page still reloads – but now the credit card field displays not your full number, but just the “XXXX…” and the last four digits, typical of how most statements display it. Your CC number is then stored server-side in a session, I presume. Weird. Furthermore, the submit button of the form wasn’t actually a submit button, (of course…), but was instead a hyperlink with the href attribute set to javascript:someMethod().

Why this is bad

I shouldn’t have to explain this, but I will just because I feel like it. Firstly, as I mentioned before, it’s insane to require users to conform to the “no spaces in credit card numbers” rule when you can just process the number server-side to remove any spaces. But the IEEE form takes it a step further by not only requiring this format, but actively removing any data NOT entered in this manner. It should be a given that you never clear any fields in a form unless the user is given prior warning and confirms it. (This is also why “Reset” buttons should have some sort of confirmation against accidental clicks)

But to carry out all of this action right when the field loses focus is completely beyond me and probably where I lost it. This goes against everything “normal” in UI design. It disrupts your workflow, it changes the state without notification or warning and it pisses off users. A purchase form is probably the worst place to do this in, since you’re trying to facilitate payment from a potential customer.

But the idea that the user has to enter the data in one, very-specific way is just what peeved me off. Most people aren’t perfectionists, so why would you assume that they are when it comes to data-entry and then punish them when they fail to achieve that expectation?

Having strict data format standards for machine-to-machine transmissions is one thing. In human-computer interaction, it’s a whole different ball game, and one that whoever designed the form from hell, evidently doesn’t understand. I’m no usability expert, but I know junk when I see it.

Final words

Okay, so maybe I’m overreacting a bit, or a lot. Though this only wasted maybe five minutes of my time, I was bothered by it enough to write about it for a further ten minutes. You may think me stupid for that, but that’s just how I felt.

Basically, a graphical command line is a command line that pops up on screen when you activate a keyboard shortcut/combo. This command line allows you to easily launch any program, file or action by easily typing its name. This offers you the advantage that good CLIs offer – such as auto-complete and speed-of-use, while retaining the advantages of the GUI. I recently learned of a Launchy, a nice program for Windows that offers these features. (Sort of like Quicksilver for Windows)

More than just a command line

Besides its fairly mundane appearance (though Launchy can be customized with skins), the Launchy interface can actually be one of the most powerful aspects of using your computer. When Launchy is first installed and running, you won’t notice a difference – in fact, you won’t even notice a space-stealing system tray icon. The command line window is brought up by pressing a user-defined hot-key. (By default it is alt-space, but I changed mine to ctrl-space, since the alt-space is already mapped to bring up a context menu for the current window, allowing you to minimize/maximize it fairly fast.)

Then, you simply start typing the name of what program you’d like to launch, and Launchy will look for matches. The list of matches pops up in an auto-complete list, and furthermore, Launchy seems to remember your usage habits somewhat, so next time you start typing, it’ll bring up the matches first that were previously used. Launchy is automatically configured to scan for all programs/links in your start menu, and also can be set up to scan other directories of your choosing. It automatically rebuilds the index after a user-defined period of time, so things are kept up to date.

The advantage of such a system might be lost on traditional GUI users, but anyone who dives into the command line will realize its benefit. Typically, input through a keyboard to accomplish actions is far more efficient that using a mouse. Take the Start Menu, for example. A typical computer will have dozens of programs available for launch, and finding the one you want in a menu can be a time-consuming and tedious task. By using Launchy, you can simply type a few letters of the program’s name, and it’ll pop up as an option. Launching a program takes far less time.

There are also a bunch of included plugins that allow for additional functionality. You can, for example, easily access all of your Firefox bookmarks, and also browse through directories/files from the command line of Launchy, further making it an indispensable application. However, perhaps the best part of Launchy is the fact that it’s open-source – that’s right, it costs nothing. So grab a copy of Launchy today!

An alternative to Launchy, which I have not tried, is Colibri. Give it a try, and let me know what you think.

More on why it’s better

As this article best describes it, a combination of the command line and GUIs is truly a best of both worlds solution. CLIs offer a “high bandwidth” input interface, meaning the choice of applications you can launch with just a few keystrokes is huge; this translates into a quick launch time because you can easily find what you want. GUIs offer a “high bandwidth” output interface, meaning they can convey a lot of information back to the user with graphics such as icons, drop-down menus, and the like. Combining the two gives a nice interface like that of Launchy’s.

In particular, I liked Launchy because I’ve been looking for ways to improve my productivity on the computer. Besides putting my most-used programs in the main level of my Start Menu (thus allowing them to be launched with two keystrokes), I was at a bit of a loss at what to do with other programs that I use less frequently. Launchy has solved those problems, essentially allowing me to launch most any program fairly fast. Windows Vista offers a similar feature in its new Start Menu (finding a program by typing), but I’m still running Windows XP and have no desire to upgrade to Vista anytime soon.

Perhaps the only problem with Launchy, has nothing really to do with Launchy at all. It is in fact the Paradox of the Active User, something that I’ve written about before in relation to design. Basically, the paradox can be summed up with the phrase, “Old Habits Die Hard”. Once most users have learned how to accomplish a particular task, they won’t be keen to learn a new way, even if that way is faster and more efficient – basically, they don’t like to take the time to learn a better way, even if in the long run it pays off.

I’ve been somewhat like this, having only recently enabled/started using keyboard shortcuts in Gmail and Google Reader. However, I’m trying to break these habits and by using Launchy more, I hope to transition to using the keyboard more to perform tasks, rather than just relying on the familiar but slow mouse.

Things like friends’ status updates, new friends of your friends, new photos of your friends, and groups that you friends have joined/left are listed, along with when these actions occurred. Basically, most of things that people would browse around for about their friends have been nicely aggregated into one page for easier viewing, making the service easier to use and more relevant. However, it’s almost information overload – I don’t really need to see every status update on what groups my friends have joined or left, do I?

Additionally, it makes it easier to snoop in on what your friends are doing on Facebook and when they’re online – though it should be noted that all the information posted in the News Feed was always publically available; this just makes it dead simple to find all of it.

The second feature that was added was what they called a “Mini News Feed”, which is displayed on every personal user’s profile. It’s basically the same as your News Feed, except it displays only the updates for that user/friend – again making it easier to keep track of your friends and what they’ve been doing, which only serves to further improve Facebook’s social networking ability.

I agree with TechCrunch’s assessment that Facebook “gets it right” when it comes to social networking – it’s more about making the end user experience better than just about increasing pageviews, and often the two are conflict. Other sites just can’t compare, in my opinion. My only suggestion for improvement would be to have some sort of settings page for the News Feed so what’s displayed can be customized.

Nothing’s changed with privacy?

However, I disagree with Facebook’s assertion that these changes “do not give out any information that wasn’t already visible“, at least in principle. While it’s true that before you could have constantly scanned each and every one of your friend’s profiles in order to figure out when they had joined certain groups, posted wall messages or otherwise updated their profile, this would have been very tedious and time-consuming, and only the most dedicated stalkers would be able to keep up. The new features make this pseudo-voyeurism all too easy. (You could have also written a scraper before, but this would probably have been against the TOS)

If there’s anything good about these changes, it’s that it’ll make people think twice about posting incriminating or otherwise personal information that they would normally want to remain private. It may also force users to reconsider who they really want to add as a “friend”, and how they want their privacy to be set.

I’ll still be using it

Of course, I’m not going to stop using Facebook. But, maybe the way I use it will change – and most likely this will be true with many other users, if the newest Facebook group, entitled “The New Facebook is Freaky as Sh*t“, is in any indication of this. How did I learn of this group? By noting that a friend of mine had just joined it, as of 11:17 PM EST tonight.

Wait a minute!

Now, some of you will know that I’m no fan of Apple fanboys, (or fanboys in general), but Apple does get it right when it comes to usability – people generally find Macs easier to use, and more intuitive. While their current line of commercials (“Hello, I’m a Mac…”) may be annoying, they are in general correct for the majority of users who just want to “get things done”. This can be further seen in the success of the iPod – its control interface is second to none.

What’s wrong with the UI in Windows?

There’s nothing wrong with the UI in Windows – it works just fine for me, and I don’t find that it gets in the way when I’m trying to get things done. But, for some people, such things aren’t so intuitive, perhaps because they don’t live and breath computers like I do.

The quick launch bar that comes with Windows is okay, and so is the Start Menu – but an application Dock is bigger, more visible and thus is quicker to use for the average user, such as my Mom. (Though some would disagree)

The choices

It turns out there’s a lot of other people who also want a Dock like Apple’s in Windows, since there are a plethora of programs out there that accomplish this. The top three I found were MobyDock, RocketDock and Y’z Dock. I only had time to try out the first two, and there were many more that I didn’t bother to look at, but I was impressed.

Both programs support easy drag and drop operations, so you can add programs to the dock simply by dragging an existing shortcut onto it; removing the icons from the dock is just as easy. They can also be positioned virtually anywhere on the screen, with offsets from top/bottom/left/right being allowed. They also feature the nice “zoom” animations as featured on Apple’s version, and have a small memory footprint.

They’re also devoid of any confusing jumble of messy configuration dialogs – the settings pages are very simple and straightforward, and the apps “just work”, so you probably won’t need to even touch the configuration pages. This is the way software should work, at least software intended to be used by the masses. Too often, software comes with too many options pages, making configuration both confusing and tedious. Usability testing should be done to find out what’s intuitive, instead of making a bunch of cryptic settings.

Out of the two, MobyDock probably offered more features than RocketDock, offering built-in widgets for Weather, Screenshots and a Clock. However, it also seemed to be a bit buggy, as it crashed a few times, so I’ll be using RocketDock since it’s for the parents’ computer, and they don’t need to deal with that. MobyDock also seems to have stalled in development, with the latest version being put out way back on November 18th, 2003 – by contrast RocketDock still appears to be continually updated.

Kudos to the developers of these programs for not only making a useful piece of software, but also for making them freely availabe.

Complicated!?! How?

Now, I know what some of you may be thinking – just how can using a mouse be complicated?. Well, it’s not that it’s compliated per se, but rather that the patterns of usage associated with the mouse take time to learn before they become instinctive. I can’t really remember the first time I used a mouse, (it was many years ago, and I have since filled and emptied my brain many times), but I suspect that I didn’t “get it” right away.

Take the example of the single-click vs. the double-click when performing actions in an operating system, such as Windows XP, for example. Even if you don’t have problems with fine-motor-skill and control, you still have to learn when to use what – and by learn, I mean to have the distinction ingrained in your mind so that you don’t have to consciously think about it when you want to perform some action that requires a single or double-click.

Will that be a single or a double?

The distinction between a single and double-click for actions may seem arbitrary, and, sometimes it is, and sometimes they can even perform a similar action, in different contexts. If you stop to think about it, there really are quite a few rules about clicking that can only really be learnt through time spent using a computer.

Usually, the double-click is used for opening things that are represented by icons, at least when they’re on your desktop or in a folder. This is to distinguish between the single-click action on these items, which selects them. This is a pretty easy difference to understand. For menus, the double-click usually has no meaning – a single-click opens the item. In this case, there’s no need to select anything, usually, so there’s no need for a separate double-click action to separate selecting from opening.

For text, a single click places the cursor at the location, while a double click can serve to select the entire word. Notice that here a double-click is the action that performs the selection function, and though this is the logical way of setting things up, it’s all part of a set of subtle nuances of mouse use that take time to learn.

Context

But, where things get complicated is on a medium such as the web, where the context is a blend of the two basic situations described above. As mentioned before, with icons, a double-click performs the open or “browse to this folder” action. However, on the web, almost all actions are performed with the single-click. To follow a hyperlink, the link is single-clicked, not double-clicked, following the guidelines of a text document rather than those of a icon-environment or context. (This also makes selecting hyperlinked text more difficult)

At first, this makes sense, since most of the documents on the web consist mainly of text. But, what happens now if the link consists not of text but an image, rather like an icon? The action remains the same, but the look has changed, almost to that of an icon – thankfully, most web-browsers change the look of the pointer when it’s over a link to remind the user that it’s a link, and hopefully, they will be adjusted enough to use a single click for all links and not be confused.

But where things get really tricky and confusing is in modern “web applications”, which are just websites heavily enhanced with JavaScript (or other client-side technologies) so that the experience of using the website is closer to that of a desktop application than a regular website. Some of these applications have really tried to emulate not only the functionality, but also the look and feel of desktop applications, resulting in some usability issues with clicking.

Take this comment by about the new Yahoo! Photos site; the user laments about the interface requiring a double-click to open a full-size image rather than just a traditional single-click as on most other websites. (The double-click detection is done via JavaScript)

I’ll admit that while I was first confused by this action, I thought little of that user’s comment – I mean, how hard can it be to learn a simple action like that? But, after some more thinking, I’ve come to agree with the comment – breaking the pattern of how a user navigates on a website is not a good idea, even if it’s done to try to make your website feel more like a desktop application.

Change is not always good

As long as the user realizes they’re on a website, they’ll continue to use it like one, with single-clicks performing actions. If you’re designing a web-application, you need to realize this, and shouldn’t break this functionality to try to “trick” your user into believing they’re using a desktop application. Even if you provide many warnings and notices, they’ll still be slowed down by this change if they don’t continually use your site – and you always want to keep the learning curve as flat as possible. And, let’s face it – while making interactive web applications is cool and I’m all for it, most people (e.g., mainstream) don’t really care and just want something that’s easy to use.