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.

It’s easy to understand the reasoning behind NDAs. No developer wants potential customers to rely on an upcoming product’s having certain features that might be dropped before the product ships. Nor does a developer want new features to leak out in advance and dilute the buzz of the launch event. The developer wants to control public discussion of the new product lest unqualified reporters, who do not know what beta software looks like, give the product an undeservedly bad review. All these things make sense.

Except, I posit, in the case of developer tools.

What’s different about developer tools

Apple’s developer tools differ from its other products in substantial ways. The first and obvious difference is the price. Developer tools are free. Apple doesn’t sell them. There is no revenue stream to jeopardize.

Second, in the modern era, there is no competitor to Apple’s developer tools. Code Warrior is long gone. Can you imagine developing an iPhone app without Xcode? If you develop for Mac OS or iOS, you’re going to use Xcode, period. It isn’t like you are going to read a bad review about Xcode and decide to use something else.

Third, the parties who test pre-release developer tools are exactly the same parties who use the tools. I don’t think I am going out on a limb to say that the only people who use Xcode are developers. And the people who have access to the beta tools are the same developers. Everyone who is going to use the released product has access to the beta. There’s no risk of beta users misinforming customers who have to wait for the final release because nobody has to wait for the final release.

Developer tools are closer in analogy to in-house software. Many of us have developed software for use within a large organization. Do you think it would improve the product if your users were not allowed to discuss it among themselves?

I’ve tried to come up with a scenario in which Apple would be harmed by developers talking about Xcode 4. I can’t think of any. In fact, there is none, because Apple allows us to discuss Xcode 4 on their forum.

Because the forum is open only to developers, one assumes that Apple perceives some harm if the public could read what developers are saying about the new Xcode. I submit that this is nonsense. “Developers confused by Base SDK vs Target SDK!” “Exclusive: method names in documentation index are not aligned!” I don’t think we will ever read such headlines. Non-developers don’t give a tinker’s damn about the design of Xcode.

Why the NDA harms Xcode development

So, my first point is that applying the NDA to beta developer tools is nonsensical. My second point is that it leads to lousy software.

We all know how the bug reporter system works, at least superficially. Duplicates matter. Your chances of getting a bug fixed improve when other developers report the same bug. We routinely urge our peers to file a bug report on something we have already reported. Indeed, Apple engineers recommend the practice. It’s quite routine for someone to tell me about a bug that I have not personally encountered, but it is definitely in my interest to have the bug fixed before it trips me up, so I will file a duplicate bug report.

That’s just the way the system works. Except with Xcode betas! Because we are not allowed to discuss bugs among ourselves, the bug reports are limited to reports from developers who have discovered the bug on their own.

That is to say:

• Apple’s bug reporting system prioritizes bugs based on number of duplicates.
• Bugs of significant importance to developers receive lots of duplicates because we discuss them among ourselves.
• For Xcode betas, the bug reporting system continues to prioritize duplicates but denies developers the ability to increase the duplicates for very important bugs.

Yes, I realize that Apple’s developer forums mitigate this flaw to some extent. But, really, those forums are a mess, aren’t they? As far as I can tell, there is no RSS feed or mailing list where you can keep up to date with what is being discussed. You have to check the site manually. For the Xcode 4 discussion alone, there are eight topics, and you have to check each one separately. When you have navigated beyond the first page of threads, and you click a thread to read it, you can’t get back to the page you were on; you’re taken back to page one and have to page forward to find the place where you left off.

As a developer whose skills will never rise beyond the level of intermediate, I rely on the wisdom of intelligent developers whom I respect. I’m far more likely to understand and agree with those guys than with an unknown poster on the Apple forum. I’d love to know what Gus and Matt and Marcus and Frasier and Daniel think about Xcode 4. I and others would then file bug reports and in the end we would all enjoy a better Xcode.

As things stand now, I have a feeling that Xcode development is beyond our control, and we are going to have to live with it no matter how awful it turns out. It might well be that some aspect of Xcode 4 is despised by the vast majority of us, but we will not know that until the NDA is lifted and then it will be too late.

I’ve posted a few items on the Apple forum. I’d ask you to search for them using my name, so you too can file bug reports, but guess what: that search does not find my posts. There’s a “Who” field in the search bar, but it doesn’t work, AFAICT.

