Mockery Blog

As I‘ve mentioned before, I play guitar left-handed. And I won’t get into the question of whether it’s a good thing or a bad thing (or a little of both). It is, however, fairly unusual. Anywhere from 7-10% of the population is left-handed, but go to a guitar store and see if 7-10% of the guitars are. It’s rare enough that I’ve only ever met a couple of other southpaw players, and that was only when buying or selling a guitar.

There have been a handful of greats, though, who play the “wrong” way. As a fun (and hopelessly subjective) exercise I thought I would put together a top 7 (get it? 7%?) list. Here goes:

1. Jimi Hendrix. This one’s a no-brainer. He would have been #1 on the list of greatest right-handed guitarists, too, if he had played right-handed. He played a variety of guitars, both built left-handed models and righty guitars with the strings flipped. The greatest rock guitarist of all time.

2. Dick Dale. The king of the surf guitar was was and continues to be innovative and inimitable. He plays Fender Stratocasters strung upside down (that is, strung as if for a right-handed player). His machine gun tremolo picking and lightning-fast runs were unlike anything anyone else was doing when he appeared on the scene.

3. Albert King. The Velvet Bulldozer. A tremendous blues frontman, he had a commanding and powerful stage presence and voice that complimented his muscular and agressive playing. He’s another guy who played guitars strung for right-handed players, which no doubt contributed to his unique voicing and phrasing.

4. Tony Iommi. A founding member of Black Sabbath, Iommi has as much claim as anyone else to the title “inventor of heavy metal.” Since 1969, Iommi has been cranking out classic metal riffs, from Iron Man to War Pigs to Sweet Leaf, along with some surprisingly sweet and sophisticated prog-rock-inspired interludes like A Bit of Finger and Planet Caravan.

5. Paul McCartney. Surely the man needs no introduction, but besides being a very musical and underrated bass player, McCartney played guitar on several Beatles songs. Later on in Wings and his solo efforts he played many of the guitar parts.

6. Kurt Cobain. Not a great technical player, but composed some classic riffs and songs, many of which are very deceptively hard to sing and play at the same time. Would be rated much higher if this list was based upon influence, but even as a guitarist he could hang with the greats. Interestingly enough, Cobain wrote with his right hand.

7. Omar Rodríguez-López. Pompous? Yes. Often annoying? Well, that’s my opinion, but yes. Say what you will, (and obviously I’m not a great fan,) the guitarist for At the Drive In and The Mars Volta can shred.

So, what do you think? Anyone I missed? Who should I move up the list?

The other day I was talking to a couple of friends about a ReferenceError they were getting in some code they were running. They were just checking for the existence of a global variable. They were just doing this:

   if(foo){
      doSomething();
   }

Would you expect that to work? If so, you’re better at this than I am. If foo is not defined, either in the current scope or globally, you’ll get a ReferenceError there. Why does this strike me as so inconsistent? Consider the following:

   var foo = {};
   if(foo.propertyThatDoesntExist){
      doSomething();
   }

If you check for the existence of a property of an object that doesn’t exist, it simply returns undefined. No error is thrown, your code doesn’t halt execution, things don’t explode. In fact, the interpreter will work its way up the scope chain from foo, looking for the missing property.

Now, consider this example:

   var setImplicitGlobal = function(){
      implicitGlobal = 'Are you sure this is what you wanted?';
   }

   setImplicitGlobal();
   alert(implicitGlobal);   // Alerts the string from above

So when we’re doing assignment and try to assign a value to an undefined variable, the interpreter assumes we wanted a new global variable and creates it for us. Despite the fact that this is almost never what anyone would reasonably want to happen.

Finally, consider the following:

if(foo){   // Reference error when foo has not been declared
   doSomething();
}

if(window.foo){  // Undefined when foo window.foo has not been set.
   doSomething()
}

So when we try to assign a value to an undeclared variable, the interpreter assumes we meant window.foo and creates it for us. But when we’re trying to read the same thing, it doesn’t make the same assumption, throws an error, and breaks our script even when we thought we were coding defensively.

What am I missing here? This is sort of inconsistent, is it not?

Today I’m posting the first of what I intend to be a regular series of posts detailing tips, tricks, and lesser-known features in Mockery. You may be using Mockery (if you’re not, get over to the download page and get your copy!) without knowing about some really cool features.

OS Themes

