• New and much improved rich text widget (based on TinyMCE)
• Awesome new data grid editor/builder
• Improved look and feel
• Much better stability, particularly on Macs and with large documents

You’ll find lots of other fixes and tweaks; it’s our biggest update yet. But you may wonder why it took nearly 5 months. Well, for me the central character in the story is Not Invented Here Syndrome.

Now, you’re probably all familiar with this nefarious malady that we developers suffer. In case any of you aren’t, it’s a term to describe reluctance to use technologies that were not developed in-house. There are a lot of justifications for it, and it doesn’t always cause problems, but what is important to consider is that if it bites you, it’s probably going to bite you twice.

What does that mean? Take the example of Mockery’s rich text editor control. When we started Mockery, we built what we thought was a robust and powerful editor. Why didn’t we use a free, open source, off-the-shelf solution? Well, the options we had were mostly web-based, and Mockery isn’t really a web app, and we were sure we could do a better job…and so on. At least part of the reasoning was (I’m sure) that it would be fun to write a WYSIWYG.

It was, and it wasn’t. But that doesn’t matter, because either way it was a lot of work. So we stuck it out, but eventually it became clear that we did not have the focus, resources, or motivation to compete with TinyMCE. The only answer that made sense was to bite the bullet and just use it. No big deal, right? We’ll just throw our stuff out and integrate the new stuff, no problem, right?

Unfortunately, we’d already painted ourselves into a bit of a corner with our own tool. It had features that no off-the-shelf system had, had a different input and output model, fired different events, accepted different commands…incorporating a 3rd party tool into an existing app is not an easy task.

The moral of the story is this: think very seriously about what you’re doing before you set about reimplementing anything non-trivial. You’re not just risking the time it takes to re-write what someone else already wrote; you’re risking the time it will then take you to integrate what you should have used in the first place.

I know I’ll be heeding this advice, and I know Mockery will be much better for it.

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?

   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?

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.

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!

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.

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.

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.

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.