The sorry situation

So all I can do publicly is muse: hmmm, I wonder how Xcode 4 handles Find Selected Text In Project? I wonder how it handles jumping directly to the documentation from source code? I wonder if you can easily jump back and forth between the docs for an object and the delegate methods for that object? I wonder if you can still right-click to fix alignment? I wonder what other features such as user scripts that I use heavily have been left out?

It might turn out that Xcode 4 is the best Xcode yet. If that happens, it won’t be because we all had a good discussion about it beforehand.

I never learned touch typing (whatever that means; is there another kind? Slam typing?). I get along very well without thinking about which finger goes to which key. On the iPad, my fingers go to the correct place as accurately as they do on a real keyboard. The loss of tactile feedback doesn’t slow me down at all, except for the shift key, as I will describe in a moment.

What slows me down—way down—is typing anything other than lower case a to z, space, comma, and period. Those, of course, are the characters you can type with one keystroke. Anything else requires either the shift key or a switch to a different keyboard layout, accomplished by two large keys on the main keyboard and two small keys on the auxiliary keyboards.

The shift key slows me down because Apple has been very sparing in representing the state of the key. Pressing the shift key draws its arrow with a blue fill. That’s a curious choice, because when my finger is on the shift key I cannot see its arrow at all. Yes, there are two shift keys, but my eyes want to go to the one under my finger.

The glyphs on the keys are all upper case. I would have liked the key glyphs to be lowercase, switching to uppercase when the shift key is pressed. That would tell me immediately what is going on, even if some keys are obscured at the moment.

Most of my irritation with letter case comes from Apple’s attempt to press the shift key for me, for example after a full stop. Even with auto capitalization turned off, the keyboard still tries to type uppercase letters when I don’t want it to. For example, if I type “In summary, I propose that” and decide I want to change I to we, when I delete the I the shift key is engaged and I end up typing We instead of we.

The auxiliary keyboards slow me down because they do not stay on screen long enough for me to learn where all the characters lie. To type a plus sign you have to tap the .?123 key to bring up the numeric keyboard, then tap the #+= key to bring up punctuation keyboard. By the way, .?123 is an odd label. You can already type . and ? from the main keyboard.

To type a + requires four taps: the .?123 key, the #+= key, the + key, and finally the ABC key to get back to the main keyboard. At that point my concentration is gone, and whatever I was going to say next has to be thought out again.

After a couple weeks I have made no progress toward learning the whereabouts of any auxiliary keyboard keys other than the numerals at the top of the numeric keyboard.

Many people, perhaps most, type a ! or ? more frequently than an apostrophe. I am not among them. It takes three taps to get an apostrophe in place. And although the proffered glyph is a properly curved apostrophe, the rendered glyph is a plain straight abomination.

Worst of all, despite all those keyboards there are no arrow keys. Selecting a single character by dragging, or placing the insertion point at a particular spot, is just not easy. I use arrow keys all the time on a regular keyboard, and I want them on my virtual keyboard.

One of my big frustrations vanished when I discovered that you can type an apostrophe by flicking the comma key upward. What a clever and useful feature! How did I miss it? Was it mentioned somewhere? At any rate, I submit that the flickable key idea can be incorporated into the entire keyboard in such a manner that the virtual keyboard rivals, and perhaps excels, the tactile keyboard.

Here’s how it would work.

1. Every key would respond to up, down, left, and right flicks in addition to taps and holds (a hold pops up a menu for certain keys, showing diacritical options).

2. The four characters produced by the flicks would be drawn on the key.

3. The shift key and the auxiliary keyboards would be removed.

4. Taking the place of the shift and keyboard keys would be keys for managing the selection and cursor position, and keys for families of quotation marks, parentheses, and hyphens.

Forgive me, but I cannot resist calling these flickable keys flickeys.

Here’s how a flickeyboard might look (click for a full size view):

Obviously, this is a US flickeyboard; localized keyboards would differ in the placement of some symbols. How it works should be self-evident. A few ideas merit a closer look.

Flicking down on any letter renders it in uppercase. Flicking downward with two or more fingers anywhere on the keyboard toggles Caps Lock, which is identified by swapping the uppercase and lowercase labels on the flickeys.

