waffle

Craig Hockenberry:

If you’re one of the people who think that a multi-touch monitor is a good idea, try this little experiment: touch the top and bottom of your display repeatedly for five minutes. Unless you’re able to beat the governor of California in an arm wrestling match, you’ll give up well before that time limit. Now can you imagine using an interface like this for an eight hour work day?

Look on your desk, or in your lap, depending of which of the two that, suffixed with -top, would accurately describe your type of computer. You will see a keyboard and either a mouse or a trackpad (or, for the painfully leet, a trackball - rock on).

Neither of these - and not, as the first mainstream consumer solely multi-touch product, your iPhone - depend on your reachering up at monitor heights to touch them. The first rule of pointing or text-input devices is that they should be usable when your upper arm is completely vertical.

When multi-touch devices come, they will be pads that lie on your desk. You won’t need to touch your monitor - in any case, you won’t need to touch a monitor that’s stood up perpendicular to the desk.

Update: Because it may be unclear, I’ll clarify: I didn’t think Craig thought monitors were a good idea (clearly, by that very portion, he thinks they’re not) - I meant to say that no one will ever produce such a display since it’s mindboggingly obvious how few people will be able use them. (I am not counting things like Jeff Han’s Perceptive Pixel multi-touch wall as one of these things. You’re standing up and free to move around when using that.)

Two years.

If I would want — after continuous experiences of not getting along with it, mind you, not just preconceived misconceptions — to touch Python with a stick, I’d like to use Django. The approach it takes to web programming is a lot more like the way I usually work than is Rails.

The Mac OS X Resolution Independence Utilities project is a Google Code project where utilities and code will be available for creating high- or multi-resolution imagery.

I aim to personally provide Cocoa examples and code, but this is labelled “Mac OS X” - code for Carbon, Java, X11 and OpenGL is welcome too (even though, for example, Java has an integer-based coordinate system). For contributions, the BSD license or more allowing licenses (like the MIT license or public domain) is required.

Here’s an idea for everyone putting out Cocoa software (and that includes me): Release versions of your apps that are resolution-independent by November 29th.

Since it should be obvious why you should go resolution-independent, I will spend the rest of this post explaining “why November 29th?”

• It is day 333 of the year. 300 dpi is deemed a reasonable resolution for text, and one almost all inkjet printers can do, but day 300 is still in October, and wouldn’t give enough testing time if you assume a Leopard launch on the last Friday that month, which is the day before. Day 333 is the next date to be easily remembered.

• You have plenty of time until then to prepare all your images and other resources.

• November 29th is a week after US Thanksgiving, and if you’re selling software, it means it’s in the start of the christmas shopping season.

• Leopard will have been out for at least a month by November 29th, so developers without access to the beta will have had a month to test their software in the first Mac OS X version to be truly resolution-independent.

• Apple has said to “get ready for resolution independence in 2008″. This smells like high-DPI displays at Macworld Expo in January 2008. This gives developers a month yet after the first release (if they release on November 29th) to iron out bugs.