Recently I bought a pair of convertible cargo pants—you know, with legs that zip off to convert your pants into shorts. The detached legs are not quite identical, so the manufacturer provided L and R tags. Simple enough. What could go wrong?

Well, the manufacturer—Columbia—attached the L and R tags not to the legs, but to the shorts.

The left leg is marked “L”. I knew that.

You would think that at some point during the design and manufacture of these pants, someone at Columbia would have said, “You know, it’s hard to tell the detached left leg from the right, but anyone can look at a pair of shorts and tell which is left and which is right. The L and R tags ought to be on the legs, not on the shorts.”

Evidently, that never happened.

Before you suppose that the sewing factory simply put the labels in the wrong place, let me point out that the labels are designed to attach to the zipper pulls, and the zippers are most definitely designed to remain with the shorts.

That is a UX failure of the grossest kind. But does it deserve to be called stupid?

(When I was a lawyer, UX was an abbreviation for uxor, Latin for wife. Now it means User Experience. Feel free to make a joke out of that.)

Shortly after I bought the cargo pants, I replaced the entry locksets in our home. Our Kwikset units were ten years old and had corroded so badly you could barely get a key in the lock. I upgraded to Schlage locksets.

The function of a lockset, by the way, is to lock intruders out. Not to lock yourself out.

With these new Schlage locksets, you twist a little button to lock the door from the inside. If you then turn the handle to go outside, the button remains in locked position. So if you step outside to retrieve the morning paper, and the door shuts behind you, you are locked out. Every other lockset I’ve worked with unlocks the door when you open it from the inside.

The door is locked.

The door is still locked.

After spending 45 minutes locked in my garage, I decided to trash the Schlage devices and replace everything again.

Schlage locksets. UX failure? Definitely. Stupid? Possibly.

There is a bar down the street named O’Neill’s. As we all learned in school, those ’ marks are apostrophes. They curl to the left. The big illuminated sign for the bar says O‘Neill’s.

Well, at least they got the second one right.

Stupid? Quite likely. Illiterate for sure.

Our old clothes dryer had a buzzer that sounded when the dryer stopped. It was convenient and it worked. Our new Amana clothes dryer starts beeping long before the drying is over. It beeps and it beeps and it beeps. When the beeping stops, that’s your signal that the dryer has stopped. I couldn’t believe it when I heard it.

UX failure? Absolutely. Stupid? It damn well is.

But what has this got to do with software?

I posit this axiom: the bigger the company, the more vulnerable it is to stupid mistakes.

The failures I’ve mentioned are not the result of misjudgment by a single person. Columbia is a big company, as are Schlage and Amana. The bar is small time, but two businesses—the bar and the sign company— jointly committed the error. In pari stupido, as it were. There’s a huge difference between the mistake of a single person and the systemic ineptitude of an entire organization.

Stupid derives from Latin stupere, to stun. If you’re a big company, UX failures like those mentioned here can result only from mass cerebral paralysis. Reviewers and managers sitting stunned in their chairs, unable to act beyond a weak and fearful hand wave of approval. That’s what I call stupid.

Well, to be fair, maybe the QA chap was out sick that day, or thought the project was assigned to someone else. Still, big software companies command vast opportunities for error correction. Yet their slop and sludge is far more evident than the slipups of the small software shop, where like as not somebody edited that .xib at three o’clock in the morning. The quality and attention to detail in indie software never fails to amaze me, while—well, I really don’t expect quality from some companies any more.

Anyone can make a simple mistake. When those with responsibility fail to catch it, that’s a stupid mistake.

I happily assert that none of my software contains stupid mistakes.

As an unappointed spokesman for Google and Verizon, I would like to clarify our joint proposal for what we like to call “open internet.”

To summarize the points we made on our blog:

We are for net neutrality except for wireless. Which will someday comprise 100% of the net.

We are for net neutrality except for wireless because wireless is “still-nascent.” Because wired internet is like really, really old.

We are for net neutrality except for wireless because wireless is “more competitive and changing rapidly.” We realize some of you might have thought of that as an argument in favor of neutrality, not against it; however, most of you do not think about anything at all except porn and gambling sites (what we call “entertainment and gaming options”), so we’re pretty sure we can say this with a straight face.

