Friday evening repeated a now-familiar but still-irritating interaction with my manager. He wanders into my office to inquire about a defect on which I’d been working. (For those not deeply geeky and to keep the technicalities from distracting, I’ve replaced the actual terms with placeholders.)

ME: The foozle impinges on the moof which in most cases fires the spryck.
HIM: The foozle?
ME: Yes.
HIM: Impinges on the moof?
ME: Yes.
HIM: Why does it impinge?
ME: I don’t know.
HIM: But that makes no sense.
ME: I know.
HIM: But why?
ME: I didn’t write the code: it’s from before I started working on this codebase.
HIM: Most times fires the spryck?
ME: Yes.
HIM: Why not all the time?
ME: I don’t know.
HIM: Are you sure the foozle impinges?
ME: Yes. Every time.
HIM: But why?
ME: I still don’t know.
HIM: We have to change the foozle to bypass the moof and fire the spryck every time.
ME: Good idea. But it may take some work.
HIM: Why? It should be simple.
ME: Because the chungong depends on the foozle and we need to make sure changing the foozle doesn’t break the chungong.
HIM: Why does the chungong depend on the foozle?
ME: Because it does.
HIM: But it shouldn’t need to.
ME: But it does.
Et cetera, et cetera, …

His instinct appears to be to challenge all data presented to him. Whilst I agree that data used to make a decision ought to be defensible, having one’s results consistently challenged feels like being a shot messenger. Messengers who get shot have a strong incentive to stop delivering the messages.

As I complained about this to my spouse, I got the eye-roll that said, “Look who’s talking, mister”. I make the distinction, perhaps a fine point, that I only challenge factoids that fail the laugh-out-loud test like, say, anything heard on Oprah. But I will concede that perhaps she might feel like it’s the same thing.

But it’s not. I’m skeptical of hearsay, even if it comes through my spouse. At work, though, it’s not hearsay. I’m quite literally a trained professional. Treating my results with skepticism puts my work in the same class as hearsay. ‘Tain’t no outrageous fortune, so keep your slings and arrows to yourself, eh?

A few moons ago I noticed that my application (at work) had a certain behavior: if the focus was in a widget that supported cut-copy-paste, the cut-copy-paste menu items and tool bar buttons were enabled regardless of whether anything was selected or the clipboard contained anything.

I added to my to-do list an item for correcting the enabling and disabling of those menu items and buttons. To me, cut and copy should only be enabled if the selection is not empty and the widget with focus supports cutting or copying; paste should only be enabled if the clipboard is not empty and the widget supports pasting. A coworker favors leaving the items and buttons enabled but doing nothing in the absence of selection, clipboard contents, etc.

That coworker is a long-time Windows developer and I am a Mac zealot. I find these affiliations not entirely coincidental. On the Mac, cut, copy, and paste are only enabled when they will actually do something; under Windows, they are enabled whenever the developer feels like, sometimes when they won’t do anything at all. Those behaviors are representative of their respective communities’ approaches to the user interface: Mac applications do whatever is easiest for the user and Windows applications do whatever is easiest for the developer.

It takes a lot of complexity to make cut, copy, and paste work correctly. In my case I needed focus and selection notifications and strategies around when and which buttons to enable. (Luckily the Cocoa framework automates a lot of things.) It certainly would have been easier to leave the controls enabled and let the user figure out if they did anything.

The benefit of the increased usability outweighs the cost of the extra work and complexity. Whilst there are examples of Mac applications that do the wrong thing and Windows applications that do the right thing, on the whole the Mac development community makes more usable applications. It’s like the difference between a four-by-eight sheet of D-grade plywood and a sanded, polished piece of mahogany: both will hold up your coffee mug but one is a whole lot nicer to use.

Which is why I spent the day fixing the cut-copy-paste controls. I’ll do the work now so the users won’t get any splinters.

I’ve done more fiddling with the theme. I like this new theme because it uses a serif font. I can’t change the header image right away: WordPress doesn’t support image uploading through Safari. Hopefully this is both localized and not indicative of WordPress in general. This particular entry was composed in MarsEdit. The WordPress composition page is pretty pro but I’m willing to give MarsEdit a try if it’s good enough for Gruber.

After my abortive beta of using Panic’s Coda to replace my iWeb blog, I’m trying WordPress instead. To kick things off I’ve imported my LiveJournal entries, all four hundred-odd of them. As far as I can tell, the iWeb entries require manual importing, which makes their appearance here unlikely.

I’ve just created this blog a few minutes ago, so everything is still the defaults. As I fiddle with things, stuff like themes and the ability to comment may appear or disappear.