One of Mockery’s most powerful features is one that a surprising number of users don’t take advantage of: the ability to view your mockups as realistic Windows or Mac applications. You can change the OS theme of the current slide on-the-fly using the toolbar buttons:

Populate menubars and menus with common values

You can save a lot of time when adding menus to a mockup by using the Populate with common values command. To do this, first add a menubar to a window by checking the “Has a menubar” box. You’ll see the menubar appear (either in the window or at the top of the slide, depending upon whether the current theme is MacOS X). You can enter the name of a new menu in the text box and press enter to add a new menu.

However, Mockery can help out by adding the default File, Edit, and Help menus for you, including their common menu items. Just right-click on the the menubar (Cmd-click on a Mac) and choose Populate with common values. You’ll see the new menus right away.

Copy as Image, and paste image data into Mockery

You may not know that you can copy any Mockery element to the clipboard as an image and paste it into an email or word processing document. It’s easy. Just highlight the item you want to copy and click the Copy as image button on the toolbar.

You also may not know that you can paste image data directly in to Mockery. This can be very useful for basing new mockups on existing applications. Just take a screenshot of the app you want to modify, then choose Edit-Paste in Mockery. You’ll see a new image element has been added to your document.

Where to learn more

You can find lots of tips and instructions on the support page. Also feel free to get in touch with me via email or on Twitter at getMockery.

Sorry for the non-UI/non-software post, but I happened upon Dr. McGillicuddy’s website today (don’t ask me how, it’s a long story) and from there found my way to the General Store, where people who survive the awful site design and navigation can buy various merch branded with their favorite budget liqueur. It was there in the Drink In Style section that I found this:

The bafflingly awful Dr. Family Ski Shot

It’s the Dr. Family Ski Shot. I guess it’s for the family that drinks together? Or it’s a ski shot designed by Dr. Family? Either way, it’s $59.99. For that kind of scratch, it had better be pretty useful, no? So what would you say it is…you do here, Dr. Family Ski Shot?

From the site:

Line up for shots. The Doctor Shot Ski is designed to let 3 people stand side by side to do a shot. It looks and feels like a real mini ski.

So it’s designed to let 3 people stand side by side to do a shot. Were people having trouble doing that without a schnapps-themed piece of miniaturized sporting equipment?

I am glad to see that it looks and feels like a real mini ski. I was getting really tired of all those drinking aids that didn’t feel like a mini ski. Or look like a mini ski. This one nails that, because, well, it was designed to.

Thanks, Doc!

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 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.

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

• Windows User Experience Interaction Guidelines include sections on controls, windows, commands (by which they mean menus and toolbars), text, handling input devices, and more.
• The Aesthetics section of the above document, in particular, has some really useful information about UI layout and the graphic design side of UI.
• Microsoft’s overview of the Windows Environment will be particularly helpful for anyone who hasn’t been able to keep up with the Windows UI over the past few revisions.
• MS’s Visual Index of controls provides screenshots and brief descriptions of UI controls as they appear in the modern Aero Windows graphical theme.
• Top Guidelines Violations serves as an example of what not to do in your UI design.
• How to Design a Great User Experience offers 19 pieces of advice. I’m not certain that Microsoft is the best source for advice on creating great UIs, but they have been successful, and most of these points are fairly self-evident.

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

• The GNOME Human Interface Guidelines are similar in layout and organization to MS and Apple’s guides, but cover the GNOME desktop environment.
• The KDE User Interface Guidelines provide the same for the KDE environment.

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.

“If I’d asked people what they wanted, they would have said a faster horse.”

- Henry Ford

I just heard that quote yesterday from a pretty smart guy, and I really like it. Some people disagree, but I couldn’t agree more. Sliced Bread Design had a great and very detailed take on it. My favorite bit from it:

So, what should Henry Ford have been asking his customers? Instead of, “What do you want?” he could have asked, “Is there anything you particularly like or don’t like about your horse and wagon?”

You can probably very easily ask someone what software they want you to build, bang out the code, and deliver exactly what they asked for. They might even be really happy with it. But if that’s all you’re doing, what separates you from everyone else? What we need to do is break down user requests into desired implementations and desired results.

Implementations are a means to an end.

Customers are not going to make clear distinctions in feature requests between desired implementations and desired outcomes. It is up to us to do make that distinction, because if we can come up with a better implementation that produces the same result, we both win. A customer may ask for a dialog, but what he/she’s really asking for is whatever that dialog lets them do.

