Point: Web browsers will become the universal app

Last week, Huned and I exchanged some emails about the future of the Web. Specifically, we were discussing the interfaces that will replace the current Web browser and client-side applications. Biased by the recent pain involved in deploying graphics-rich Swivel, citing the frequent practice of hiding rich data in PDFs instead of loading them directly into a browser, Huned argued:

In order to make information useful, you need an app that is well suited to the data…

Update: My blog ate the rest of this post. Bad blog!

Make Time For Quality – Lots of Time

I am always saddened to see plywood wheelchair access ramps retrofitted to multimillion dollar edifices. They’re ugly and incongruous, and shout “whoops, we forgot about you,” to a valuable minority of users. It leaves me hoping that the building owners sued the architects. Unless the building was designed before 1670.

Recently, I took over the completion of a functional spec/business requirements doc from a coworker. It was about 2 pages long and included about 8 wireframes. At the time, we figured it was “almost done”, just needed a little polish and it would be ready for engineering review.

A week later, the document was finally ready for review. It was 22 pages long, including 20 wireframes.

The Devil is in the Details

Corner cases, alternate flows, defensive design, and all those niggling UI details are your web app’s access ramps. They take a product from good to great. You can address them in the planning documents or you can deal with them in the code, but the Pareto Principle is alive in product design: 80% of a prodman’s effort is typically focused on these considerations.

Many users will never notice your attention to details, but it provides two potential benefits:

  1. Like any excellent craftsmanship, it occassionally reaps big rewards amongst general users. By extending their menu buttons one extra pixel to a screen’s edge, Mac designers created interfaces that are about five times faster than Windows interfaces. Ask a Mac user why they switched, and they’ll say it’s just easier, or maybe they like the pretty case.
  2. It rescues differently-inclined users. I’m talking about the access ramp riders, many of whom are overlooked by the competition. Look beyond the blog mavens and 18-to-34-Males. My Grandmother used Juno, instead of AOL because it was easy (I think Tog worked there too). Actually, look at the blog mavens too – the ones who use Backpack in spite of Outlook’s massive marketing budget, because it does all the right things, and does them well.

User Perceptions Scale Geometrically

Remember the Mac menus: one pixel, five times faster. A satisfied customer tells one person; a dissatisfied customer – the poor sap who stumbles into your unaddressed edge case – tells 11 people. Even in tight races like the new browser wars, Firefox and Safari stand out head and shoulders above Internet Explorer. In premium and emerging markets, the advantage is even more pronounced: iPod wins, Rio is a distant second, and there is no third place.

Quality is Addictive

It’s true, especially for users who care, whether because they’re mavens or face exacerbating challenges. Consider productivity guru David Allen’s argument for purchasing top-quality organizational products: if your file cabinet is difficult to open and you’re in a hurry, you’ll stack your papers instead. Ask a Whole Foods snob to join you in a local D’Agostino and watch their reaction. This is why New Yorkers love the Big Apple: quality blooms and survives in the Darwinian nooks and crannies of our concrete jungle – once discovered, it’s hard to ignore.

A fellow iconoclast recently admitted to falling in love with Flickr. They created an account on a whim, used it, and were delighted. Then they used it again, and were delighted again. And again. All those nice interface details and lovingly-crafted UIs just kept calling him back. In an increasingly disposable world, quality is a refuge.

Remember that “polish” is just one of several options for resource allocation. Limit scope, not quality. Keep your building small and it may not need that access ramp at all.

Product Manager’s Reading List

During the course of my recent search for a Junior Product Manager, I met some people who were interested in learning more about what it means to be a product manager.

Here’s a recommended reading list – these books got me through the early stages of my prodman career, and now live on my nightstand or workbench. They’re heavily skewed towards Internet product design (less low-tech, less marketing stuff, more design and usability). In my future “funnest job” rant I’ll talk about all of the disciplines that product management intersects, so all of my avid reader can better understand just how biased this list really is.

A Starter Product Management and Design Canon