The top row of flickeys mimics the operation of the top row of keys on a standard keyboard. Numerals 1 through 0 are right where you expect them to be; you simply flick upward to type the numeral. Flicking to the left produces the symbols associated with holding the shift key while typing a number key. Flicking upward with two or more fingers swaps in a numeric keypad.

Flicking to the right produces some symbols that appear on the iPad punctuation keyboard. Currency symbols are grouped together; in a happy coincidence the yen symbol appears with the letter y and the euro symbol appears with the letter u. Multiplication, division, addition, and equals symbols are placed on three adjacent flickeys.

In this mockup, the second row of flickeys has not been assigned any characters. That’s 27 possibilities.

A quotation mark key replaces the left shift key. With one key you can easily type the four typographer’s quotes, or the abominable straight mark. This, I submit, is an improvement over the shift-option-bracket combinations used on a Mac desktop.

Flicking upward on the bottom row of letters mimics the option key combinations used to type diacritical marks.

At the right of the third row, three punctuation keys provide related symbols. The comma and semicolon use the same flickey. Full stops—period, exclamation, and question mark—appear on the period flickey, as does the colon. The rightmost flickey provides hyphen, en hyphen, em hyphen, and underscore.

To the right of the space bar, two keys provide matching delimiters: parentheses, brackets, braces, and angle brackets.

The space bar shows a command symbol to denote that holding the space bar in conjunction with a another flickey mimics the command key; space-z invokes undo, space-v invokes paste, and so on.

The leftmost key on the bottom row does nothing when tapped; it responds only to flicks, and it moves the cursor left and right, or line up and line down. Up-left and down-right flicks mimic the Home and End keys.

The select key (which is not a flickey), when held, turns any cursor movement into a move-and-select. It works in conjunction with the key to its left, or with taps in the document. For example, you can select from the cursor to the beginning of the line by holding the select key and tapping at the beginning of the line. In other words, it creates selections exactly as the shift key does on a regular keyboard.

If users find the layout too busy with all those labels, one possible solution is to toggle the visibility of the flick labels by means of an added key or a flick. Another is to put an opacity slider to the left of the a key.

The flickeyboard takes advantage of the iPad’s ability to do things that cannot be done on a conventional keyboard. A single, simple, intuitive movement replaces the typewriter-era paradigm of holding a modifier key while tapping a character key. You see all the characters all the time, unlike physical keyboards that require a keyboard viewer application to show you where some characters hide.

It shouldn’t be too terribly difficult for someone to write an app that would let us try out this concept. A github project, perhaps?

(Edited 24 April 2010 in response to Uli’s comment.)

But when I go to NSConference, I become part of a fraternity that has a rollicking good time.

What if, instead of attending the Atlanta conference last week, I had taken a cruise, or gone to the Olympics, or gone skiing in the Alps or toured the world’s top museums—would I have had any more fun than I had hanging out with Cocoa developers? What if I had tickets to the funniest play on Broadway—would I have laughed more loudly than I did at the Cocoa Rumble? What if I had set aside a few days for quiet study of Cocoa documentation—would I have learned any more?

It goes without saying that the answer to all these questions is an emphatic No. I don’t know how Scotty and his team do it, but they’ve come up with a conference formula that packs a couple of days full of fun and material. It was rather like the time I got to sit right next to Tommy Emanuel while he was playing guitar. I could see his hands, and I could hear the music, but I couldn’t believe that all that music came from just those two hands. At NSConference, I couldn’t believe I was having such a good time and learning so much at the same time.

NSConference 2011? Sign me up now.

Degrees of abstraction

We can differentiate between tasks that require high and low degrees of abstraction. When you take a pencil and draw a picture of a cup, that’s a low degree of abstraction. It looks like a cup; when you drew it you were thinking of an actual cup; and when someone looks at it they think of an actual cup, too.

If instead of a cup you draw the letter u, you invoke a high degree of abstraction. The shape that you drew contributes meaning in the context of its grouping with other shapes. The process of accumulating many abstractions into a larger meaning is immensely complex; we all learned it when our young brains were fantastically adept at this sort of thing. Even so, learning to read and write took years of study and practice.