Now, let us get technical. What about the concrete terms of the proposal?

Because we recognize that HTML “is the programming language of the Internet, which was designed over forty years ago by engineers who wanted the freedom to communicate from any computer, anywhere in the world. It enables Macs to talk to PCs, Blackberry Storms to iPhones, the newest computers to the oldest hardware,” we are posting our proposal in Flash.

“In providing broadband Internet access service, a provider would be prohibited from engaging in undue discrimination against any lawful Internet content, application, or service in a manner that causes meaningful harm to competition or to users.” Discrimination is OK as long as it is not “undue” and causes no “meaningful” harm.

“Prioritization of Internet traffic would be presumed inconsistent with the non-discrimination standard, but the presumption could be rebutted.” You might ask what it takes to rebut that presumption. We don’t provide that level of detail. We’ve only been working on this for five months.

Broadband providers are permitted to “prioritize general classes or types of Internet traffic, based on latency.” If a type of traffic is generally latent, we can throttle all traffic of that class, latent and non-latent alike.

Broadband providers will be guided not by FCC rules but by “best practices adopted by an independent, widely-recognized Internet community governance initiative or standard-setting organization.” If asked to chair and fund this organization, we will say Yes, out of patriotic duty.

Providers of broadband Internet access service can prioritize traffic that is “distinguishable in scope and purpose from broadband Internet access service.” We believe that statement stands for itself.

You might think that our proposal allows wireless broadband providers to do whatever the hell they like. On the contrary, they must “disclose accurate and relevant information in plain language about the characteristics and capabilities of their offerings, their broadband network management, and other practices necessary for consumers and other users to make informed choices.” Just as they have always done.

Thank you for giving me this opportunity to clarify our proposal. You now know what we mean when we said, “The minute that anyone, whether from government or the private sector, starts to control how people use the Internet, it is the beginning of the end of the Net as we know it.”

Pagehand.com has just released our second application: LaunchCodes, a utility that helps you open files in the creator code application rather than the default application.

I’ve written about my intense disagreement with the decision to drop creator code support in Snow Leopard. Fellow developer Patrick Thomson and I teamed up to produce a tiny, unobtrusive utility that makes Snow Leopard respect creator codes as God intended.

Our objective was to re-introduce creator code application binding without modifying or replacing any system components. Snow Leopard preserves creator code metadata (it must, because the same volume might be accessed by 10.6 and pre-10.6 Macs), so all the utility has to do is intercept the appropriate Apple event and send it to the application identified by the file’s creator code.

Because we refuse to tamper with the OS, our solution is not a drop-in replacement for the pre-10.6 behavior. When you right-click a file with an extension recognized by LaunchCodes, you see that the default application is LaunchCodes rather than the creator code application. And LaunchCodes doesn’t intervene in every double-click on every file; it works only with the extensions that you’ve assigned to it.

LaunchCodes has some features that the pre-10.6 behavior lacks. In fact, I like our LaunchCodes behavior better than the old behavior. The principal feature is that you can instantly turn LaunchCodes on and off via a menu bar icon. If you are engaged in a task where you really do want all files with a certain extension to open in the default app, just one click disables LaunchCodes and returns you to the standard Snow Leopard behavior.

Configuring LaunchCodes on a file extension basis might at first seem an annoying limitation, but in practice it’s a benefit. If two or more applications can open the same file type, it’s a sure bet that the file type is associated with an extension. As a practical matter there are very few extensions that present conflicts between the default application and the creator code application. Most people who complain about the lack of creator code support mention only one or two extensions that disrupt their normal workflow. For many people, configuring LaunchCodes to work with only one extension might be all they need to get Snow Leopard to present the same user experience they enjoyed with previous Mac operating systems. Keeping LaunchCodes out of the picture when it is not needed helps to maintain its tiny footprint.

Even if you like creator code application binding, there are times when it can get in the way. If you open files that were created by other users, as is common when accessing files on a server, you might not want to use the same application that the other user chose when creating the file. For example, if I like to create .html files in TextMate, and a colleague likes to use BBEdit, I do not want to launch BBEdit when I double-click one of his files. With LaunchCodes, you can confine the use of creator codes to files that you created; if this preference is on, and you did not create the file, LaunchCodes deems it to have no creator code and sends the file to the default application.

