Shirt Pocket Watch

When I left Windows for the Macintosh years ago, there was one thing I didn’t count on: there are no good personal finance programs available for the Mac.

Yes, there’s Quicken 200x, and I tried it for six months (and have looked carefully at every version when released, including the latest minimum-changes-required 2006). But, it’s a pale reflection of its PC version, and is kind of old and clunky to boot: it clearly has “OS9 port” and “1998 feature set” written all over it. Which is too bad—Mac users deserve better.

Now, it’s very possible to do a good job with a program that was originally written for OS9: see BBEdit, for example. (Hi, Rich!) And while I’m a big Cocoa fan, Carbon isn’t the problem—there are plenty of ugly, clunky Cocoa applications. The problem is that Quicken is old and under-featured, especially when compared to similar applications on Windows.

So, I’m stuck with a boat anchor: Microsoft Money.

For years (1985-1999 or so) I used Quicken, starting with Quicken for DOS (I was actually one of the testers, way back, and I’m even in the manual for one of those old versions). But, around 1999, Microsoft got serious about making Money decent, while, at the same time, Intuit lost its way. When my Quicken database got corrupted one time too many, I jumped ship.

Money’s actually a pretty darn good program, and while I have various quibbles with some of the recent choices they’ve made—it’s pretty clear that much of their charter is to drive people to the MSN Money site, and the designers have never tried to use Money on a computer with a less than 1024x780 screen (they’ve surrounded everything in the last two versions with so much blank & wasted space it’s driving me insane)—I’ve been happy with it. Its investing tools work well (the portfolio view is excellent), the bill functionality is good, as is budgeting and the various other things I do. And, the Small Business Edition does a reasonable job of printing invoices and the like when I need to do that.

Its only problem: it’s not available for the Mac. So, I keep a PC around (at present, a Motion Computing LS800 Tablet PC), to check out what’s going on in that world (I’ve always been interested in Pen-based computers), and to keep Money running.

(Of course, I can’t just run Money. This is Windows: I also need a huge fleet of anti-virus, firewall, anti-spyware and other programs. Whee.)

So you gotta do what you gotta do: the ship sails on, dragging its anchor behind it. But, mostly, it’s a good ship, Macintosh.

The Pavlov’s Beep post got me thinking a bit about how user expectations can set a product up for failure out of the gate… and that made me think of the late, lamented (by some), lambasted (by many) Newton.

Ignoring the obvious hype surrounding the rollout—something the product could never live up to—one of the things that was coolest about the Newton was also the thing that caused the most frustration: handwriting recognition.

Handwriting and speech recognition are two areas that have seen a lot of advancement in the past years—for example, the recognizer that comes with Windows XP Tablet PC Edition 2005 Elite Pro Extreme (or whatever that product is called) is exceptional, and from all reports is improving in its next iteration. And, according to those who use these things routinely, like David Pogue, the latest Naturally Speaking (ex-Dragon, now ScanSoft) is similarly surprisingly accurate.

All that said, though, they’re doomed to teeny market segments, because no matter how accurate, when they make mistakes they frustrate their users.

Why? Because we’ve asked the computer to play by our rules, rather than asking us to play by its.

When a device imposes an unnatural input method on its user, any mistakes you make are your own. Consider Graffiti, as used on Palm OS: it specifically requires you to make certain “letter shapes” if you want them to be recognized. It doesn’t try to recognize your handwriting. If a letter comes out wrong, you might be frustrated, but you know it’s “your fault”—you didn’t make the shape right.

But, with the Newton, it was supposed to recognize your handwriting. Not an alphabet of its own design. And, when it doesn’t, the first thing that runs through your head is: this thing sucks! Even if it got 90% right, which is pretty remarkable considering many people can’t read their own handwriting!

Speech is hard, too—especially if used in an “unrestricted vocabulary” scenario. Not only do you have to “speak” all punctuation (try it sometime), but correction is an incredible pain. And speech is such a natural part of most people’s daily interaction that it’s near impossible to rise to an acceptable level of performance.

Newton, near the end of its life, tried to get around this problem by taking a bit of a Graffiti approach: it encouraged people to print, and there’s a lot less letter variation in printed characters. Suddenly, with the new Rosetta printed character recognizer (still in use in Mac OSX today), people started saying the Newton did a good job recognizing handwriting when—in actuality—it just shifted the burden onto the user some more by restricting input.

Similarly, speech is becoming more common in situation where the vocabulary is highly restricted and expectations are low: package tracking #s; pick 1-2-3 menus; interacting with “speed trade” stock systems. Correction is pretty easy and, given the relatively robotic nature of the interaction, expectations are low. (You’ll note that as the systems got better, they started using more animated, natural voices at the other end—raising expectations they knew, from testing, they could meet.)

So—if you’re designing a UI, remember that the way you “frame” the interaction often sets user expectations.

Leaving aside speech and handwriting, free form input can be really, really cool—see Simson Garfinkle’s SBook and Microsoft Outlook’s date/address fields for examples.

But if you put up a free-form field , you better make damn sure that it accepts all sorts of wacky variations. If date-based, expect things like “tomorrow”, “next wednesday”, etc—every one you miss, given the free-form nature of the field presented, is the fault of the program, from the user’s perspective. Similarly, what about international addresses? And how do you tell the user you’ve made the inevitable mistake?

A lot of words to say something obvious, I know. But it’s a mistake I make all the time… e.g. “Safety Clone”…

Once again, I’m really happy to announce that a Shirt Pocket product has gone all gemilicious!

netTunes was just reviewed by Dan Frakes of Macworld Magazine, in the Mac Gems section.

netTunes 2.2 was awarded 4 mice—and also mentioned, in another recent MacGems column, as “the best solution, by far”!

Not too bad for my first Macintosh product… not too bad! 

Thanks, Dan!

In the first Bang & Olufsen multi-line cordless phone system—the 6000 series—the designers and developers clearly had a problem. Basically, when you picked up the phone, it took a while to actually “connect”, something on the order of .5 seconds or so. Long enough for the user to get out a “Hello? Hello?” and to feel pretty stupid about talking to empty air.

I wasn’t there, and don’t know, but I’m certain that when this went to testing, users screamed bloody murder. Phones are devices with very set behavior, and when things don’t work properly, it’s instantly noticeable.

I can imagine the engineers’ reaction when this came back to them: but there’s just no way to make it go any faster, given the hardware we’re using! It just can’t!

Back in the 80s, when my company UnderWare was doing BRIEF (a programmer’s editor of some renown back then, and my first commercial endeavor), we were in a similar situation. We had a certain percentage of people who were complaining that writing files was just too slow.

Mike and I went over the file writing code over and over, and—without resorting to going direct to the hardware, something we just weren’t going to do—there was just no way to speed it up any more. This stuff was working as fast as the system would let it work.

So, we thought about it. And thought about it. And, finally, came up with a solution.

Since we couldn’t speed it up, we did the next best thing. We cheated.

BRIEF had a “status line”—a quaint bit of information at the bottom of the window that was all the rage back in the Olden Days—and, before cheating, it would put up “Writing file...” and then, when completed, it would say “File written.”

So, I changed it to write out the percentage it was through the process. Which, if you think about it, actually made the whole thing slower.

And we never had another complaint about write speed.

And what did B&O do? They added a “beep” when it was time to talk. Just a little thing, but after the first time, users started waiting for it (and, no doubt, blaming themselves for not waiting, rather than blaming the phone for being slow to beep).

Bingo. Problem solved.

Sometimes the solution to a problem isn’t really a fix. Sometimes, it’s whatever works.