frankschmitt.org:

Dr. Drang has a post (now fireballed) bemoaning the large difference in resolution between desktop, notebook, and ultraportable Macs. There is indeed a wide range, from 102 ppi on the 21.5” iMac to 135 ppi on the new 11” MacBook Air. Apple has been working on resolution independence for awhile, but thus far it’s been too buggy to unleash on the general public. Lately those efforts seem to have stalled, at least as far as public announcements go. There are a couple of reasons why this might not be such a bad thing.

First, the different displays mentioned above are typically used at different distances. I’m typing on a 27” iMac, with the display at a distance where I can very nearly (but not quite) reach out and touch it. It wouldn’t be physically possible for me to type on a laptop at this distance, at least with the built-in keyboard.

Controls really ought to occupy a fixed number of arc-seconds of one’s visual field based on typical usage. That way, regardless of screen size and working distance, they occupy the minimum amount of screen real-estate necessary to be readable. The WYSIWYGness of what’s displayed on the screen only becomes an issue when you want to gauge what a document will look like printed. So the important parts of this sort of resolution independence can be (and mostly are) implemented in individual print-media creation apps.

The second reason is that resolution independence might soon become moot. Displays are rapidly becoming too high-res for a person to distinguish individual pixels: the iPhone 4 already achieves this at typical smart-phone viewing distances, and I would argue that my iMac and the new 11” Air are, if not already there, really close (at their typical viewing distances). If and when desktop and notebook displays reach Retina Display resolution, Apple could simply declare that 320 is the new 72 and be done with the whole resolution independence quagmire for good.

A caveat is that some people (particularly those my age and older) are going to want larger controls on an arc-seconds-of-visual-field basis. That in itself might make resolution independence worth fighting for.

Another thought just occurred to me: two 7-inch displays of a plausible aspect ratio add up to one 10-inch display. It could in fact be a Nintendo DS form factor. The displays might be identical, or one might be a low-power version.

That would make it quite a nice two-page-at-a-time eBook reader, a decent sub-netbook (running modified iPhone apps on the top screen with a keyboard on the bottom screen), and could even improve the video phone aspect (think three-way calling).

And the thing wouldn’t have to be any bigger than a smallish paperback.

Given it’s prediction season, and that a lot of folks are speculating about whatever sort of tablet computing device Apple is putting its finishing touches on, I’m going throw my hat in the ring and post my own prediction.

First, I think the thing has two touchscreen displays. That could explain the conflicting stories about whether the display is 7 inches or ten inches diagonally. It would open up like a notebook computer and one of the displays would become a keyboard. So it’s a ultralight notebook, like an airier MacBook Air, and with built-in 3G connectivity.

I think the second display — actually a hybrid of a display, a reconfigurable keyboard, and a trackpad/pointing device — may even be an eInk or OLED or other low-power type. And I think they would’ve come up with some clever system of hinges and/or sliders that would allow the full-power display to either close up like a notebook (protecting both displays from the ravages of the inside of a backpack) slide behind it. In this second mode it’s a eReader, like the Kindle, Nook, or Sony Reader.

Of course Apple’s multifunction products usually have feature sets that come in threes (“it’s a phone, a widescreen iPod with video, and a breakthrough internet communicator”). My best guess as to the third function would be as a two-way video phone connected over the mobile phone network.

I suspect the design language might follow that of the Magic Mouse, as it’s new and strangely distinct from just about everything else Apple is selling right now. Not that the iMac ever looked like a Mighty Mouse, but no other current product of theirs has the combination of aluminum, plastic, and compound curves that the Magic Mouse has.

I’m not sure how they would pull the mechanical design off, particularly since Apple is so averse to fiddly or flimsy-feeling mechanisms. My best guess is that the keyboard/CPU/battery portion is like a bigger, solid-aluminum iPhone, and that the high-power display is a concave plastic cap that fits over the top and/or bottom of that, depending on the configuration.

So it think Steve will pull it out of his pocket and presented first as an eBook reader. Then Steve will flip the display around and “boom”, it’s also a netbook. Finally he’ll have Phil or Tim give him a video call.

I spent about an hour yesterday carefully stepping through some code that was setting the text of a UILabel in an iPhone app I’m working on. It worked perfectly on my 3.0 development box and my 3.0 device, but for some inexpicable reason, the text wasn’t showing up on my client’s 2.0 machine or device.

(more…)

Apple released the beta version of their iPhone SDK yesterday, and the response from the developer community was an unintentional DDoS of the entire developer.apple.com domain. But there are a few caveats to the otherwise Christmas-morning-like announcement.

