Posts from November 2009.

Today’s fun JavaScript trick: switch(true)

Programmers who are new to JavaScript but familiar with other C-syntax languages like C or Java are definitely familiar with the switch statement, but may not be aware of how much more flexible this construct is in JavaScript. In fact, I’ve heard experienced programmers claim that they never use switch statements!

One major difference in the JavaScript switch statement  is the fact that the condition can be any type of variable, not just numeric types. Most obviously, this allows you to use a string or an object, which provides a lot of flexibility. So much flexibility, in fact, that when used with a boolean condition the JavaScript switch can provide a very different type of program flow control.

For example, consider a case where we want to take different actions, respectively, if a number is greater than 100, less than -100, or equal to 0. We could write it as a series of if/else ifs, like this:

if(x > 100) {
    doSomething();
} else if (x < -100){
    doSomethingElse();
} else if (x == 0){
    doAThirdThing();
}

Using a switch statement, this block becomes:

switch(true){
    case (x > 100):
        doSomething();
    break;
    case (x < -100):
        doSomethingElse();
    break;
    case (x == 0):
        doAThirdThing();
    break;
}

Is that any better? Probably not. In fact, it’s a little more clever, which may make it a little harder for other programmers to maintain, which would actually make it worse. However, consider the case where we want to take a specific action if x is greater than 100 or y is greater than 200, or z is less than -100, or if (x + y + z) is greater than 500. We could write this:

if(x>100 || y > 200 || z < -100 || (x + y + z) > 500){
    // um, what?
    doSomething();
}

Using the switch statement, that same code looks like this:

switch(true){
    case x > 100:
    case y > 200:
    case z < -100:
    case (x + y + z) > 200:
        doSomething();
    break;
}

I find the second block much more readable. Is it groundbreaking or radically new? No, but this is just another case where the flexibility of JavaScript’s syntax provides an interesting opportunity for more maintainable, readable code.

I Already Told You That!

I used to have a checking account with Wells Fargo. Overall I was pretty happy with the service, locations, and website. It was a pretty good overall banking experience. There was, however, one extremely grating thing. Every time I used of of their ATMs, it started out by saying, “Welcome, Joel. Please select a language for this transaction,” and presenting options for English and Spanish.

Of course, I have no problem with them providing the option to conduct transactions in Spanish. What bothered me was that I had to tell them every time I used the ATM. Christ, they know who I am; I just put my card in the machine, and they’re addressing me by name! What are the odds I would want to change my mind and use a different language than I used last time I used the ATM? Would that ever happen?

Now, there may have been a technical reason that it wasn’t possible to save my preferred language. From a user’s perspective, though, it just doesn’t matter. It’s annoying having to answer the same question, click the same button, change the same radio button, or do anything else every single time you want to get something done.

I try to remember how irritating those ATMs were when I’m adding new functionality in Mockery. Am I asking my users to do the same thing over and over? Users tend to be less forgiving of minor annoyances when your application doesn’t spit out $20 bills.

A roundup of UI guidelines and reference documents

As UI designers, we are responsible for playing nicely with the operating systems that our software runs on. While blind adherence to any rule is obviously not a good idea, uniformity gives applications greater learnability and makes users feel at home. If you’re doing something in your app differently than other apps do the same thing, you should have a good reason.

If you’re developing software that will run on multiple platforms, in most cases the technology you’re using will handle rendering controls and widgets in a platform-appropriate way. But using platform-specific design patterns is still up to you. Luckily, most major platforms provide guides for designing UIs that feel right. Here is a list of useful documentation broken out by OS.

Windows

Mac OS X

  • The Apple Human Interface Guidelines are the grandfather of all UI guidelines and pretty much a one-stop-shop for information of best practices in Mac OS UI development.
  • The Aqua Interface deals specifically with the controls and widgets available to UI developers on the Mac.
  • The Mac OS X Environment provides a run-down on the Dock, Finder, Desktop, and more Mac-specific OS-level features that may be unfamiliar to Windows-only developers or designers.
  • The Design Process is a good, quick read with some good, though often obvious, advice.

Linux/Other

This is not intended to be an exhaustive list of UI reference materials; rather, it is a list of official reference materials provided by platform providers. If you know of other useful platform-specific UI guideline documents, please post them in the comments.