Applying this to Henry Ford’s quote, if we had a customer ask us for a faster horse, we could simply break down the request into implementation and outcome. The desired outcome is fairly clear; get me and my stuff from point a to point b faster. The desired implementation? Some kind of rocket-powered superhorse. The outcome is what the customer is willing to pay for, though; the implementation is merely a suggestion. If you can can come up with a better implementation (and Henry Ford sure did), people will not be disappointed.

As a developer, it’s easy to become fixated on details; they’re our bread and butter. That’s why it’s important to take a step back when analyzing customer requests and remember that users have exactly the opposite fixation. They’re willing to work with just about any implementation that lets them accomplish their task. We need to give them what they really want, whether or not it’s what they asked for.

My apologies if this is too obvious, but based on a discussion I was involved in yesterday it seems there are three distinct steps to creating a great UI.

1. Accomplish the task

Often overlooked, this is the foundation and the most important step. Without this step, no matter how well you do on steps 2 and 3, you have failed. You must allow the user to accomplish their task. That may be editing a photo, sending an email, or sequencing a DNA strand. Whatever it is the user is trying to do with your software, it must be possible for them to do. Sounds obvious, but consider how many times you have used software that has failed this step.

2. Facilitate the process

Once you’ve established that your UI allows the user to accomplish a task, the next step is to make accomplishing that task as easy as possible. This involves arranging controls and pages correctly, minimizing the risk of unwanted actions or data loss, usability testing to ensure that the UI is efficient and to minimize user errors, and smart feature design to increase efficiency.

As long as step one is followed, users may put up with some pain to use your application. However, if you don’t do your best to facilitate the process, using your software will be an unpleasant chore that users put up with. We can summarize step 2 as don’t get in your users’ way.

3. Make it fun

Here’s the step that gets missed most often. Step 1 enables users to use your software. Step 2 minimizes the pain of doing so. But the rare piece of software that takes the next step is something special.

One way to make software fun to use is to make the UI visually appealing. Your users are going to have to look at it while they use it, so it might as well be pretty. Apple has obviously always been a leader on this front, but Microsoft has been making some strides on the eye-candy front lately.

Making your software fun to use also involves exceeding your users’ expectations in a surprising way. This can come from some unexpected sources; just recently I found that the mail merge option in Microsoft Word was so easy I couldn’t believe it. When I learned that I can highlight an email attachment in Mac Mail and press spacebar to QuickView it, I was delighted. I’m sure you can remember plenty of times a piece of software just got something right.

So once you’ve established that your software gets the job done and stays out of the way in the process, we can sum up step 3 as make them love it. I know that’s my goal with Mockery.

First off, keep in mind that I’ve never used Groovy, just skimmed a couple of language references, but people I know have used it and like it. In case anyone is not familiar, Groovy is a dynamic language implemented on the JavaVM. It’s commonly used for web development, especially with the Grails framework.

Anyway, having established that I don’t know much about Groovy, I do know that it has a feature that I really wish we had in JavaScript. It’s called the Safe Navigation Operator, and it’s represented as ?. in the code. Quoting the Groovy reference:

The Safe Navigation operator is used to avoid a NullPointerException. Typically when you have a reference to an object you might need to verify that it is not null before accessing methods or properties of the object. To avoid this, the safe navigation operator will simply return null instead of throwing an exception[.]

If it’s not clear from that, here’s a real-world example. Let’s say you have a customer object. That object has an optional attribute address, which is itself an object, and in turn has city, state, and postal code attributes, which are strings. In JavaScript, you could access the State like this:

var state = customer.state.address;

No problem, but what if the customer object doesn’t have an address? That line will throw an exception. We can work around it like this:

var customerState= customer.state ? customer.state.address : null;

But if we get deeply nested objects, the syntax gets really muddy. Using Groovy’s Safe Navigation Operator, we could just do this:

var customerState= customer?.state?.address;

Now, if customer is defined, and state is defined, and address is defined, then customerState has the customer’s state. Otherwise, it contains null. Either way, it never throws an exception, even if none of those objects are defined.

Cases where this could come in handy are data retrieved from deep XML hierarchies, complex nested JSON objects returned by web services, and unpredictable user-entered data.  I’m sure that if JavaScript supported a similar operator I would use it all the time. Kudos to Groovy’s designer, Guillaume Laforge.