Among them is that to get an app into the hands of users, a developer must sign up for a $99 app-signing license, and then sell the app through Apple’s iTunes-esque store, with Apple taking a 30% cut. This is really convenient (if a bit expensive) for the developers, but runs up against the established business model of the vast majority of indie Mac OS X developers: try-before-you-buy shareware. In this model, the software is distributed free-of-charge, often with limitations or nagging that can be turned off (or extra features that can be turned on) only by entering a license code purchased from the developer. It’s not completely clear how this would work under Apple’s model.

But another thing Apple released yesterday was a Mac-OS-based iPhone simulator. Right now it’s Mac-only, and it may or may not be a major PITA for Apple to port this functionality to run under Windows, but it represents an ideal solution to most instances of the try-before-you-buy conundrum: Apple would merely need to allow developers to link their app against the simulator and to distribute the resulting bundle as a trial version of their app. If by playing around with it on your (non- or less-mobile) desktop or laptop you decide that you like it, you would pay to download it from Apple’s store.

Now it’s true that a linked-against-the-simulator app could lead to piracy, but realistically the App Store will do little more than to keep honest people honest; dishonest people will most likely just copy the app from a hacked iPhone. It’s also true that people might use the simulator-widgets on their computer in lieu of paying to use it on their iPhone. But typically anything that can be done on an iPhone can be done better on a PC, albeit in a less pocket-sized fashion.

So I believe that represents another category of people who wouldn’t have purchased the app anyway.

Dictionary.app in Mac OS 10.5 (Leopard) reliably hangs when first launched. Even with a very high-bandwidth and low-latency connection to the Internet.

Apparently this is due to the new Wikipedia functionality built into it. Until Apple fixes this, the easiest way to put teh snappy back into your Dictionary is to open the preferences and uncheck Wikipedia as a source.

In anticipation of getting an iPhone for Christmas, I moved my personal email account from my hosting company to GMail, using Google Apps for my domain. GMail gives me IMAP, first-rate spam filtering, and more storage than I can shake a stick at. I couldn’t be happier with my arrangement, in particular how well it works with my iPhone.

However, there is a project I’m involved with that would benefit from subscribing to a couple of high-traffic mailing lists. While I’d like to be able to peruse and participate in these lists, I don’t want them clogging up my iPhone’s inbox.

It turns out this is pretty easy to accomplish. First, sign into the web interface for your GMail and add a label (click “Edit Labels” in the left sidebar) for the mailing list. Since I followed the advice on the GMail link above and added the [Gmail] IMAP prefix to the account in Mail.app, I will also need to prefix the friendly name of my label with [Gmail]/ (e.g. [Gmail]/List). On my Mac this will show up as an additional IMAP folder at the bottom of the sidebar.

Now you just have to create a filter (click the “Filters” tab under your GMail settings) that will automatically apply the label if the email in question is involved in the mailing list. Choose the appropriate criteria (the “Has the words” setting might be best, since often times “to” address isn’t what you’d expect). After clicking “Next Step” to continue, select the label, and — to keep it from showing up in your inbox — check the “Skip the Inbox” setting as well.

I can now receive email from the mailing list and it goes directly to my archive folder, receives the proper label, does not pass go, and does not collect $200.

One last thing: to get the label/folder to show up, I had to right-click the account in Mail.app and select Synchronize. YMMV.

These steps will let you follow one or more high-traffic mailing lists without them interrupting you every time a message is sent, but also without the latency of receiving digests instead of individual messages. It turns the mailing list “workflow”, if you will, into something closer to that of an RSS feed.

Update: Here’s an easier way.

In anticipation of getting an iPhone for Christmas, I moved my personal email account from my hosting company to GMail, using Google Apps for my domain. GMail gives me IMAP, first-rate spam filtering, and more storage than I can shake a stick at. I couldn’t be happier with my arrangement, in particular how well it works with my iPhone.

However, there is a project I’m involved with that would benefit from subscribing to a couple of high-traffic mailing lists. While I’d like to be able to peruse and participate in these lists, I don’t want them clogging up my iPhone’s inbox.

By combining a few esoteric features of GMail and Mail.app, I have come up with an arrangement that works superbly.

(more…)

For those of you used to running lookupd -flushcache to clear out stale entries from your DNS cache in Mac OS X, the new version (10.5) has replaced the old NetInfo suite with a bunch of new, more compatible utilities. The new way to do this is dscacheutil -flushcache.