Finally, LaunchCodes lets you see the creator code metadata for a file. If a file opens in the default application instead of the application that created it, like as not the creating application did not set a creator code. (Alas, Apple’s 10.6 apps are guilty in this respect.) With LaunchCodes, you can see what is happening by option-dragging the file to the LaunchCodes application icon. LaunchCodes will show you the file’s creator code, whether you own the file, the application that will open the file, and the reason why that application was chosen.

We’ve priced LaunchCodes at only $4.95. A few aspects of development were surprisingly tricky, and the app required much more development time than I anticipated. I have no idea whether LaunchCodes will be a commercial success, but it’s already clear that a lot of people are very grateful to have it.

For the last few weeks I’ve been beta-testing my friend John Eddie’s iPhone app, Years. It’s now been released. I recommend it.

Years quickly became the iPhone app I use most frequently. I hadn’t realized how often I simply want to look at a year’s calendar. Not a month, not a week, not a bunch of detail about appointments, but just the current year, scrolled so today is in the middle.

That’s exactly what Years does. It defaults to the current year, and allows you to view other years. There’s a month view where you can scribble on a date to mark it.

Years points up the problem with most calendar apps: they do too much. There’s no end of enhancements you can add to a calendar: appointments, alarms, view as list, and so on. Those are useful features and I’m grateful that Calendar provides them.

The brilliance of Years is its restraint: it recognizes that most of the time, I just want to look at a calendar. Apple’s Calendar app displays at most one month at a time, so I frequently have to flip between months. It’s not really a calendar, but rather an appointment book.

Years reminds us that some useful things work best when they remain simple. How many weeks until Christmas? What day of the month was last Friday? How many days until we leave on our trip? That’s the sort of question I ask every day, and the answers have never been as easy to find. With Years, there’s no punching around to get the correct month and layout. It just pops up the calendar I want.

I wonder how I got along without it.

Funniest thing I’ve read recently: today’s letter to the editor from a guy complaining that our local paper is too liberal:

In a little over two months, President Barack Obama’s administration committed more missteps and faux pas than in all of Bush’s eight years, yet hardly a word of this is mentioned in your paper. If it wasn’t for Fox News, I wouldn’t have known about it.

For the past four years I have been engaged pretty heavily in developing a computer application. A typical day, seven days a week, finds me at work shortly after I’ve finished reading the morning paper, and still programming ten hours later.

During this period I have grown familiar with trained and experienced Mac developers. I follow their blogs and tweets, and meet up with them at conferences. As I continue to know and understand developers, I find myself comparing them to the other profession that I know fairly well: lawyers.

I practiced law for twenty years or so. Happily, I am now fully recovered. The lawyers that I knew were without exception trained in the law (well, they had three years of law school) and many were quite highly experienced. You might think that with all that education, and all that mental exercise, lawyers as a whole would be fairly smart. Maybe they are. All I know is, Mac programmers are smarter.

Most of the Mac developers I know have a computer science background, but it is not at all unusual to find one who, like myself, is self-taught. One cannot say that programmers are smarter than lawyers because programmers are better educated. Yet on the whole, when I think of the conversations I’ve had with members of the two professions, the programmers seem altogether more articulate, better informed, and more adept at reasoning to their own conclusions. I had much rather talk to programmers, on any subject, than to lawyers.

As for myself, well into middle age, my logical faculties seem to be increasing. I’m slower, but sharper than I ever was. The thought struck me this morning when I remembered a dream I had last night. I was running along a beach, being chased by a pack of angry savages. I outran them and paused to ponder their next move. “Spears and arrows,” I thought. “What can I do for protection against the incipient barrage of spears and arrows?” I spied a thicket, and crawled into it as the projectiles became tangled in the brush over my head. Then I thought, “They know where I am, and will track me by my footprints. How can I escape from this spot without leaving footprints?” Then I remembered the beach. “I’ll swim!”

Whether the pursuers would have seen me in the water was left unresolved. What is clear is that in this dream, I stopped to reason things out. This dream is not at all unusual. I realized that these days my dreams are more likely to place me in a situation where I have to think my way out, than to place me in a situation where I merely observe events.