Don’t Make Me Think: A Common Sense Approach to Web Usability (2nd Edition)
by Steve Krug
This is the “aha” book for good product design. I will always be grateful to Pete Steinberg for “strongly recommending” that I read this book during my time at Meetup. If you just got assigned to “fix” a website or web-based app, stop sweating: you can read this in a day and sketch out an improvement strategy that will finally earn you that corner office. It starts with solid guidelines and concludes with an easy-to-implement plan for conducting usability testing.
The Elements of User Experience: User-Centered Design for the Web
by Jesse James Garrett
This book is a great complement to Krug’s work. It’s a handy theoretical framework for thinking about web sites/applications. Garrett starts out by sketching a mental model on a napkin, then walks through the explanation, piece by piece, chapter by chapter.
Strongly recommended if you find yourself wanting to be more strategically organized in your thinking. I leaned heavily on this text during the NeuCo redesign, and it was one of my most successful projects to date.
Universal Principles of Design: 100 Ways to Enhance Usability, Influence Perception, Increase Appeal, Make Better Design Decisions, and Teach Through Design
by William Lidwell, Kritina Holden, and Jill Butler
I stumbled into this one while browsing Amazon, and was surprised to learn that the text lives up to the title. It’s an easy read (notice a theme?), with one lavishly illustrated-or-diagrammed and clearly defined principle per page. A nice mix of design, usability, and psychology. Reading it cover to cover is a little overwhelming, because it’s a list format, but you can open this book at any page and learn something new.
Getting Real
by 37Signals
Hey, remember those days in the late 90s when pundits predicted that ebooks would spell the end of paper? Well buy this book and print out all 177 pages – let’s kick ’em while they’re down!
First off, this book is a great case study in solid product management (solid sales with no overhead!). Secondly, it’s extremely well written – rather than trying to round out the page count with general blather, Fried and crew make their points and move on. The scope of the book is larger than simple product management, but the geniuses at 37 Signals built their rep on great product design, and this publication is a handy distillation of their sometimes annoyingly arrogant blog (when did they become Libertarians?).
The Non-Designer’s Design Book, Second Edition
by Robin Williams
Yup, another short reference. Even if you aren’t confident in your own design skills, this book will help you identify successful design, and (more importantly) figure out how to improve troubled designs.
Williams focuses on the “CRAP” prinicple (contrast, repitition, alignment, and proximity), explaining each component with plenty of examples, including before-and-after cleanups of bad designs. It’s a little heavy on typography (not so useful in the Web world), but generally a must-read if you want to build attractive, engaging products.
Williams has a companion piece that focuses on Web design, and a compilation volume, but I’m not convinced that they can add more value than this one.
The Visual Display of Quantitative Information
by Edward R. Tufte
Although Tufte’s prescriptions for Web UIs are generally off-base (sorry, his museum kiosk idea is terrible), the man is a genius about information presentations. Most Web site/applications mix content and information freely, so you should have a solid understanding of info design.
This one is not a quick read, it’s more of a hands-on example of great product design, with page after page of examples from throughout history (focus on printed information design). I’m a bit of a Tufte geek, so this one may not be as useful as the others, but it’ll still blow your mind and expand your thinking about product constraints.
The Elements of Style, Third Edition
by William Strunk Jr. , E. B. White
I’m a little embarrassed to say I haven’t read this book. Hey, back off – “skimming” and “referring to” are not the same as reading, Mr. Glass House! Nevertheless, language is the core of communication, and every good product manager should read this book – it will help you communicate requirements, write better UIs, and choose effective marketing copy. Let’s both promise each other we’ll read it, okay?
Update: I actually read this book, cover to cover (perhaps foolishly). Like anything by Ayn Rand, completing this book will turn you into a jerk for weeks afterwards.

Online Resources

