The shortest distance between two points is a straight line. This is one of those darned Euclidian facts of life. Of course, it’s only fact in a paper life. Everywhere else, it’s an exception. In real life for instance, things get in the way.

The shortest path is only useful if it’s both possible and expeditious to follow that route. On paper the shortest path always takes the same amount of work. We drag the stylus against the straight edge. Nothing hinders our progress in two dimensions, except for the possible breakage of pencil lead.

In real life, everything gets in the way. So the shortest path is only useful to the extent that it provides a line of sight. Something we can aim for, even as we twist and turn in ridiculously off-course directions to reach the destination.

Something I’ve been meaning to do for a number of years is to learn how to sail. This year, late in the summer, I finally got started with that endeavor. I joined Boston’s Community Boating, Inc., where kids can learn to sail for a mere US$1, and adults can buy a year’s membership for less than US$200. Learning to sail must be a lifelong process, and I’m just a newbie. But even after a week on the water, I was impressed by one of the fundamental facts of sailing. You can sail in almost any direction except for straight into the wind. I find it amazing that you can actually harness the power of the wind blowing straight at you, and turn it into energy that propels your boat sideways, or even sort of towards it!. The bad news, of course, is you can’t always sail straight towards your destination. If you want to travel towards the wind, you’re out of luck:

When you’re sitting out in the middle of the Charles River collecting sailing experience and a sunburn, this is a pretty profound lesson. The shortest distance between two points is not a straight line, when a straight line is impossible!

Fortunately for sailors, there’s an easy workaround. It only takes a little bit longer than a straight line, and it has the major advantage of being possible. You simply achieve your destiny by traveling away from it until it is achievable by a straight line:

The cool lesson from this fact of sailing life is that by merely changing your position in any direction you may alter the viability of your goal from the impossible to the possible. If this little observation were only true in sailing, it would hardly be worth mentioning in my blog. But some version of this “wide angle shortcut” applies to almost every obstacle you’re liable to encounter in life. In fact, if you think about the ways we reach our various destinations, it’s almost never by straight line. We’re accustomed to twisting and turning, yet when we step back and aim for a goal, we’re foolishly obsessed with striving for the shortest path!

Let’s say you’re walking through the woods and you come upon a steep incline. The best thing to do might be to climb straight up, but in all likelihood you’d be better off going around. Going up and over might even be impossible. This concept becomes truer and truer the more limitations there are on your mobility. Take railroads, for instance. Railroad track must be set on fairly level ground. Trains can’t just jump over a mountain. So when the early railroad pioneers sought to lay track across the American continent, they had to compromise. Big time. In fact, choosing to take the longer path was an act of brilliance. A good example of this is the Rocky Mountaineer Railroad, which connects Calgary and Vancouver. Let’s see. How can I represent this without violating some copyright. I guess I’ll do a crude representation:

The red line represents the shortest path, but the green line represents the shortest possible path! The path the railroad had to actually take to stand a chance of reaching its destination. You’ve got to contend with mountains, my friend. So the next time you face a formidable problem, when something stands in your way and pushes against you with all its might, consider taking a different route. An oblique route. It’s how the greatest thinkers in history have reached their destinations, so it’s probably good enough for you, too.

Relaunch is a nifty application that lends itself toward structuring your time into working “modes.” It lets you save a snapshot of your running applications at any time, and save it for later restoration. So you could keep Relaunch documents around for “Work,” “Composing Music,” etc. It even has a nifty auto-snapshot feature that will keep track of your running applications on an ongoing basis, automatically storing the details into timestamped files. I’m not sure how useful this is, but it’s kind of cool to think that you could go back and see “what was I running last Tuesday at 3:00 PM?”

Relaunch also supports, for a limited number of applications, the ability to automatically reopen all the documents you were working on in that application. As of version 1.3.4, FlexTime is among the applications with this support! So now you can use Relaunch in conjunction with FlexTime to really add structure to your day.

This application has a lot in common with the “Focus” idea I blogged about recently. The fact that the author is using AppleScript to support integration with other applications is a really good indicator that we’ll see this product evolve in remarkable ways.

Replacement passenger side window … $50

Eight minutes sucking glass with the gas-station vacuum … $1

Identical TomTom Go 300 on eBay … $305

Shipping & Handling … $15

Getting your life back to normal after some eff-wad messed it up … priceless!

Paying for it with PayPal funny-money instead of VISA … extra-priceless!