Communicating through written language, without doubt, is the most complex and abstract task that we routinely perform. This is equally true for alphabetic and pictographic writing systems; pictographs arguably require less abstraction but more complexity because of the large number of glyphs.

Written text is not the only highly abstract activity we perform. Numbers are abstract, with arbitrary representations. Recall that the roman alphabet we use today long preceded the arabic numbering system. Dates and times are also abstract. “The first Thursday of the month” references a complete abstraction.

On our computers, we constantly switch back and forth between high- and low-abstraction tasks. As I write this, I pause from the highly abstract task of typing text to the non-abstract task of repositioning the window by dragging the mouse.

Now, pay attention here. Moving the window was low-abstraction because I have a low-abstraction input device. If I had no trackpad or mouse, I would have to move the window by typing keystrokes, which would involve quite a bit of abstraction. I don’t think I have ever moved a window via the keyboard. I have no idea how to go about it. I haven’t learned that particular abstraction, so I can’t move the window with the keyboard because abstractions are the only kind of input a keyboard understands.

Here’s the theorem: if the input method matches the abstraction of the task, executing the task is simple; if not, executing the task is complex. Or, if you like: the ease with which a task can be performed is directly proportional to the impedance match between the abstraction level of the task and the abstraction capability of the input system.

How computing devices handle abstraction

Now let’s do a quick review of the progress we’ve made in thirty years of interacting with personal computing devices.

Before Apple, computers used toggle switches for input and lights for output. Looking at such a device today one is repulsed by the high level of abstraction required to interact with it. You have to associate meaning with various patterns of light and switch state. Interacting with the machine seems almost impossibly difficult. In fact the process is probably no more abstract than our writing system; we simply don’t want to undertake the great effort required to master it.

The Apple computer designed by Steve Wozniak was the first personal computer to use a keyboard for input and a monitor for output. This provided an enormous increase in usability by replacing an unfamiliar system of abstraction with a system we already knew.

The keyboard is remarkably adaptable. You can use your typing skills, or you can learn some new abstractions and use the keyboard to play games or make musical tones or emulate a calculator. The keyboard beneath my fingers right now has seventy-eight keys. All but five (the keys for adjusting brightness and volume) are totally abstract. The four arrow keys I consider semi-abstract.

Because the keyboard is designed for high-abstraction tasks, it is terrible for low-abstraction tasks. Our human impulse to use our hands for grasping and manipulating objects must be replaced with an abstraction because abstraction is the only kind of interface that a keyboard provides.

That’s why the mouse-equipped Macintosh was so revolutionary. It gave us two input devices that provide input in both high and low levels of abstraction.

But the mouse is not ideal, is it? There’s still some abstraction involved—the physical object moved and the movement on the display occur in different places. Sometimes I have to wiggle the mouse in order to find the pointer of my display. When I try to draw with the mouse I usually see the brush going a different place than I wanted. After all, the mouse is an extension of the hand, not the fingers. You wouldn’t want to resize a picture by executing the pinch gesture with a mouse in each hand. Other low-abstraction input devices such as trackpads and drawing tablets address some of these limitations. Still, the input sensor is external to the display, so there is necessarily some abstraction involved, and in any event you have to manipulate at least two different devices to provide both high- and low-abstraction input.

The ultimate low-abstraction devices are our fingers, and that of course brings us to the iPhone. Cocoa Touch provides the sense of manipulating objects directly with your fingers. That’s a very satisfying thing to do, and perhaps explains why I prefer to do some tasks on my iPhone when I could do them just as effectively on my Mac. Because the input occurs at the same location as the result, nearly all the abstraction is removed. For low-abstraction input, the touch screen beats the mouse hands down.

Sometimes we forget that the touch screen is not the only input system on the iPhone. The accelerometer turns the entire device into an input sensor that responds to motion and orientation in three-dimensional space. Together the two systems provide a wealth of low-level abstractions that far exceed the capabilities of the input systems on desktop and laptop computers. There are no peripheral objects to capture input; on the contrary, the notion that input is distinct from output all but vanishes, merged into a single concept that embraces output, input, and the computing device itself.

