Jul 08

Learn To Type Week

Post Thumbnail

As I’ve traveled around and programmed with a lot of different people, I’ve noticed a really frightening thing: in general, programmers don’t type correctly. I’m not sure why this is, but it makes me sad. Most of the people I meet that don’t touch type still can bang away a lot of words a minute, but if you watch their heads, it is like a bobbing robin, constantly looking down to see where their hands are. What a waste of motion and context switching.

Typing is a fundamental skill for programmers. We spend our days manipulating text, so it makes sense that you should have it mastered. In a way, it would be like hiring a carpenter and seeing them flailing around with the screwdriver, missing the screw sometimes, maybe poking their finger. What would you think? That’s how it looks when you are hunt-and-pecking. Embarrassing!

Continue →

Jul 03

Implementation Model vs. Mental Model

Post Thumbnail

Last week I wrote a post which generalized that programmers do not create great user interfaces. It stirred up some pretty intense debate. A few people even emailed me insulted.

I certainly didn’t intend to insult anyone, but it proves that this problem isn’t going away soon. Proper procedures won’t be put in place until programmers are self-aware.

Consumers don’t think about how things work on the inside. Your interface should function as a magic box. Push a button and something predictable happens.

The brake pedal on your car is a great example. Someone who doesn’t understand how brakes work may envision the pedal pushing a lever which exerts sideways pressure on the wheels, causing the car to slow. Their mental model says that pushing this button causes the car to slow down.

The real implementation model of a brake system is far more complex. That complexity shouldn’t translate into the interface.

Alan Cooper, in his book About Face 3, states:

User interfaces and interactions designed by engineers, who know precisely how software works, quite often lead to a represented model that is very consistent with its implementation model. To the engineers, such models are logical, truthful, and accurate; unfortunately, they are not very intelligent or effective for users. The majority of users don’t much care how a program is actually implemented.

The retina display and the subtleties of Helvetica Neue

From John Gruber’s iPhone 4 review:

It’s a subtle change, but Apple has changed the system font for the iPhone 4, from Helvetica to Helvetica Neue. The change is specific to the iPhone 4 hardware (or more specifically, the Retina Display), not iOS 4. On older iPhone hardware, iOS 4 still uses Helvetica as the system font.

I’ve had a hard time aliasing this typeface at small sizes with any real quality. While it looks great in large sizes or in print, both on my Macbook Pro and 3G iPhone, the type is fuzzy at 14 point or smaller. (I suspect this is due to font hinting) Not surprisingly, it renders very cleanly on the retina display.

This kind of attention to detail is just one example of what separates Apple from the other manufacturers who clearly couldn’t care less about this stuff.

Jun 24

Draft

Post Thumbnail

37signals announces ‘Draft,’ a simple iPad application for sketching up wireframes and sharing via Campfire.

This move seems like it’s less about the product and more about pimping their software development opinions. There’s absolutely nothing wrong with that. For the record, I don’t have a problem with the $9.99 price tag either.

(Aside: A lot of people are complaining that it’s too expensive. They also just broke into the Top 100. So, you decide if it’s too expensive.)

I’ve always agreed with their minimalist approach. It’s like YAGNI on steroids. Sharpie markers, bold strokes, forget the nitty-gritty details… all great advice.

But, it feels like they’ve intentionally taken this to the extreme. Basecamp is great because they left out features that would get in the way. In Draft, it’s as if they did this because it’s cool to leave out features, rather than useful.

On another note, the attitude in Jason’s comment irks me:

We might add yellow to version 2.0 in 2012.

Kinda witty and funny, in a blunt and rude way. It was a rather condescending response to a comment left by someone praising the app they just publicly purchased.

Just bought the app. Love the simplicity, and posting to Campfire makes it valuable. If the goal isn’t to add features… is version 1 the final version?

We run our business on Basecamp and Highrise, and wouldn’t change that for the world. I never thought I’d see the day where Adobe creates a better user interface than 37signals.

Jun 22

Why you should keep programmers away from your GUI.

Programmers generally do not design great user interfaces. I do not mean to cast aspersions in their direction. If anything, it’s a discredit to the project manager who insisted the UI is part of their responsibility. It shouldn’t be – it should be the job of a dedicated designer.

Programmers don’t understand the Mental Models of their consumers. They are so entrenched in the geeky details, that they can’t step back and look at the product through their customers eyes.

A user interface does not need to reveal the inner workings of the product. Rather, the user interface should expose feedback about the actions that the person expects to happen.

For example, a landline telephone uses a very different protocol for transmitting voice than a cellular telephone does. To the consumer, these are variants on the same product. They exist for the same purpose. However, many programmers would consider these to be entirely different products.

It’s important for designers to be involved in deciding what features should be implemented, as well as deciding how the interaction will work, before any technical plans/code are put in place. Otherwise, you may end up with a website indistinguishable from online-banking websites.

Jun 14

On “FanBoy” as a 4-letter word

Post Thumbnail

Apple bashers love to dish the “fanboy” insult to anyone bearing iDevices.

My definition of an “Apple fanboy” is one who blindly and proudly consumes Apple products, blogs, keynotes, etc…, in an obsessive manner. The word blindly is insulting, not the word “fanboy.”

Apple customers, in general, are a fussy bunch. They are obsessive about high quality products with great experiences. They are also critical about devices which don’t live up to their expectations. These are not “blind followers.”

The fact that Apple generally creates amazing user experiences, doesn’t mean we are blind to bad products. We may be members of the Apple cult, but we aren’t ignorant.

I consider myself a loyal Apple customer – even after terrible customer service experiences. I’ve invested in a profusion of their products. I also hate the Mighty Mouse, the new iPod shuffle, and the fact that you can’t register an iPad without another computer.

This “fan” is not a “fanboy.”

Poor Internal UX Design Causes Zappos $1.6 Million

Post Thumbnail

A great case study which proves why you should invest in the user experience of your internally facing applications, not simply the customer facing ones.

Zappos.com CEO Tony Hsieh

We have a pricing engine that runs and sets prices according to the rules it is given by business owners. Unfortunately, the way to input new rules into the current version of our pricing engine requires near-programmer skills to manipulate, and a few symbols were missed in the coding of a new rule, which resulted in items that were sold exclusively on 6pm.com to have a maximum price of $49.95.

This isn’t the first time this kind of thing has happened. Remember the 52″ flat-screen TV on sale at BestBuy.com for $9.99?

2 Weeks or Less

There’s a two-week-or-less version of just about everything.

@JasonFried

Forgiveness

By Joshua Brewer at 52 Weeks of UX

Humans are inherently prone to make mistakes. We do it all the time. Misreading some copy and clicking on the wrong link. Searching for something that doesn’t exist. Entering in a URL that we mistyped. Attempting to engage with an interface in a way it was not designed for. All of these examples (and thousands more) happen all the time with our products.

It is this moment in which we have a unique opportunity to engage our users in a genuinely human manner. We have just interrupted their workflow and they may or may not be able to accomplish the task that the software is supposed to help them perform. So often, when an error occurs users will often blame themselves and, unfortunately, because we give little to no help, they continue feeling like they have made the mistake.

[...]

We failed, not the user. After all, they are using our product. We are responsible for the experience and by admitting there was a problem and attempting to fix it as quickly as possible, we will engender the goodwill and hopefully, the return business of the user.


Search

Latest Comments