The resumption of normalcy was not nearly as expensive or time-consuming as I feared it might be. Ten days from damaged to repaired. I was also glad to see that my replacement came with a box and accessories that were not in my car at the time. So at least I know I’m not buying back my stolen unit! (Though that would have been fun in its own way).

My summary of C4 includes what I think are the main points from John Gruber’s “HIG is dead” talk. (For those who aren’t famiiliar, HIG stands for Human Interface Guidelines, and is a long-lived and ever-violated prescriptive document from Apple). In that entry, I forced myself to (mostly) reiterate what I took away as the intended messages from the various speakers. But these guys got me thinking, and I’d like to expand upon my reaction to some of the most interesting ideas. I’ll start with Gruber.

Is the HIG dead? I don’t know. But Gruber’s talk was thought-provoking, and I’m feeling pretty convinced right now, high on sleep deprivation and freshly returned from the fray. At the very least I think it’s time for us crotchety old engineers indoctrinated by System 7 or earlier values to mellow out a bit. I got so used to defending the party line for so many years, that I stopped questioning whether it was worth defending. Taking a step back now, I have to wonder why none of us, noticing that Apple was “constantly violating its own HIG,” stopped to consider whether we were the suckers for being so hung up about these problems on their behalf.

I’m picturing some Rowan Atkinson character standing alone on a sinking boat, foolishly but adamantly refusing to bail water as his knees, and then waist, succumb to the rising tide. “Queens order! Bailing shall not be performed by officers! Somebody bail this water at once! That’s an order!” He’ll die, but he’ll die having been right. Is that your fate?

Cry all you want, but the ship is sinking. Gruber presented two high-level alternatives for dealing with this situation, so that we continue to produce mechanically and visually beautiful applications (paraphrased, again because I have no notes):

1. Synthesize an implicit HIG based on prevailing standards.
2. Do your own thing with gusto.

But these are optimistic instructions. They only cover the decisions that lead to a beautiful app. By putting the choices into a context where the ugg-tastic choices are also visible I think we can learn something, and obtain some calm in the face of these “changing times.”

I propose that Mac developers have always been neatly divided into two groups: those who give a damn at all about HIG, and those who don’t. You know which group you fall into! I further propose that this high-level differentiator neatly and naturally directs developers towards either Gruber Choice 1 or 2. And never the twain shall meet:

• Developer gives a damn at all about HIG:
1. Follow HIG to the letter (knee-tastically ugly result).
2. Synthesize an implicit HIG based on prevailing standards (beautiful result).
• Developer could care less about HIG:
1. Leveraging X-Windows, Java, and tcl (ass-tastically ugly result).
2. Do your own thing with gusto (beautiful or ass-tastic result).

Extemporaneous charts don’t lie. Obviously you can make beautiful applications whether you believe in the HIG or not. But most of us prefer to play it safe, and don’t have the confidence to do our own thing with complete gusto. So for most of us the decision is the same as it’s ever been. We believe in the HIG because it helps us make decisions, but we also recognize that changing tides require changing our own personal rules about these decisions.

If you’re a developer who gives a damn at all about HIG, then you’ve already been either following it to the letter or synthesizing an implicit HIG. The only thing that’s changed now is the sheer amount of adaptation that may be required in formulating this implicit HIG. There’s a lot more work adapting to the current tides. Bail faster, peon!

Those charmed and beautiful people who can do their own thing with gusto and obtain beutiful results … bastards! I mean, more power to them. But they’ve always been doing it and getting away with it. They were doing it on System 7, in their own special way. They’re more resilient to the changing implicit HIG, because they choose not to abide by it. Only those of us (the masses) who rely on some form of HIG advice need to adapt furiously in times like these. And the first step toward a successful adaptation may be, as Gruber suggests, recognizing that the world is comfortable with all kinds of freakin’ buttons. And gradients are good, mmkay?

Feeling glum about the implicit HIG? Don’t worry – unlike the real HIG, this one is a sliding scale arrangement. It’s a sort of “gusto and beauty” plan with a safety net. You only adopt as much from the prevailing standards as you feel comfortable with. And if you mess up and end up erring too much in the direction of “HIG to the letter,” well things could be worse. You could look like an ass-tastic Java app. And when some crotchety old-timer challenges your UI and claims it doesn’t comply with the HIG, you can be Apple for the day and smugly reply: “it complies with my damn HIG!” and get back to work.

Update: Scott Stevenson and Michael Tsai have each written thoughtfully about this in their blogs.