According to our theorem, the iPhone should be ill-suited for high-abstraction tasks. And it is. I, for one, cannot type with two thumbs. A pocket-size device is simply too small to accept rapid input from ten fingers. For better or worse, that’s how we provide the complex input required for high-abstraction tasks: we type on a keyboard. And you can’t do that on an iPhone.

How the iPad handles abstraction

To recap:

As of 27 January 2010 we must add this:

With the iPad, we have a device that provides the outstanding low-abstraction input of the iPhone, and high-abstraction input that is superior to the Mac. (People who think the iPad is a big iPhone have it backwards; the iPhone is a miniature iPad.)

At the product launch event, we watched people drive a car by turning the iPad like a steering wheel; create a presentation by dragging slides around with a finger; and type text on a qwerty keyboard. All this was done on a device that has no peripheral attachments—a device that, like the iPhone, conflates the notions of input, output, and the device itself.

That’s why the iPad is going to change the way we interact with computers. Most of the recent clatter misses the point. Cameras and tech specs and book prices are the trees; the way we interact with the device is the forest, and I hope people start to see it.

Why do I deem the iPad keyboard superior to the one I’m typing on now? Primarily because the iPad is not limited to just one keyboard. The iPad introduces the concept of different keyboards for different tasks. In the demo we saw the traditional qwerty keyboard, what we might be tempted to call a numeric keypad, and a delightful innovation: a keyboard for inputting date and time information. (“Keyboard” is something of a misnomer on the iPad, as there are no keys; maybe “button board” or just “board” is a better term to denote an infinitely configurable system of processing highly abstract input.)

It’s no coincidence that those three keyboards correspond to the three abstract systems I described at the beginning of this essay. These alternative input systems seem to live in another dimension, popping into our existence only when we need them. We’ll see more of them in the fullness of time. I look forward to the button board designed for musical composition.

The virtues of the virtual keyboard

Some might object that typing on a glass keyboard will never rival typing on a regular keyboard. Let’s reason this through. There are three factors that define a typing experience: the distance that the key travels, the force required to initiate key movement, and the cushion or give when the movement reaches bottom.

It’s easy to see where key travel has been heading.

Back when typewriters were made of iron, the key travel was as much as two inches. Electric typewriters reduced key travel to about three-eights of an inch. (Just guesses; I don’t have either one, and I don’t know anyone who does, so I didn’t measure. But I’ve done quite bit of typing on both electric and mechanical typewriters, including one so old that when you pressed the shift key it raised the carriage instead of lowering the keys, and these numbers seem right.)

I took a ruler and measured the key travel on some keyboards I have around the house. Here’s the key travel data, measured in thirty-seconds of an inch:

Very old mechanical typewriter: 64
1960s mechanical typewriter: 32
Electric typewriter: 12
Keyboard from first-generation iMac: 6
2002 Microsoft keyboard: 5
Keyboard from iMac G5: 4
Keyboard from new iMac: 3
Keyboard on MacBook Air: 2
iPad virtual keyboard: 0

Every reduction in key travel has improved the typing experience. In my view, the iPad marks the inevitable end of a progression that has been happening for the last hundred years. Just as 6/32 seems like way too much travel to me now, I’m sure that anything greater than 0 will seem too much after I’ve used the iPad for a while.

The force required to execute a keystroke cannot be measured without an iPad, and even if I had one I wouldn’t know how to measure it. I expect it is very small, like the iPhone. At any rate, I’m sure that touch sensitivity can be tweaked by the operating system, or possibly by user preference, and the default value will be much less than the value for a mechanical keyboard.

The landing experience, in my unschooled opinion, cannot be judged apart from the force exerted. The harder you have to push to make a key move, the more you need a soft landing. As we grow accustomed to typing on glass, I think we’ll soften the force we apply to our fingers and the experience will be quite natural and painless. I’ve never heard anyone complain that using an iPhone makes their fingertips sore.

Furthermore, we won’t need a desk to set the iPad on. An iPad resting in your lap will absorb quite a bit of typing impact. Typing on the iPad won’t be like drumming your fingers on a glass tabletop.

I also suspect that the diminution of key travel and key force over the years has changed the way we position our fingers over the keys. In the old days, you had to type with the tips of your fingers because that was the only way to exert enough force to execute the mechanical movement required. I still remember jabbing a stiffened little finger into the shift key in order to move the entire keyset. When little or no force need be applied, we can type with the balls of our fingers, which have more natural cushion than our fingertips.