Signal vs. Noise
The 37Signals blog, it’s mostly product observations, generally good, updated very frequently. It also attracts an intelligent readership, so the comments are nearly always a valuable addition to the conversation.
Jakob Neilsen’s Alertbox column
You’ll find yourself bookmarking a lot of these posts. More info on my favorite vanilla-ist in the next section.
Creating Passionate Users Blog
A little too touchy-feely at times, but this blog is generally very insightful and good for getting yourself out of a rut.
Vitamin
I’m still trying to decide if this one is useful, but it has a good pedigree. Seems like a more focused version of A List Apart, which I rarely find useful anymore.
Yahoo! User Interface Blog
I’m still warming up to this one, but it’s a good daily dose of UI thinking. Pretty technical.

Some Books I’m Planning to Read, One Day

When I’m done creating Amazon affiliate links…

Defensive Design for the Web: How to improve error messages, help, forms, and other crisis points
by Matthew Linderman and Jason Fried
Not one of my strong suits (or anyone’s, I guess), handling the alternatively described “alternative flows” warrants more attention: they’re typically a user’s worst nightmare, and they can cripple an otherwise-solid product.
The 37 Signals products are famously easy to use, so I expect this is a useful read.
Prioritizing Web Usability
by Jakob Nielsen & Hoa Loranger
Last decade’s Jason Fried, Jakob Nielsen is a prolific, polarizing figure in the realm of Internet product design. Nielsen is Mr. Usability Guru, but he’s a bit… focused on usability over any other priority. Most prodmen will say “well, I don’t agree with everything he says, but he has some interesting ideas.” Translation: “His dogmatic attitude is a real kick in the pants, but I can’t think of a way to prove him wrong.” I expect that Nielsen’s garage includes a pegboard with outlines of all of his tools and little labels that read “Place hammer here”. The whole setup is probably screen reader compliant.
Before buying this book, I’d check out Nielsen’s Alertbox column and figure out how much you can stomach. I love the guy, but you may not agree with everything he says.
Writing Effective Use Cases
by Alistair Cockburn
A very wise man lent (loaned?) me a copy of this book. I read it on the train ride home, thinking “This seems useful, but it’s a bit arcane. And dry.” Then it sat on my desk until a project manager asked me if he could borrow it. I see the author’s name referenced fairly often, and I’m pretty sure this is an important book, but whenever I think of it, I can’t help remembering my days as a lightweight rower, spooning down a mix of lite cottage cheese and yogurt so I could make weight.
Persuasive Technology: Using Computers to Change What We Think and Do
by B.J. Fogg
Another cheese-and-yogurt book, loaned to me by Scott Heiferman. (I promise I’ll get it back to you!) I actually think this one is pretty good, so I’m hanging on to it. It focuses mostly on HCI, but it gets referenced a fair amount.

Well, that’s it – I hope it’s useful. If you have any suggestions for additional books, drop me a line, especially if they deal with topics beyond product design. I’d like to keep the list trim: for every book here, I considered and dismissed a couple of also-rans. I think the list needs a good marketing resource, but I’m having a hard time finding one.

If you buy any of the books, use the links above – I’ll get some green in my Amazon account, which I’ll use to hunt down more good reads.

How to debug a page

Part of the fun of producing web pages and applications is that we get to be medicine men: wave our hands, write some code, and suddenly the Golem springs to life. The truth of the matter is that we’re closer to Ed Norton’s character in the beautiful but mostly pointless movie The Illusionist. Behind every stage trick is a logical (and sometimes overwrought) explanation. The only real mysteries lie within our own hearts and desires, and we can master our environments by recognizing the distinction between mind and machine.

For my part, I am mystified by engineers who use cajoling as a debugging tactic. These are the people who talk to their dev environments like Han Solo, begging more speed from the Millennium Falcon: “C’mon baby, work for me… (screen refresh)… nooooooo! Why god, why?!”

The very term “bug” bespeaks a rational attitude towards the initially inexplicable. Software presents an extremely controlled engineering environment, making scripting bugs even easier to detect than the original moth in the vacuum tube. When a hacker anthropomorphizes or spiritualizes their product, they’re ignoring that useful fact, abdicating responsibility for their domain and retreating into a comfortably passive mindset where success is incidental rather than created. They join the unwashed masses.

