Dear IA People:
I love your Tokyo subway map of all the major Internet properites in the world. The “Google block” in the top-right corner is fantastic, and it really speaks volumes about the nature of P2P when The Pirate Bay sits alongside Flickr and Reddit. But, can you please get rid of the snap.com snapshots? And fit the whole thing above the fold? Thanks IA folks.

Edit: Whoops, forgot to actually link to it.

(Via the always-great information aesthetics).

Tags: ia, subway, internet

The Product Development and Management Association is perhaps the leading professional association for folks in its field. It’s a world that Adaptive Path has been getting closer and closer to as we shifted our focus away from marketing and toward product development, particularly product development that makes sense for the people using those products. The website of the conference is a disaster.

peterme.com :: Talented bad web design

You’d think that an organization supposedly focused on developing great, usable products would have created a usable site. Especially one for its chief conference. One focused on building usable products.

“Great-looking” and “novel” don’t equate to “usable” and “successful.”

technorati tags:design, pdma

37Signals launched another product this week, and continued to show that they’re the best at product launches and immediate customer service in the business.

In the world of the Internet and its near-infinite set of possible customers, it’s impossible to get a product correct right at launch. Most Internet companies do a launch and a follow-up to that launch after quite a while (a month? a couple weeks? how ever long it takes to analyze all that usage data and customer feedback?). 37Signals ran a 36-hour follow up, trotting out a host of new features to immediately satisfy customer needs.

This is great on many levels.

• 37Signals immediately delivered on customer experience;
• 37Signals immediately fixed bugs and added new features;
• and, 37Signals immediately found and created additional channels of revenue for their product.

