Archive for the ‘General’ Category

Phone Wars: iPhone 4 First Impressions

Tuesday, July 13th, 2010

As long-time iPhone owners we’ve done our share of railing against AT&T. Time to put our money where our mouth is. We’ve ordered an iPhone 4 (with AT&T) and a Droid Incredible from Verizon. In 30 days we return one. Two phones enter…

We’ve had the new iPhone for three days now. Since there are plenty of full reviews elsewhere, I’ll restrict myself to a few highlights.

It’s fast. Fast, fast, fast. I cannot overemphasize how important this is. Presumably it’s a combination of the faster processor and the pseudo-multitasking, with an emphasis on the former. (I am upgrading from an iPhone 3G whose iOS4 upgrade slowed it to a crawl.)

The new screen is beautiful. It’s evolutionary, but the type of evolution that feels revolutionary because it makes such a difference. I was doing my Kindle reading on an iPad, but the crispness of text on the iPhone 4 has switched me back to it. In some ways it feels like a different technology.

The hardware is not as dramatically different from previous generations as Apple would have you believe, but nice, compact, clean-looking. It’s a little harder to pick up because of the square edges.

The best news is the signal. Reception is definitely better in San Francisco – and the Mission in particular. It’s possible to make calls in our apartment and to load data on the street, though it’s still spotty. Whether that’s the device or AT&T’s ongoing improvements is unclear: we know they’re adding towers, and our iPhone 2G seems to be doing a bit better as well.

Then there’s the much-discussed antenna issue. It’s real, not simply cosmetic, and confirmed by Consumer Reports. (Mini-rant: the frustrating part is not the hardware problem, but Apple’s all-too-typical response ranging from, “What problem?” to “You’re the problem.” It takes a special brand of arrogance to deny something so easy to reproduce.)

Otherwise…well, it’s an iPhone. Overall a delight to use, irritatingly locked down at times, occasionally annoying. The Droid should be arriving soon…

Trade-offs

Wednesday, June 30th, 2010

Great products require trade-off. Which features should you promote with big, glossy buttons? Which materials or technologies should you use, and at what cost? When should you release it? How heavily should you test it first? Should you fix a crash bug that affects 2% of users or a cosmetic bug that affects 90%?

These trade-offs are unavoidable. If you don’t make them explicitly, you make them implicitly. Can’t decide which feature get a big button? You can create ten buttons but you’re making another trade-off: each will be a little less prominent, and your product’s simplicity and elegance will suffer.

Trade-offs are necessary at every stage of the product lifecycle:

  • Apple is often praised for simplicity. Less is more: remove all the physical buttons and do the rest in software. But that’s not the whole truth. The iPhone has two volume buttons, a power button, a Home button, and a ringer switch. Only the power button is necessary. Someone made a trade-off, sacrificing a certain degree of simplicity for the convenience of four more buttons. The result may, in fact, feel simpler: without taking the phone out of my pocket I can adjust the volume or set it to vibrate. What we call simplicity is, in fact, a successful trade-off.
  • Facebook has repeatedly favored speed over caution, angering users by releasing features and design changes (e.g. the newsfeed) without vetting them thoroughly. Many look to the resulting uproar as a cautionary tale, but I believe this is the wrong lesson. At worst, Facebook’s tremendous growth has proceeded in spite of these choices. But I suspect Facebook has succeeded because of them: by trading speed for pre-release research and by making sure they can correct course quickly, Facebook has innovated, stayed ahead of the competition, and gotten free user research in the bargain.

Make no mistake: trade-offs are hard. They require sacrifice. They require risk. But then, it should come as no surprise that these qualities are needed for great product design as well.

2009 Co-Worker Feedback for Maggie

Saturday, January 16th, 2010

Strengths

Maggie is an enthusiastic office manager with a keen interest in the details of what goes on around the apartment. Her broad range of interests is perhaps her strongest asset – from tackling tissue paper to folding laundry to changing the sheets to whatever seems to be going on under the stove, her passion reminds us not to take the details for granted.

Maggie sees tasks through to their completion. For example, on several occasions I’ve seen her work late simply to defend a pile of laundry from being worn or put away. This drive to go above and beyond the call of duty – and indeed beyond what anyone actually wants her to do – is admirable or possibly irritating.

In recent months Maggie has focused on developing an extremely fuzzy winter coat. While the associated shedding can be problematic, the entire team appreciates the resulting increase in cuddliness.

Development Areas

In 2010 Maggie should work on her periodic tendency to become confrontational. While I admire her passion, I would encourage her to find a more effective and professional outlet than leg-biting or drive-by swatting.

In past peer reviews I’ve commented on Maggie’s progress in lap-sitting and purring; in 2010 I’d encourage her to build on those skills and turn her attention to hugging.

Maggie would also do well to cultivate team-oriented traits like staying off the table, vomiting only on non-porous surfaces, and increasing her “face time” by restricting incessant meowing to normal business hours.