The world has changed

The best low-abstraction input system the world has seen, and an infinitely adaptable high-abstraction input system, in a product that is a simple thin rectangle—how that can be anything but revolutionary?

It’s going to be a long sixty days.

Curious, I put Pagehand through its paces in VoiceOver. The exercise left me horrified. Far from deserving praise from this user, I instead deserve severe disapprobation for neglect.

It took a while (and some great help from the accessibility mailing list) to figure out how to fix the worst of my transgressions. For the benefit of others who, like me, are a blank slate when it comes to accessibility support, I’d like to share what I’ve discovered so far.

First discovery: VoiceOver reads tooltips.

It turns out that I got a big jump on accessibility simply by filling in the Tool Tip fields in Interface Builder. VoiceOver reads tooltips as accessibility help tags. Without my doing anything special, VoiceOver users got the benefit of those tooltips:

Second discovery: VoiceOver sees things that we do not see.

The most surprising discovery I’ve made is that VoiceOver’s notion of what is visible is different from what is in fact visible on screen. Specifically, VoiceOver sends a -isHidden message to a NSView to determine whether the view is visible. It ignores the view’s frame. If you hide a view by setting its height to 0, or move it out sight, the view is invisible on the screen but fully visible to VoiceOver.

Pagehand uses simple proxy animations to open and close views. Controls are subviews of an NSView subclass named Palette, and the animation hides the Palette by setting its height to 0. Palettes are placed side by side in another NSView subclass named Sidebar, and Sidebars are made visible by adjusting the x origin of their superview, again using animation. The superview is the width of one Sidebar, so the Sidebars appear to slide horizontally into place.

This all looks fine on screen, but VoiceOver does not understand any of it. VoiceOver thinks all the Palettes in all the Sidebars are visible all the time.

I can think of three simple approaches for fixing this problem: send setHidden:YES at the end of animation that hides a Palette or Sidebar, and setHidden:NO at the beginning of all other animations; override setFrame: to send setHidden: as appropriate; or override setHidden: to look at the receiver’s frame and return YES if the Palette or Sidebar is completely hidden.

For now, I am using the third approach. I don’t know which is best.

Third discovery: You cannot supply accessibility text for an NSSegmentedControl in Interface Builder.

VoiceOver will read the items in an NSSegmentedControl as “radio button 2 of 4.” You might expect that the Accessibility Description field in Interface Builder would allow you to set the description for each cell. But the Description field applies to the entire segmented control, not to individual cells. You have to provide the accessibility description in code.

You can see how to do this in Apple’s ImageMapExample. To help keep the accessibility strings organized, I subclassed NSSegmentedControl and set a unique tag for each control in Interface Builder. Basically it’s just a copy-and-paste job from the example:

@implementation CCMAXSegmentedControl

// copied from ImageMapExampleController.m:
static void SetSegmentDescriptions(NSSegmentedControl *control, NSString *firstDescription, ...) {
    // Use NSAccessibilityUnignoredDescendant to be sure we start with the correct object.
    id segmentElement = NSAccessibilityUnignoredDescendant(control);
    
    // Use the accessibility protocol to get the children.
    NSArray *segments = [segmentElement accessibilityAttributeValue:NSAccessibilityChildrenAttribute];
    
    va_list args;
    va_start(args, firstDescription);
    
    id segment;
    NSString *description = firstDescription;
    NSEnumerator *e = [segments objectEnumerator];
    while ((segment = [e nextObject])) {
        if (description != nil) {
            [segment accessibilitySetOverrideValue:description forAttribute:NSAccessibilityDescriptionAttribute];
        } else {
            // Exit loop if we run out of descriptions.
            break;
        }
        description = va_arg(args, id);
    }
    
    va_end(args);
}

- (void)awakeFromNib {
  if ([self tag] == 2) {    // paragraph alignment:
    NSString *leftAlign = NSLocalizedStringFromTable(@"left align", @"AX", "left align");
    NSString *centerAlign = NSLocalizedStringFromTable(@"center align", @"AX", "center align");
    NSString *rightAlign = NSLocalizedStringFromTable(@"right align", @"AX", "right align");
    NSString *justifyAlign = NSLocalizedStringFromTable(@"justify align", @"AX", "justify align");
    SetSegmentDescriptions(self, leftAlign, centerAlign, rightAlign, justifyAlign, nil);
  }
}