The old launch it and wait strategy is dead in favor of the early launch and quick fix. Get the product out in the users’ hands, and, as commenters tell us in this 37Signals blog post, if you address their gripes quickly enough, adding new features and fixes right off the bat, your users will love you (and your flexibility and high level of customer service.

technorati tags:37signals, highrise, product

I thought I broke FireFox the other day. I was browsing as usual, with a couple tabs open in the background, when I decided to open a new tab. I hit CTRL+T, the keyboard shortcut, and up popped a document layout editor. I thought I hit the wrong key, so I tried again. Same document layout editor. I figured a must have changed a setting, so I gave the “Tools” menu a scan. Nothing.

I opened a new browser. CTRL+T worked there, right off the bat. Then I realized the difference between the two browsers: one had a tab featuring normal websites, the other “broken” browser had a PDF open in a background tab. The PDF had hijacked my keyboard shortcut!

Adobe broke a cardinal rule of usability: their software altered and broke the fundamental experience of the parent software that it was supposed to enhance without giving me, the user, a choice in the matter.

Keyboard shortcuts are learned ways to navigate through a system; users have invested time and effort to learn these things, to become “power users” of the system. Designers and developers looking to enhance that system should spend time and effort to learn the same things, so that their products don’t break or alter the sytem’s fundamentals, changing it in unpredictable ways.

Perhaps, keyboard shortcuts aren’t viewed with the importance that they should be: they’re not for casual users, who might represent the biggest chunk of an audience. However, they are an important function of any system: they enable users to accomplish their tasks faster and with ease, allowing users to power through those quick, routine tasks while saving time and effort to difficult problems or more enjoyable things. Once you learned that CTRL+C copied and CTRL+V pasted, how often do you find yourself moving your mouse all the way up to the “Edit” menu to accomplish those tasks? Those seemingly unimportant keyboard shortcuts form a large part of your experience while you use many different products; they help to speed things up and make you a power user with a few simple keystrokes.

If you’re designing a piece of a system (software, a plugin for a browser, etc.) make sure that your piece of software lives and plays within the rules of that system. If CTRL+C copies, follow that rule. If CTRL+T opens a new browser tab, follow that rule, too. Don’t alter the fundamentals learned, enjoyed — and heavily invested in — by users.

And, from now on I’ll be sure to use CTRL+N to open a new window whenever I need to view a PDF.

Matt from 37Signals details what JetBlue did right and what they did wrong during last week’s airport delay fiasco. It’s an interesting look at how all the pieces of an experience (web, phone, face-to-face) work, rely on each other, and sometimes fail
spectacularly.

technorati tags:jetblue, userexperience

Yes, Apple’s iPhone is cool. But, will it have a cool experience?

Dan Saffer, in the Adaptive Path blog, wonders whether or not the lack of tactile and haptic responses will harm the experience, despite the device’s feature set.

The same discussion has broken out at 456 Berea St.

I’ll grant that the device is certainly cool. But, how long will it take to retrain oneself to use a different method of "keying in" data? Is it worth it just for a – albeit very cool – phone? Those are questions that are probably answered when you see the thing up close (or, in our case, see pictures of it online): "I’ll gladly relearn how to dial to use these apps on the go."

Is this new interface, and its potential clashes with accessibility and usability, a design mistake by Apple? I don’t think so. In fact, it seems that they’re designing primarily (or, singularly) for their target audience, who will buy out this product when it launches and will take the time to train themselves to "do things a new way on their phones." Apple’s primary user base will be elated with the new gadget, and will plunk down millions the moment they go on sale. Apple’s primary user will be tech- and design-savvy enough to have few problems using and adapting to the new product; it’s designed for them. However, in creating a design that may – we don’t know the details of the product’s specifications yet – lock out a whole group of users with different needs, is Apple valuing the business over the experience for all?

technorati tags:iphone, accessibility, usability

Most people (I think it would be safe to assume) would state a usable interface must be a visual interface. While not necessarily crammed with graphics or cool effects, a usable interface, they would argue, is one that you can interact with using your mouse and screen, seeing updates and feedback as those things happen. Unix, then, with its text-only command line and sometimes-cryptic editors, would be the opposite of a usable interface: almost 100% of command line applications work mysteriously, accomplishing some goal sometimes silently at the completion of some often-cryptic keystrokes. So, Unix can’t be usable, right? Wrong!

How can it be??? A usable product is not necessarily one with an amazing visual design, or any visual component whatsoever: a tight visual design can be – and often is – part of a usable product, but it is still just a piece of the larger puzzle. A usable product – in a certain sense – is a product that supports users, making it easy, quick, and delightful for them to accomplish their goals.

A usable product is a product that does exactly what it’s supposed to do, and makes it easy to do so. Dan Saffer, in a blog post discussing Neal Stephenson’s In the Beginning … was the command line, talks about a command line application traders used while he worked at Datek. While it did have a learning curve, it turned out to be very supportive of users who took the time to learn it. The product made users’ jobs easier, making trading a quick series of keystrokes and punch of the enter key. It was nothing more than a textbox.

Slashdot features an article on the birth of Unix editor vi. Vi was designed, the article states, "so that you could edit and feel productive when it was painting slower than you could think." In this, it did what is a very key component of many interfaces (and what a great many interfaces fail to do): it overcomes technological restriction to make users forget that those restrictions exist; it lets users simply do their jobs in the most productive way possible, despite the underlying technology they’re using. This captures the essence of a usable product: it lets users accomplish their tasks without them having to worry about what’s going on in the background.

Usable products, to expand our really limited definition from early, also support varying levels of users, from beginners to power users. Certainly, Dan’s Datek application and vi have learning curves, but they do support users of all types, and do what many "modern" interfaces do not: they reward users for learning more about them and practicing with them. Take a look at the comments in the Slashdot post. Hundreds of people have commented on their favorite editor, with many talking about how the keyboard commands are now firmly ingrained in their memory and permanently boost their productivity. They’d never switch to a graphical editor, because they’re reaping the rewards of learning: their favorite editor has a productivity reward for power users that few interfaces really can capture.

Most interfaces are built for occasional use; should you limit your users to a small set of commands because you believe they’ll only use your product occasionally, or should you build in levels of commands, rewarding users for repeatedly using and learning your product? If it’s a product users’ are paying to use, I’d strongly recommend the latter: if I’m paying for a product, I expect to be using it frequently and am glad to learn ways to speed up and improve my workflow. I’d like a vi, a product that rewards and supports power users.

Sometimes, usable, supportive technologies go almost sight-unseen. A truly usable product does not need a lot of glimmer, or even any glimmer at all. A usable product simply needs to let users accomplish what they’re trying to accomplish, while providing users with the opportunity to benefit from becoming power users of that product, reaping the rewards of really learning about what that product can do. Perhaps, like those hundreds of Slashdot comments would suggest, we should look to Unix for usability guidance.

technorati tags:usability, unix, design

How do you make product specifications comprehensive enough for AJAX, Web 2.0 apps? Simple boxes and arrows aren’t going to cut it: your spec must talk about complex interactions and behaviors, timings (of updates or polling), and application states. In short, you’re not just writing a document that talks about how code should work; you’re writing a document that talks about how people should work with your code.

Adaptive Path took a stab at the Web 2.0 spec and what’s beyond wireframes and came up with a three-pronged approach to documenting Web Twenty apps. Their approach is as comprehensive as any I’ve seen. However, cranking out specs like this seems like a product of having a lot of time (read: billing clients for hours worked) and may only play out will on large, highly interactive projects. (On short projects, these specs might take longer to build than the actual end product).

Specs really do help development, and Adaptive Path’s spec helps capture all of the important pieces of end-user interaction that make or break an app. Ultimately, these things are only as good as your product team: the people responsible for building the spec must have comprehensive knowledge of what can happen in an application for them to document that behavior or they must be willing to work with, and adapt their ideas to, the knowledge of practicing developers or designers whose knowledge of possibilities is greater. In all, writing specifications should be an iterative process with input coming from across all disciplines, a change advanced web applications are forcing to happen.

technorati tags:specs, product, design

Don’t Click It is an interesting slant on the user interface: what would the UI be if clicks weren’t allowed? As a trained clicker, it’s amazing how navigating through this interface using only gestures feels both intuitive and wrong: the years of training almost invalidate the ease of movement. It’s a very odd experience that led me to wonder if this is what navigation is like for people who cannot, for whatever reason, click a mouse button.

Update: Thinking about this more, I’d call the interface itself "natural but wrong": the gestures feel like both at the same time, as ease of use runs into convention and learned behavior.

technorati tags:mouse, gestures, dontclickit, navigation

Sent to the office colleagues:

Very nice interface and use of technology (javascript libraries Behavior and Prototype). The design really supports the interface (note how all columns are even and each panel has a solid top edge which scream "draggable," to promote and invite users to drag items around the page, yet dragging things around keeps the newspaper column feel in tact). Of particular note is the introductory steps they present to take you through initially building your page, which are a great, unobtrusive wizard. In all, it’s a pretty nice take on the "AJAXy homepage."

Josh, one of the guys I work with, pointed out how well the screen resizes, which is very true. Fonts scale pretty well, too. Very "scalable" design, in terms of screen size and what’s on the screen.

technorati tags:espn, redesign, ui, interface, design, ajax, behavior, prototype