Mockery Blog

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

I play guitar left-handed, which is kind of a pain in the ass when it comes down to it. I can’t play anyone else’s guitar and they can’t play mine. When I go to the guitar store, there are usually only a couple of lefties and they’re usually pretty unspectacular.

Most times when I mention this to people they ask me why I didn’t just learn to play right-handed. After all, it would be my left hand that would be doing the “hard” part. And, in fact, I tried it when I was first starting. Thing was, it just felt wrong. I didn’t enjoy it until I flipped the guitar over and played it the way it felt right. Years later, I’m still happily shredding.

The suggestion to “just play right-handed” is well-meaning but wrong. There is a reason that right-handed people (almost) universally play guitar right-handed. There is a real connection between plucking and strumming and the dominant hand. It just works that way for most people. Fighting to overcome that natural tendency is not fun, and when playing music is not fun people do not learn to play. I think you’d be doing a disservice to an aspiring guitarist if you told him or her to flip the guitar over and play it the other way because that’s just the way it’s done.

Software, I think, is a lot like that. You can force people to try to accommodate your interface. If your app is important enough to them, they may even fight their way through the pain and continue to use it. But if you continually tell people to do things in a way that is uncomfortable and unintuitive for them, people who are just getting started are going to bail out and give up on you because it’s not worth the pain to them. If I ever get tempted to cut a corner UI-wise, I’m going to try to remember how it felt to try to play that right-handed guitar 15-odd years ago when I was getting started.

I probably shouldn’t admit this, but I’m not any good at shell scripting. It’s one of a few things I’m not good at that mean I’m not a “real” programmer (the others being regular expressions and SQL queries…good thing I’m into UI). But I have hope that I will get good at shell scripting.

So I’m pretty psyched that StumbleUpon came through for me with a couple of useful links related to shell scripting. Here they are. Enjoy!

http://www.techinterviews.com/basic-shell-scripting-questions

http://blog.emson.co.uk/2009/06/18-useful-bash-scripts-for-web-developers/

I finally got an opportunity yesterday to do something I’ve always wanted to do: use bitwise arithmetic in JavaScript. Why would I want to do that? Mostly because it’s interesting and different, but also because bit-twiddling is something that programmers should just know how to do, whether or not we ever actually have to anymore.

The problem with bitwise arithmetic in JavaScript (and, for that matter, in most other languages) is that it’s almost always the wrong solution to the problem. It’s not 1972 anymore, and we can spare enough RAM to give each boolean value its own variable. Sure, it’s a tiny bit less efficient, but the efficiency cost is more than offset by the increased readability and maintainability of code with meaningful variable names.

So in all but the most performance-critical examples, using bitwise arithmetic smacks of premature optimization and over-cleverness. So imagine my delight when I was given the task of storing at least 2, possibly more, flags in a single database field. We weren’t going to get a second field under any circumstances. Arguments raged about whether to use comma-delimited strings, JSON-encoded objects, pre-defined constants, or something else.

What I arrived at was, I believe, the correct solution given the problem. I’m using an integer to store the booleans, and each bit position in the int corresponds with a single flag. Checking the flags is where the fun comes in. Folks with heavy CS backgrounds are not going to be impressed, but those of us who have honed our skills in interpreted languages will get a kick out of this:

// Check whether the second bit is set in the passed integer
function checkFlag(bitmap){
    var mask = 2; // since 2 in binary is 00000010, this will check the second bit.
    return bitmap & mask
}

The bitwise AND operator (&) takes the bitmap and the mask (which is 00000010 in binary) and returns a new number where bits are only set to 1 if they are 1 in both the bitmap and the mask. So if you pass in 3 (00000011 in binary) as your bitmap, only the bit in the second position appears in both. The operator returns 0000010. Since it’s non-zero, we know it passed the test. If you pass in 4 (00000100 in binary), no bit gets set since no bit is set in both numbers. The operation returns 0, and we know the test failed.

So, given a tricky problem (store multiple boolean values in a single variable), we have a tricky solution that’s a little bit of fun to implement and think about. I would love to hear examples of other legitimate uses for clever JavaScript.

Really cool and interesting post by Derek Powazek here:

http://powazek.com/posts/2090

The gist is that SEO is not a valid field in and of itself and that good content will rise to the top naturally. Google works all on its own, and part of Google working is not requiring (or allowing) gaming by SEO goons.

Also of note is that traffic is increasingly driven by social media, which I have to imagine is harder to game as it is driven by real people. So the advice is doubly valuable there.

Sometimes it occurs to me that I’m putting up with unreasonable pain from the software I use on a day-to-day basis. It’s really easy to get into habits and put up with some pretty big deficiencies.

I think it’s dangerous allowing users to put up with annoyances. You’re basically training them to dislike and resent your software and pushing them to find a replacement. Just getting the job done is not nearly good enough.

I will not allow this to happen with Mockery. I’ve got the UserVoice page set up. I’m on top of support emails. The rest of this is just a process of making sure that users communicate any issues to me and making sure there aren’t any annoyances just minor enough for people to work around them.

Tough day here in Red Sox Nation. I think just about everybody had the impression that this year’s team didn’t have what it was going to take, but most of us were hoping for more than this and a rematch with the Yankees in the ALCS would have been fun.

I am looking forward to having more time on my hands to work on some exciting new Mockery enhancements. The Celtics look great this year, and I’m going to enjoy following them. Nevertheless, it’s hard not to be a little melancholy after the long, tough baseball season just ends with a thud.

For what it’s worth, I’ve been saying that the Sox need to either make Papelbon a starter or trade him while he has peak value. Daniel Bard is my favorite player to watch right now and I’m confident that if he had been the closer we’d be getting ready for tomorrow night’s game. Maybe this will be the push that the front office needs.

One of the snags I run into most often when I talk to people about Mockery is the terminology involved in designing UIs. What one person calls a mockup (or a mock-up) another person may call a prototype or a wireframe. While they all amount to more or less the same thing, here’s some clarification on how I see the terms:

A mock-up is an image of a product used to flesh out ideas and solidify the design, done (ideally) before implementation begins. It isn’t intended to work at all; it is just a representation of what the finished product should look like.

Naturally, then, some confusion comes in when the term “prototype” is used to describe a mockup. A prototype is, to my mind, a functional (albeit crude) implementation of something used to prove it can be done and to test the technology involved. The key bit is that it should work. And that’s part of the problem with prototypes: the fact that they work means that all too often the prototype becomes the release. It’s happened to me before, and it’s reason enough to

Wireframe is a term I hear used synonymously with mockup a lot; it seems that a wireframe is a very light, fast mockup without much or any visual flair.

All in all it doesn’t really matter, but I do have to explain what a mockup is more often than I would expect. Hopefully getting the word out about Mockery will help.

Anybody have any thoughts on what we should call all of this stuff?

Update: http://www.melissabernais.com/blog/wireframes-v-mock-ups-v-prototypes/ describes Melissa Bernais’s take on this really well. I agree with her on all of these; our definitions of prototype are a little different but not incompatible.