NSAccessibility reminds me of AppleScript: sometimes it’s hard to figure out what it wants, and you save a lot of time by just copying what someone else has done.

To summarize, I addressed the worst of my accessibility problems by:

1. Supplying tooltips and descriptions in Interface Builder;

2. Making sure that non-visible views return YES from -isHidden;

3. Writing code to provide accessibility descriptions for segmented controls.

This is just the beginning. Plenty of accessibility work lies ahead.

The facility: The deHavilland Conference Center seem to have recruited their employees from the Society of Happy Helpful People. The room was just right, the food was excellent, the beer was real, and my stay there was delightful.

The speakers: I’ve written about how programmers are smart. The speakers were the smartest of the smart. The presentations were engaging, informative, useful, and well planned.

The organizers: The entire event reflected Scotty’s infectiously jolly character. As it turns out, he’s quite an organizer, too. For a first-time event, the smooth and efficient operation was remarkable. His motto could have been, “All needs anticipated, all preferences accommodated.”

The design competition: The conference closed with an inspired idea: two teams of developers were given a set of requirements and had to design, but not build, an application. It was all the fun of Iron Coder without the work. Scotty kept saying the idea might be a disaster. It wasn’t.

The attendees: NSConference 2009 was populated by developers from all over Europe, with a few North American infiltrators added to the mix. What made the group especially cohesive was our shared experience with the loneliness of being a Cocoa developer. Here in Kentucky I am certainly never going to meet another Cocoa developer, and I’m sure my European counterparts know the feeling. We don’t have a NSCoder Night to attend. Our wives and girlfriends might listen sweetly as we talk about AppKit, but it’s not the same, really. So, you throw a hundred of these guys together and you can be sure they are going to have a great time.

All the folks I met at the conference write code and inhabit a spot somewhere along the trajectory of application development: from the thinking about it stage, to the actively working on it stage, to the selling it and making money stage. At other conferences I’ve attended there were writers and CEOs and representatives from big companies mingled among the coders. At NSConference, we were all coders.

And that might explain why, from the opening moments of the conference, we were all talking about next year. It’s just inconceivable that such a wonderful event would be a one-off; there simply has to be one next year. Banks may fail and economies may sour, but please oh please let there be NSConference 2010.

When the taxi driver took me to the train station on the morning after the conference, he shook my hand and wished me a pleasant journey. It had to end just that way. The taxi driver’s little pleasantry was emblematic of the time I spent in Hatfield.

The friendships forged at NSConference 2009 will last a very long time. Thanks, Scotty.

The temptation to release the beta now sits on my shoulder every day while I work. “You can write the help files while you wait for the responses,” it coos. “Go ahead. You’ve frozen the feature set. You’ve cleared all the FIX MEs. Release the beta. You’ll feel so good when you do.”

From my other shoulder I hear, “But you want the testers to evaluate your help files, too. Well-written help makes the beta that much more impressive.”

For the last few days I’ve been working on writing Help, and I’m ever so glad I didn’t release the beta. What I’ve learned is that writing Help makes you exercise every feature of your app, including the ones you’ve broken while fixing something else. Typically I write for half an hour, then spend four hours fixing the bugs I’ve discovered. Foolish me, I thought I had found all the obvious bugs. Ha! I wasn’t even close.

When I think about all the bug reports that would have come back, I shudder. Writing help files is not much fun, but it’s invaluable as a way of giving your app a once-over before you release it to testing.

Until Apple offers developers a firm set of guidelines, developers will continue to be ticked off by seemingly arbitrary rejections. . . . Apple needs to step forward, and do so soon, with a clear set of guidelines that explain to developers exactly what to expect when they press that “submit” button for their new app.

Erica and others know a lot more about software development than I do, and they might well be right. We all have an innate, acute sense of injustice, and secret rules by their very nature send a jolt to our injustice neurons.

Sometimes, though, life isn’t fair, and sometimes there’s a reason why life isn’t fair.