Rather than stare at tea leaves or rely on emotional appeals, two faster, more effective approaches to debugging simple scripts:

1. Start at the beginning of the script, and follow along until it breaks.

This is how many debuggers function, and it’s easily handled by adding alerts (JavaScript) or trace (ActionScript) calls into your code, line by line. Eventually, you’ll hit the point where the function doesn’t alert the expected information. Typically, there’s a breakdown in a call to another object – it doesn’t exist, or you’ve handled scope badly, or it lives in an unexpected form.

This technique is less useful when you have many scripts or functions interacting simultaneously or nesting, in which case you may want to try the second approach…

2. Observe the buggy behavior, and list the possible causes.

This is the Sherlock Holmes method – assume that you’re assuming something incorrect. This is an inverse approach to the first one: start at the broken output and work your way upstream. Define the buggy behavior and list all of the possible causes for that behavior. The trick is not to think within the constraints of the script as you understand it: instead of thinking “what could I have done to turn the screen blue?”, try “what are all of the possible ways to turn a screen blue?”

This is a great method for debugging CSS: IE is unexpectedly in quirks mode, an unexpected style rule is affecting a DOM node. It’s also useful for more complex UIs where multiple scripts are present. It’s not as useful when there are a lot of possible causes for the phenomenon (as in with a blue screen on a Windows machine).

That’s it. The theme between the two techniques is that you iterate through enlarging and reducing a list of possible causes until you strike upon a solution. No magic there, just a simple list edit.

Next time you see a bug, instead of wondering about the morality of the situation, pause and think “now how could that happen?” Usually, there’s an extra factor that you didn’t anticipate in your controlled environment. Identify it, change it, and listen to the peasants ooh and aah.

Live Reggae in New York City!

On Saturday, 9/23 my brother Wil’s band Dubconscious from Athens GA will be playing at the Lion’s Den in the Village.

Dubconscious has been touring nationally, putting on shows with the Wailers, Burning Spear, and other big reggae names. If you’ve met Wil then you know he’s a cool guy, incredible guitarist, and the man who named and raised Mystery Dogg.

Know anyone else who likes reggae, dub, jam bands, or has a large mailing list? Please forward this invitation along.

Boring Interfaces May Be More Effective

Catching up on Jakob Neilsen’s articles, I came across this piece on users’ reading patterns. This is a good one to bookmark, so you can easily explain to someone why “clever” section headings aren’t generally a good idea. If a heading doesn’t clearly explain the content’s value, the user moves on pretty quickly.

It also raises questions about the trend towards placing site navigation along the right side of a page. I think it’s a good idea in blogs, where we can expect that a user is really only interested in the current article – don’t distract their eyes with a left-side list of links.

Give ‘Em What They Expect

I can hear the design hack saying “well, my site is deliberately different – we’re going to excite and engage the user with our avant-garde interface.” Prepare for an uphill battle to achieve that engagement, because ignoring the “F” means ignoring years of pre-existing experience, during which the user has been physically and cognitively training to perform an “F” scan on thousands of standardized pages.

Best Days to Send Emails: Saturday and Monday

Citing a report by eROI, MediaPost published interesting information today about email open and clickthrough rates. The findings? Weekends get the best open rates (37-38%, which seems extremely high to me).

I noticed that Monday also performed well, and that surveyed users preferred to receive email on Monday. I’d wager that the weekend open rates are primarily personal addresses, whereas the Monday open rates are primarily business addresses. Good data for product information as well as marketing – if you’re going to tell a customer about a new feature or release, make sure you send the message at a time when the recipient is likely to read it.

Hot Links

Lucy Schaeffer’s photography site is live. Lucy is my friend, so I’m glad her photos are so great or it would be really uncomfortable discussing her work. Phew!

SpiffyWebCo is a fun little collective of little people who are doing some small but cool projects.Keep an eye out, cuz we’re going to blow your mind. A little.

George Washington – who knew history could kick so much ass? No wonder he founded the USA in his spare time!