Additional Comments

It’s been a pleasure working with Maggie over the last ten years, to see her grow professionally and socially. While her performance in 2009 was excellent, I am not yet convinced she will reach her overall career goal of remembering what she was doing ten minutes ago.

Clarifying Mac App Installation

Sunday, August 31st, 2008

Installing applications on a Mac can be confusing. Anecdotally, I’ve observed friends and family struggle with it, and it makes sense that they would. Luckily, it doesn’t have to be that way: app developers can make it easier, though few have.

Background

Traditionally, software applications are installed via an installer: a script that copies files to your computer and performs any configuration necessary to get the app up and running. Typically (and especially on Windows), files are dumped all over your hard drive. The program itself, yes, but also various supporting files: help files, images, libraries, etc. Deleting one of these files may cripple the application. To remove the app, you need to know exactly what was installed or you need an uninstaller.

With Mac OS X, Apple introduced application bundles to improve this situation. (Actually they were introduced with NeXTSTEP several years earlier and OS X inherited them.) An application bundle is a specially structured folder that looks to the user like single file. If you’re a Mac user, you can see what I mean: open your Applications folder and Ctrl-click (right-click) on an app there such as iCal or Mail. Select Show Package Contents and you’ll see what the app is made of.

Why is this important? Because now a double-clickable app can contain all its supporting files. Installing an is as simple as dragging it to your hard drive. To uninstall, drag it to the Trash. And applications are less fragile: because they’re self-contained they’ll run from anywhere (not just Applications), and the chances of destabilizing an app by deleting a depenency are low.

Current Practice

Since apps don’t require an installer, the simplest way to distribute one is simply in a zip archive. Unzip it and you’re done. If you drag to /Applications, great; if not, it’ll still work. Many apps are indeed distributed this way.

However, the de facto standard is to put the app on a disk image, compress the disk image, and distribute that. It’s also  standard to include either an image or an alias of /Applications to indicate the need to drag the app there.

Disk image window with drag-and-drop cue

Disk image window with drag-and-drop cue

There are several advantages to this approach:

  • You can distribute auxiliary files (plug-ins, extras, manuals) without dumping them all on the desktop or obscuring the app in a folder.
  • When the disk image is mounted its window can open automatically, providing helpful feedback to the user.
  • It enforces the idea of dragging the app to /Applications.
  • It allows you to present a license agreement to the user when the DMG is mounted.
  • You can include branding in the DMG’s window.

The Problem

The trouble is, this approach works too well. Because apps can run from anywhere, a user can launch the app from the mounted DMG, resulting in the following scenario:

  1. A user downloads your app.
  2. He double-clicks until the app appears in a window (that of the mounted disk image).
  3. Accustomed to installers or just to double-clicking on things to make them go, he double-clicks. Or, he drags the app to the Dock and clicks on it there.
  4. The app launches. Everything is great.
  5. Later, the user restarts his computer. The Dock icon turns into a question mark and the app’s window disappears. The user is confused and sad.

In other words, if a user misses or misunderstands the drag-and-drop cue, everything works so well that he fails to install the app, causing confusion later on. And it’s not a far-fetched scenario: many apps do still use installers and double-clicking on things tends to work. People’s visual focus can be very narrow, so some users will certainly miss the drag-and-drop cue. Aliases are arguably somewhat of an advanced concept, so the idea of dragging the app from one place in the window to another may not make much sense; and users who interact with apps exclusively via the Dock may not know the location or role of /Applications.

Luckily, this problem isn’t hard to solve.

The Apple Solution

The ideal solution would probably come from Apple. With Leopard (Mac OS 10.5), apps launched from DMGs already produce a warning:

OS warning when launching from a DMG

OS warning when launching from a DMG

Apple could simply replace “Open” with “Install” and copy  to /Applications before launching:

A revised launch-from-DMG dialog

A revised launch-from-DMG dialog

A context menu item or modifier-click would allow advanced users to run directly from the DMG. References in the Dock would be updated as well.

The Developer Solution

Of course we can’t rely on Apple to implement this. Nor do we have to. In the absence of an OS-level answer, individual vendors can provide the same functionality themselves.

How aggressive should vendors be? Delicious Library – which is not distributed by DMG – prompts users when the app is anywhere outside /Applications:

Delicious Library's launch dialog

Delicious Library's launch dialog

The disadvantage of this broader approach is that it must be presented as a warning or choice rather than a natural part of the install process. By only prompting for DMG-launched apps, we can make it a simple (and expected) “Proceed with installation?” confirmation rather than a more complex “Should I put this someplace else?” choice. And while Delicious Library’s prompt keeps a user’s desktop clean, it’s an extra and entirely optional step: downloaded apps scattered all over the desktop may be irritating to some, but it doesn’t prevent the user from launching them.