As a developer, I concede my inexperience. I have twenty years less development experience than the people whose opinions I value. What I do have is twenty years more experience practicing law, and I can tell you a few things about rules and regulations that you might not have had the opportunity to observe.

Justice Holmes wrote, “Whenever the law draws a line there will be cases very near each other on opposite sides.” United States v. Wurzbach, 280 U.S. 396, 399, 50 S.Ct. 167, 74 L.Ed. 508 (1930). The establishment of a line—what lawyers call a bright line—means that people are free to get just as close as they possibly can to the line without crossing it. As a consequence, human nature being what it is, a bright line becomes an attractor. Behavior patterns that otherwise would have been distributed equally across a spectrum will tend to clump together near a bright line.

In civil law, that result is acceptable. If a tax law says you can deduct $500, then by all means go ahead and deduct the full $500. That’s OK. Get right up against that $500 line. Just don’t cross over it and try to deduct $501.

In criminal law, we have to step back and think a moment. Do we really want to allow people to get as close as they possibly can to murder, as long as they stay just a hair’s breadth on the good side of the line? Certainly not. So in the criminal area we see laws that establish degrees of guilt with graduated penalties. If you almost but not quite committed first degree murder, you might be guilty of second degree murder, or reckless homicide, or wanton endangerment, or some other offense.

The principle that we can enunciate is this: if you can tolerate people congregating around a bright line, draw a bright line. If you want a line that keeps people away, you have to draw a gradient instead of a bright line.

NSGradient now makes it much easier to draw a gradient in computer code, but in legal codes, it’s still hard. Think about it. When you write a block of code, whom do you have to satisfy? First and foremost, the compiler; not eleven compilers selected by the President, the compiler. Fine. Anything else? Well, if the block is to be used only in the context of other code you are writing, then it has to provide the expected result to the rest of your code. That’s easy enough. If you’re writing a framework, then you have to account for a larger set of considerations. But it’s a finite list, and a short one at that.

Writing a law is hard. I’ve done it. I know. You have to satisfy a wholly unknown and unpredictable set of circumstances that will be adjudicated by an unknown and unpredictable set of arbiters. Can you imagine writing code when you don’t know what platform it will run on, or which compiler it will run through? That’s sort of the challenge of writing a good law. (I wasn’t particularly good at it myself, but I never met anyone who was.)

That is why a whopping proportion of the laws that affect you and me are not codified. It’s just too hard to write out a single set of rules that will hold up (that is to say, will satisfy our innate sense of justice) when applied to the magnificent variety of fact patterns that human activity creates.

What we have instead is the common law.

Justice Holmes’s The Common Law—a splendid book that is read, tragically, by only a tiny percentage of lawyers— describes how common law, unlike the bright lines of codified law, evolves and advances just as life, language, and culture do. Common law by its nature is adaptive. Codified law is not. One is not inherently better than the other. We need both. And we have both.

When I look at the App Store situation, I do not see a process that invokes words like “secretive and arbitrary,” “seemingly arbitrary”, and “out of thin air.” I see a system of common law. I see a set of decisions made on a case by case basis that will over time congeal into a set of gradients. Not bright lines, which attract activity toward the forbidden zone, but gradients, which repel activity from the forbidden zone. It’s not a great system. It’s frustrating and imperfect. But, as history validates for those of us acculturated in English/American jurisprudence, it’s not bad.

Yes, certainly, Apple could announce a rule “No fart humor.” Some people would interpret that rule as a green light for defecation and urination humor. So Apple could refine the rule into “No applications that deal primarily with solid, liquid, or gaseous human ejecta.” Then someone would be afraid to write an application that provides first aid advice to deal with severe vomiting. You think writing computer code is hard? Well, writing human code is mighty hard. Given the imprecision inherent in human language, it’s often impossible. The sharpest minds in the world can’t do it.

It’s very difficult for me to comprehend a situation in which a developer with, let’s say, 50% of the average human allotment of intelligence and responsibility would experience genuine uncertainty about the fate of an application submitted to the App Store. The developers who complain about the lack of guidelines, as far as I can tell, are not complaining on their own behalf, but on behalf of an imaginary population of fart-app-writers whom they deem to be at risk of some future injustice.

Count me as one developer who says, you fart-app-writers are on your own. You’ll get no support from me.