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.”

After a couple of weeks with my iPad, I have to say that I am disappointed with its virtual keyboard.

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.)

Sometimes I think I’m not a real developer. I don’t like cats, loud music, television, or science fiction. I like beer, but when I go to a bar I order just one or two at the most, not five or six. I can’t stay up till 3 a.m. I’m a slow typist. Menlo bothers me because the * is too low.

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.

The iPad is going to change the way we use computers. The change is huge, and it affects everybody. I’m going to tell you why in one word: abstraction.

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:

Device	High-abstraction input	Low-abstraction input
Apple II	Excellent	Terrible
Mac	Excellent	Good
iPhone	Poor	Outstanding

As of 27 January 2010 we must add this:

iPad

Outstanding

Outstanding

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.

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.

Recently I received feedback from a blind user complimenting Pagehand on its accessibility. This surprised me because accessibility is one of those things I intended to look into one day, and I had not done anything special to make it happen.

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.
Read more »

Update: please see our post about LaunchCodes

I’m loathe to criticize Apple, I really am. There’s no other company I would allow so much control over my life. I sit here every day happily coding away in Cocoa and, for the most part, loving it.

But I have to say that Apple has made a huge, dumb mistake in dropping creator codes from Snow Leopard.

Years ago when I was a middle manager in an organization, the people in my division had Macs. We were doing very well until a new boss replaced our Macs with PCs. Many frustrations followed, not least being unexpected behavior when double-clicking on a file.

“Windows is not as smart as Mac,” I kept telling my charges. “When you double-click a file, the Mac knows what do because the file has a hidden creator code. Windows has only the extension to go by.”

Now it is 2009 and when it comes to double-clicking a file, OS X is as dumb as Windows.

As I write, I have two Macs before me, one running 10.5 and the other 10.6. On the 10.5 machine I do this:

In BBEdit, make a new file and save it as test.txt.
In BBEdit, make a new file and save it as test.html.
In BBEdit, make a new file and save it as test.css.
In Nisus Writer Pro, make a new file and save it as test.rtf.
In Pixelmator, make a new PNG file and save it as test.png.

When I double-click each of those files:

test.txt opens in BBEdit.
test.html opens in BBEdit.
test.css opens in BBEdit.
test.rtf opens in Nisus Writer Pro.
test.png opens in Pixelmator.

That is exactly the behavior I want.

Now I repeat this exercise on the 10.6 machine. The results:

test.txt opens in TextEdit.
test.html opens in Safari.
test.css opens in DashCode.
test.rtf opens in TextEdit.
test.png opens in Preview.

Snow Leopard takes one of the Mac’s most elegant features—launching the correct application for a file—and desecrates it.

This situation is particularly egregious with respect to PDF files. Let’s say a PDF file contains application-specific data (as the PDF spec allows). When I double-click that file, which application do I want to open it? Let’s take a wild guess: I want to open it in the application it was intended for. I want to open it in the only application that can read its app-specific data. I sure as hell don’t want to open it in a generic PDF reader.

I can hear Preview smirking, “All your PDF are belong to us.”

I never create an html file with the intention to view it right away in a browser. I create it because I am working on a web site and I’m going to deploy the file to a server when I’m finished. The same goes for .css files and images.

If I choose a specific text editor from among the several on my Mac when I create a new .txt file, that’s a pretty good clue that I want to use that same editor to edit that file. Does anybody create a text file in one application with the intention of editing it in another?

Nisus Writer Pro and TextEdit both create .rtf files. I’ve never had a problem with that. If I create a .rtf file in Nisus, then I’m likely do complex things with the file (tables, columns) and I want henceforward to open it in Nisus. If I create a .rtf file in TextEdit, then it’s bound to be a simple file that I can keep editing in TextEdit. I want, forever, to open the Nisus file in Nisus and the TextEdit file in TextEdit. Is this concept somehow challenging to understand?

I would like to know what problem Apple thought they were solving by dropping creator codes from Snow Leopard.

The closest thing to an explanation I’ve been able to find is this statement from an Apple engineer:

“When I save a JPEG file in an image editing app, and later open it, I expect it to open in Preview (or whatever my default image viewer is), not the image editing app.”

Now, that engineer is a man whom I know, like, admire, and respect. I hold him in the highest esteem. But in this case, he is just comically wrong. Does he really think that workaday blokes who create a file always get all their work done in one go, and never have to edit the file again, and go on their way rejoicing and henceforward opening the file in a generic viewer?

Want some salt in that wound? Listen to this:

“For documents that are recognized by multiple apps, the user has the power to bind a particular document to any app they wish, using the file inspector in Finder. So at least for this purpose the creator code is not needed.”

Two words come to mind: puh leez. In what universe do people create a file and immediately, whistling with merriment, go to Finder and change the application binding for that document?

When you’ve used a Mac for over twenty years, and it has always done the right thing, and now it often does the wrong thing, the feeling is a lot like betrayal.

It is still true that daily I sit here happily coding in Cocoa. But every day I double-click a file that opens in the wrong app, and then I seethe with the fury of the burning sun. Apple, how couldst thou?

If I made a mistake like this, I’d be mortified. And nobody would buy my software. Nor should they.

Microsoft retail stores are going to open soon, and I can’t wait.

I simply love going to an Apple store and browsing through all the cool Apple hardware: Macbooks, iMacs, the Mac Pro, Time Capsule, iPods, iPhones.

So when the Microsoft store opens, I want to go get my hands on all that cool Microsoft hardware, like Read more »

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.