Is that a consequence of the type of thinking I’ve been doing lately? I certainly never had such dreams when I was practicing law.

And here, I posit, is why. We expect computers always to produce the same result for the same input. There are few, if any, anomalies; if something unexpected happens, then it’s a bug and we fix it. The operating system or the network might not provide the result I expected, but it will always produce that result, and once I know the result I can deal with it.

In law, anomalies are commonplace. Two judges, both competent (just imagine, if you will), might rule differently on precisely identical questions. Tomorrow they might rule differently. I remember one day early in my career when a lawyer in motion hour made the same argument I was going to make in my case. He won. When my case was called, I made the same argument and lost.

I think that if judges were as predictable as computers, I would have been the sharpest lawyer in town.

Over time my professional judgment improved, but I never worked in a cycle where I proposed a solution, evaluated the result, and proposed another solution until I got it right. Many times I knew beyond question that a proposed law was unconstitutional, but no court in the state would be willing to strike it down. I was a better lawyer for knowing that, but not any smarter.

I learn more in one day of programming than I learned in six months of practicing law. I learn how to think through problems and how to reach the true solution rather than just finding something I can argue with a straight face.

This entire essay is mere subjective speculation, and I am blithely unobligated to cite corroborative facts. Form your own opinion whether programmers are, on the whole, smarter than lawyers. For me, there’s no doubt. You’re a lawyer? Nice to meet you, but I really have to be going. You write Mac software? Come on over, I’ll buy you a beer.

When I was in high school, my buddies had a simple test to tell when we’d had too much to drink. If you could could recite the quadratic equation, you could have another beer.

Whether the test kept us sober I can’t recall, but it did drill the incantation into my memory: “negative b plus or minus the square root of b squared minus four a c all over two a.”

If I ever knew what you would use the equation for, it quickly faded along with a thousand facts like the population of Guyana, retained only for the duration of a geography test. Over the years, though, I’ve caught myself checking my mental state by reciting the quadratic equation, so those words stuck, like the first stanza of “O Captain My Captain.”

Yesterday I needed to convert a linear scale to a logarithmic scale. I’d set up an NSSlider control that allowed the user to select values between 0 and 1. I wanted to weight the values so that the halfway value would be .75 instead of .5, the three-quarters value would be .95, and so on.

After some trial and error I found that I could get the logarithmic scale I wanted by taking the slider’s value x and running it through this formula:

y = x + x * (1.0 – x)

That’s exactly what I wanted: the slider values 0, .1, .2, .3, .4 .5,.6, .7, .8, .9, and 1.0 came out as 0, .19, .36, .51, .64, .75, .84, .91, .96, .99, and 1.0.

Then it dawned on me that I also had to perform that operation in reverse.

At first I was totally bewildered. I tried rewriting my little formula to get x on one side by itself so I could solve for it. No luck. y = x * (2.0 – x), y = 2x – x squared, -y = x squared – 2x; I just couldn’t come up up a solvable expression.

Then I remembered the quadratic equation.

Hmm. I tinkered with my formula and got it into the form 0 = x squared – 2x + y. Aha! In the quadratic equation, a would be 1 (the value that you multiply times x squared), b would be 2, and c would be my y value. I could then solve the quadratic equation and get x.

A little tinkering with the quadratic equation reduced it to this: x = -(((square root of (4.0 – (4.0 * y) )) – 2.0) / 2.0). Imagine my joy when I plugged in the logarithmic y values I had calculated earlier and got the linear x values.

I learned the quadratic equation as a sophomore in high school. That was thirty-nine years ago. I’d never encountered a practical application for it until yesterday. I guess high school taught me useful things after all.

Now, excuse me while I go look up the population of Guyana.

In Microsoft’s description of their Open Specification Promise they state:

We listened to feedback from community representatives who made positive comments regarding the acceptability of this approach.

Because the sentence implies that they didn’t listen to feedback from representatives who made negative comments, I’m inclined to believe that the omission of a comma after “representatives” was deliberate.

What a week! Who would have thought a hurricane would knock out power in Louisville for 2 weeks?
Read more »

I had everything installed, and decided I wanted to look at the crud in my Applications menu with a view to removing it. I started with Adobe Stock Photos.
Read more »