Freeverse is proud to offer DF readers a 20% discount on the powerful sound editing software, SOUND STUDIO 3. An easy-to-use and extensively AppleScript-able Mac OS X application, use it to record live performances and podcasts, digitize tapes and vinyl records, and create your own mixes with crossfades. Tweak the levels and EQ, apply digital effects, and save in all major file formats! The essential tool for working with digital audio. Use coupon code FIREBALL during checkout to receive the discount, good until December 8.

A few weeks ago I wrote about the Richard Solo iPhone/iPod Backup Battery — a small $50 external battery pack you can plug into an iPhone or iPod’s dock port to supply an extra charge.

They’ve already come out with a second model, the Richard Solo 1800, which just started shipping last week.1 The “1800” in the name refers to battery capacity: 1800 mAh, one and a half times the 1200 mAh capacity of the original Richard Solo Backup Battery. For now, they’re selling both models, the 1800 for $70, the 1200 for $50.

As is plainly evident, the 1800 sports an entirely different industrial design:

It’s still small enough to be easily carried in a pocket, but it’s about an inch and a half longer and slightly wider. Including the dock connector, it’s not that much shorter than the iPhone itself, and for some reason even seems designed so as to resemble a hypothetical iPhone Nano. It doesn’t feel much heavier than the original Solo battery pack, though. Latched to an iPhone 3G, it fits, just barely, in the front pocket of a pair of Levi’s.

In my testing, the 1800 stores enough power to give a nearly-depleted iPhone a complete charge. Starting with an iPhone that had already shown the “10 percent remaining” warning, the iPhone was back to about 25 percent within 15 minutes, 60 percent in 30 minutes, 85 percent after an hour, and fully charged (or nearly so) in about two hours. (These percentages are my eyeballed estimates from the lock-screen battery gauge.) In my tests, the original 1200 mAh Richard Solo battery only restored a depleted iPhone to about 70 percent.

The other major improvement in the new model is that the dock connector latches when connected. To release it, you need to press two buttons on the sides of the battery. The original model doesn’t latch, and I’ve found that it sometimes loses contact when connected to my iPhone in a pocket. I’d go so far as to say that the 1800’s latching connector is a more important improvement over the original than the increased battery capacity.

The 1800 also comes with two plastic support braces, one for the iPhone 3G and one for the original iPhone. The braces are intended to prevent stress from breaking the connector while the battery is latched to the iPhone.

To top it off, the 1800 adds two features that are clearly intended for the Sky Mall audience: an LED flashlight and a laser pointer. Seriously, a frickin’ laser. Well, why not?

The indicator lights on the 1800 are far more sensibly designed than those on the 1200 model. There’s (1) a blue light that indicates when the battery is connected to and charging the iPhone; (2) a green light that blinks while the Richard Solo battery is itself receiving a charge, and which lights up solidly when fully charged; and (3) a red light that blinks when the Richard Solo has below 10 percent charge remaining.

Like the original, the 1800 comes with a plastic cap to cover its dock connector when not in use. It latches, but it’s so small that I still expect to lose it. I’d gladly trade the flashlight and laser for a retractable dock connector.

Also like the original 1200 model, the 1800 charges via a USB cable and comes with an AC power adapter. Unlike the 1200, the 1800 also comes with a dual-USB car charger. So for $20 more than the original, the 1800 offers 50 percent more capacity, a latching connector, a car charger, and a built-in flashlight and laser pointer. The only downside is that it’s physically larger.

The only other 1800 mAh iPhone battery pack I’ve seen is the 3G Juice, which appears to be physically smaller than the Richard Solo 1800, but which doesn’t offer a latching connector.2

If you already own an external battery pack for your iPhone, I doubt it’s worth it for you to buy this one too. But if you don’t own one already, I’d strongly recommend this one over the original 1200 mAh Richard Solo model because of the higher capacity and the latching connector.

1. Disclosure: the folks at Richard Solo sent me an 1800 for testing; I paid for my original model. ↩

2. Nor the fricking laser. ↩

One of the more visible changes in last week’s iPhone OS 2.2 update is a new toolbar in Safari. Here’s the previous toolbar from Safari in iPhone OS 2.1:

It now looks like this:

The new toolbar looks much more like an iPhone-sized version of the desktop Safari toolbar, with the rectangular location text field on the left and the oval search text field on the right. But the new toolbar is functionally equivalent to the old one, with the same three tappable targets: location field, search, and reload.

I prefer the old 2.1 toolbar, but, at this point, I’m hesitant to say that the reason amounts to anything more than 17 months of (very frequent) habit. Here’s what the differences amount to:

• The location field is shorter, so you see less of the URL.
• The reload button seems to be a smaller target, and, because it’s so close to the search field, it seems too easy to mistakenly tap the search field when aiming for the reload button.
• The search field is now a bigger target, and therefore easier to tap, but the old 2.1 search button never felt too small to me. They’ve made something bigger that was already big enough.

So two of the three items in the toolbar have been made worse at the expense of improving the other one needlessly.

But I have a theory why Apple did this anyway. My guess is that testing showed that many iPhone users didn’t know that the magnifying glass in the toolbar was a button they could tap to start a web search. The new layout makes it unambiguous what the search item in the toolbar does, and that may well make the small usability hit to the size of the location field and reload button worth it.

To make better use of the available space in the location field, Safari no longer shows the “http://” or “https://” protocol scheme. You do see the protocol scheme, however, when you tap the location field to edit the URL:

But it’s hidden, sort of like file name extensions in the Mac OS X Finder, in the normal display view.

The best argument in favor of always displaying the protocol scheme is to make it visible when you’re connected via HTTPS, but the lock icon in the location field serves the same purpose, and is almost certainly better recognized by typical users than the extra “s” in “https://”.

This is a pretty clever idea, and once seen in action, it seems so obvious that I’m now surprised that the iPhone version of Safari hasn’t been doing this all along. And it makes me wonder whether the desktop version of Safari will follow this lead — space isn’t at such a premium there, but it’s always struck me as somewhat ungraceful that we spend all day staring at dozens of URLs that all start with the same repetitive prefix.

• DF reader Matt Gough, via email:

  It seems Apple could make the Safari address bar more pleasant looking and useful if they just resized the search field to fit the placeholder text for Google or Yahoo!

  He included the following mockup:

  

  Looks like a total win to me. It retains the improvement to obviousness, remains a large tap target, and adds a few extra pixels to the location field.

• Andy Baio, linking to this article, observes:

  I’m a little surprised they didn’t merge the search and location bar into a single field.

  Space-wise, this would be very efficient, and for us, the sort of people who read (or write) web sites like the one you’re reading now, it’d be pretty cool. But I think it’d have the wrong effect on the sort of iPhone users who didn’t even know they could initiate a web search from the previous iPhone Safari toolbar. The whole point of this change, I think, was to increase obviousness, even if at the expense of a bit of efficiency.

Google’s just-released and much-publicized update to their Google Mobile iPhone app features some very clever interaction design for the voice search feature. There is an on-screen button you can tap to initiate a voice search manually, but, as illustrated in their example video, you can initiate a voice search just by lifting your iPhone to your ear.

In order to trigger this automatic voice prompt, you must:

1. Move the iPhone.
2. Trigger the proximity sensor next to the speaker at the top of the iPhone.

You need to do both, in that order.1 The voice prompt is never triggered by motion alone, nor by covering the proximity sensor without first having moved the phone. The only way it is triggered is by moving the phone and then triggering the proximity sensor. It’s very clever, and the resulting user experience is very nice.

But here’s the intrigue: There is no public API in the iPhone SDK for using the proximity sensor in this way.

As you might imagine considering the number of accelerometer-driven games in the App Store, there are plenty of public API calls to access data from the iPhone’s accelerometer. But the only thing apps can do with the proximity sensor is turn it on and off. When the proximity sensor is on, the screen turns off and stops accepting touch input when you cover the sensor (typically with your head, when holding the phone to your ear to, say, make a phone call, but you can just as easily trigger it by covering the sensor with your finger). By default, the proximity sensor is turned off, and the overwhelming majority of apps leave it that way.

If you’re a registered iPhone developer, you can read the relevant documentation for the proximitySensingEnabled property in the UIApplication Class Reference. An app can check the status of this property (is it on or off?), and can toggle it, but that’s it. After an app has turned the proximity sensor on, the app never finds out when or if it has actually been engaged. There is no way for an app to be notified when the proximity sensor has been triggered.

No way, that is, via the public APIs.

If you use something like the command-line strings utility to examine the UIKit framework, you can see that there’s an undocumented (and therefore private to Apple) method named proximityStateChanged. And if one were to strip the FairPlay DRM from the current Google Mobile application binary — which, of course, you wouldn’t do, because you’re not supposed to strip FairPlay DRM, but I’m just saying if one were to do this — a class dump of the application binary would show that Google Mobile does in fact implement proximityStateChanged.

So, (a) Google Mobile is using an undocumented API, and (b) to my knowledge, there is no way to duplicate the behavior of Google Mobile’s “just lift the phone to your ear to trigger the voice prompt” feature using only the public APIs in the iPhone SDK. Needless to say, using undocumented APIs violates the iPhone SDK Guidelines. A developer that plays by the rules cannot do what Google is doing.

I can think of three explanations for how Google got away with this:

1. Whoever at Apple approved this Google Mobile update did not realize that it was using the private proximityStateChanged method.

2. Whoever at Apple approved it knew that it used a private API, but approved it anyway.

3. Google sought and obtained permission from Apple to use this method.

I do not believe #3 is the case. I’m pretty sure that the App Store approval process is as much of a black box for Google as it is for everyone else.

That leaves #1 and #2, either of which suggests that the Google Mobile team followed the adage that it’s easier to ask for forgiveness than for permission. If this is the case — if — it might explain why Google started publicizing the voice search feature several days before it actually appeared in the App Store. The publicity from John Markoff’s feature in The New York Times put pressure on Apple to accept the app. If there was any internal debate within Apple about whether to allow this, it might explain why the app took several days longer to appear in the store than Markoff’s story indicated Google expected.

#1 is possible. There is no technical barrier that prevents a third-party iPhone app from making calls to undocumented APIs, and I have heard that several apps that do so have slipped past the App Store approval process. But I would presume the Apple employees who examine App Store submissions are well-versed regarding which hardware features are exposed through the official public APIs.

If it’s #2, though, this stinks. Third-party iPhone development is purportedly a level playing field. If regular developers are forced to play by the rules, but Google is allowed to use private APIs just because they’re Google, the system is rigged.

So here’s to hoping that it’s #1. Even in that case, the situation just highlights the problem that a lot of cool features are behind the iPhone’s private APIs — private APIs which Apple’s own apps make full use of. I understand the reason why the developers of Google Mobile used this method — without it, the feature isn’t possible (and, frankly, the proximity sensor isn’t of much use). The downside to third-party use of any undocumented APIs, however, is that undocumented APIs can change or vanish in future iPhone OS updates, which situations inevitably lead some users to be outraged that Apple doesn’t support the unsupported.

My thanks to Robert Marini for assistance researching certain of the technical aspects of this article, including going so far as to build an iPhone app to test whether any documented application delegates are triggered when the proximity sensor is engaged. (The answer is no.)

1. This explains why, if you turn on Google Mobile’s off-by-default setting to allow the UI to rotate, the automatic voice search prompt is disabled. By default Google Mobile tracks motion to see if you’ve moved the phone to your ear; turning the UI rotation option on means it instead tracks motion to see if the display orientation should be changed. I suspect the two uses conflict, in that when you rotate the iPhone, your thumb is likely to cover the proximity sensor. ↩

On the desktop version of Safari, when you use the built-in Google search field, you get pretty much the same results page as when you go to google.com and enter your query the old-fashioned way. The toolbar search field is just a more convenient way to get the same results.

But that’s not the case on the iPhone. On the iPhone, when you use the toolbar search field (the one you get by tapping the magnifying glass button next to the location field), you get Google search results that look pretty much exactly like Google’s default web presentation, shrunk down to fit on the iPhone screen:

In this initial state, the results are effectively illegible. But if you start your search by loading the google.com home page, you get a results presentation that is specifically optimized for MobileSafari:

The text is perfectly sized, and the entire page layout is optimized for the iPhone display.

Admittedly, the un-optimized presentation you get via the toolbar button isn’t a big deal, because you can double-tap on the results column to zoom in:

But even then it’s still not as nice as the version you get through the web site interface. I don’t understand why, if Google has an iPhone-optimized search results mode, this mode isn’t used for queries initiated via the iPhone’s built-in Google search field.

It’s not clear to me whether Apple should change MobileSafari to send a different query string to Google to trigger these iPhone-optimized results, or whether Google should just handle it on their end, the same way they already serve an iPhone-optimized version of their home page to iPhone users.1

Update 1: Looks like Google engineers Steve Kanefsky and Rob Stacey wrote about this last week for the Google Mobile Blog:

Over time, we intend to make the newly formatted results pages available through other search entry points on the iPhone, on additional devices, and in more language and country combinations.

Update 2: I neglected to mention that if you change your default MobileSafari search engine from Google to Yahoo, the search results from Yahoo are iPhone optimized:

Right idea, but I don’t care for Yahoo’s presentation. Each result is too big — you can only see the first two without scrolling, whereas with Google’s iPhone display you can see four.

1. In addition to sizing and positioning the form fields on the Google home page in a way that’s optimized for the iPhone, there’s also a very nice as-you-type menu of suggested search terms. Google, company-wide, has made some of the best iPhone-optimized web sites I’ve seen. ↩

On the heels of winning MacUser’s Business Software of the Year and a Macworld Eddy for 2007, Marketcircle recently released Billings 3. Billings is a time tracking and invoicing application that produces some of the most professionally formatted invoices, helping you maintain your image when it counts the most — asking for payment.

On top of the great features such as the menu bar timer, Billings 3 brings approximately 50 new enhancements including: a new and simplified interface, 18 additional invoice templates for a total of 30, statements, recurring invoices and more. Try it free for 21 days and take advantage of the current “Give Main Street a Break” sale.

My email “system”, such that it is, is pretty simple. For each of my main accounts I use just two mailboxes: an inbox and an archive. The inbox is for new mail, and the archive is where all messages go when I’m done with them. I can’t say I follow Inbox Zero, Ringo, but I’m trying. I’m tryin’ real hard to be a shepherd.

One habit I’ve found to be harmful is using “unread” to mean anything other than “new message”. For years, I’d let email I didn’t want to deal with immediately sit “unread” in my inbox, and I’d eventually wind up with hundreds of “unread” messages. I put quotes around unread because most of those messages weren’t literally unread — I’d looked at them, but then marked them unread because I didn’t want to deal with them yet. Breaking myself of this habit significantly increased my email efficiency.

I have three main accounts, and at this moment, they have 2, 24, and 18 messages in their inboxes. Not zero, but not out of control. At one point about two years ago, I had over 4,000 unread messages in the inbox for my public contact address for Daring Fireball. I had actually read, or at least skimmed, most of those, but at that point there was no way to catch up, and no way to identify the older messages that I’d truly never even looked at.

What I do for messages I want to keep in my inbox after reading, for whatever reason, is mark them as flagged. In my system, all that flagging implies is that I want to keep the message in my inbox. Of those aforementioned 2, 24, and 18 messages in my inboxes at this moment, all of them are flagged, and none of them are marked unread. So while I’m not — and to be honest, never am — at inbox zero, I am almost always, at the end of each day, at unread zero.

In one regard, the iPhone has been a tremendous boon to keeping my email manageable. Pre-iPhone, I’d often fall woefully behind on email from DF readers while I was traveling. The iPhone makes it easy to read messages here and there, a few minutes at a time, throughout the day. Have a few minutes? Read a few messages.

But the iPhone Mail app’s lack of support for flagging has been a constant irritation. The primary thing I want to do with email on the iPhone is triage — most messages I can read once and forget. I’ve written before about the AppleScript I wrote that moves read, unflagged messages from my inboxes to their corresponding archive mailboxes. I don’t bother moving messages from the inbox to the archive folder one at a time, either on my Mac or on my iPhone. I just let that script move them all at once a few times a day.

The problem with the iPhone’s lack of support for flagging is what to do with messages I read on the iPhone, but which I want to deal with later. Most times it’s simply a case of a message which demands a response that would be too long to peck out on the iPhone keyboard. Without flagging, I took to marking such messages unread. But that never sat right with me — both because I’d already broken the habit of using “unread” in this way on the desktop, and because it completely throws off the utility of the unread message count in Mail’s icon badge. I really want the number in that badge to represent new messages, not new messages and all the old ones marked unread because you didn’t want to deal with them on the iPhone.

What I really want is to be able to mark messages as flagged using the iPhone. But, absent that, I’ve come up with a simple workaround that’s worked well for me. Here’s how it works:

1. In each IMAP account I access from my iPhone, I’ve created a new top-level mailbox named “[Flag]” — one mailbox with the same name in each account. The name isn’t special — I added the brackets because most of my accounts are hosted at Gmail, and “[Flag]” sorts alphabetically before the magic server-side “[Gmail]” folder.

2. From the iPhone, whenever I read a message I want to flag, I move it to that account’s “[Flag]” mailbox. It takes just two quick taps.

3. When next I read email on my Mac, I run the AppleScript shown below. The script is very simple — it looks through every IMAP account looking for mailboxes named “[Flag]”. When it finds one, it sets the flag status for every message therein and moves them back to that account’s inbox.

Here’s the source to the AppleScript. If you want to use a mailbox name other than “[Flag]”, just change the string on line 6.

To use it, copy the source, paste it into Script Editor, and save the script in your ~/Library/Scripts/Applications/Mail/ folder.

Robert X. Cringely’s latest column regards Apple’s replacement of Tony Fadell with Mark Papermaster as head of iPod and iPhone engineering:

So here’s what’s going on with Tony Fadell. First, he was vulnerable as a charismatic leader in his own right who has been talked about in the press as a possible heir to Jobs. That alone meant he had to die, but it wasn’t enough to mean that he had to die just now. That decision required an external variable in the form of former IBM executive Mark Papermaster.

The first thing worth noting is that Papermaster was not hired to take the exact same job that Fadell held. Papermaster’s job is a superset of Fadell’s. It’s right there in the press release Apple issued a week ago — Fadell’s title was “senior vice president of the iPod Division”, Papermaster’s title is “senior vice president of Devices Hardware Engineering”. The PR describes Papermaster’s responsibilities:

Apple today announced that Mark Papermaster is joining the Company as senior vice president of Devices Hardware Engineering, reporting to Apple CEO Steve Jobs. Papermaster, who comes to Apple from IBM, will lead Apple’s iPod and iPhone hardware engineering teams.

Tony Fadell only oversaw the iPod division, and had very little, if anything, to do with the iPhone. And, according to multiple sources familiar with Apple’s engineering management, the iPod Touch has been produced by the iPhone team, not by Fadell’s iPod division. The last new product that Fadell oversaw was the new iPod Nano.

So Fadell was never in any way in charge of the iPhone or iPod Touch; Papermaster’s job description indicates he will be directly responsible for all iPhone and iPod hardware engineering.

The iPhone’s software is overseen by Scott Forstall (Senior Vice President, iPhone Software), and, at a technical level, Bertrand Serlet (Senior Vice President, Software Engineering). There is no such division between hardware and software with the traditional (pre-Touch) iPods. The story I’ve heard is that at the outset of Apple’s iPhone initiative, there was a heated debate within Apple as to what OS should be used. Forstall and Serlet pushed for using OS X. Fadell (and, according to one source, former Apple executive Steve Sakoman) pushed for using something else.1 Obviously, Forstall and Serlet won this debate, and, hyperbolic though it may sound, it may prove to be the single best early design decision in the entire history of the company. It seems hard to imagine the iPhone any other way now, but at the outset it was not a foregone conclusion that a stripped down and revamped version of OS X would work for a mobile phone.

And so I think Cringely is right that the basic story line is that Steve Jobs wanted to hire Papermaster and so Fadell had to go, and not that Fadell first decided to leave and Papermaster was then picked to replace him.2 But Fadell’s ticket has probably been punched ever since the iPhone shipped and proved to be an enormous success.

Without question, Fadell’s tenure at Apple has itself been an enormous success. He came to Apple in early 2001 with the idea for the iPod and an integrated online music store to complement it, and it turned into one of the biggest hits in consumer electronics history. The iPod and iTunes reshaped the music industry, and have made a mountain of cash for Apple. But the iPhone is the new thing, and Fadell was not involved in its development. The word on the street in Cupertino is not that Fadell was pushed out the door, but that he was never offered a role like Papermaster’s, encompassing all of Apple’s handheld hardware engineering. The iPhone has eclipsed the iPod as the A Team at Apple, and Tony Fadell does not sound like a B Team sort of guy.

Cringely’s speculation about Jobs in any way feeling threatened by Fadell, or that “Jobs ultimately betrays all of his direct reports in this manner”, is just goofy. Steve Jobs is not insecure; if he were, he’d have canned someone like Jonathan Ive long before putting the squeeze to Tony Fadell — Ive is far better-known than Fadell outside the company, and is far more popular inside.3 For a company of Apple’s size and success, the relative stability of its executive team is remarkable.

1. Updated, 13 Nov. 2008: The original text of this footnote read:

   None of the sources I spoke to knew what specifically Fadell had in mind. But the idea wasn’t that they would use some other OS to build the iPhone as we know it, but rather to build what would have been a very different iPhone.” The best guess is that Fadell was pushing for something more along the lines of an iPod that could make phone calls, and less along the lines of a new handheld computing platform.

   However, I now have a one-word answer from a knowledgeable source as to which OS Fadell wanted to use for the phone: Linux. ↩

2. Cringely speculates that the “Senior VP, Devices Hardware Engineering” title is just a placeholder for Papermaster while Apple waits for his IBM non-compete to expire, at which point his true role at the company will be revealed to be leading the chip design team Apple acquired when they bought PA Semi. I have no doubt that Papermaster’s expertise and experience in this field is a big part of why Apple wanted to hire him, but leading the hardware engineering division responsible for all iPods and iPhones is a far bigger and more prestigious gig than leading a chip design team. I don’t think there’s anything secret at all about Papermaster’s intended role at Apple. ↩

3. One source put it to me this way: “Steve Jobs is a good jerk, Tony Fadell is a bad jerk.” ↩

BBEdit 9 is the leading professional HTML and text editor for Mac OS X. Crafted to meet the needs of content and application developers, BBEdit delivers high-performance text editing at your fingertips, allowing you to be productive right out of the box.

An intelligent interface provides easy access to BBEdit’s best of class features including Projects, multi-file search and replace, extensive HTML tools, grep pattern searches, text & clipping completion, language support for JavaScript, Ruby, Perl, Python and over two dozen others, code folding, direct FTP and SFTP editing, AppleScript, Unix scripts and filters, and much more!

Some thoughtful feedback from readers regarding my analysis of the UI design of the iPhone’s built-in Notes app.

Regarding my assertion that sorting notes by modification date was the right choice, Glen Raphael1 writes:

That would be fine for me if it were sorted chronologically by note creation time. That is what the Newton NotePad did and what the Palm notepad app did — quite sensibly. However, what Apple chose to do here was sort by note modification time. Which is insane.

If I take notes in a variety of contexts over time, my notes are nicely sorted in historical order — the older notes are further down the list and notes taken at a similar time are in proximity to one another. So I can use my temporal memory to find things. Paper notepads in the real world work like that too. But on the iPhone if I ever go back to review my old notes and make any changes, those notes spontaneously jump to the top of the stack. That has two negative consequences:

1. After reviewing and revising old notes, my notes are in a random order. Given that the chronological ordering has been violated and there’s no search feature, you simply can’t find old notes in a large stack. It doesn’t scale the way the Newton/Palm/everybody-else -in-the-known-universe approach does.

2. If I scroll back to find an old note, revise it, and want to continue scrolling back to look at or revise the next note before that one… I can’t find it. Because the note I just changed has moved, it’s no longer adjacent to the one taken before it. This means lots of extra scrolling if I want to try to find the next note in series.

In notepad apps on other platforms, I could easily scroll to the 40th newest note, delete a couple parts of that note I no longer care about, click/tap/button press once to get to the 41st newest note, fix a typo there, click/tap/button press once to get to the 42nd note and read it to refresh my memory, and continue down the stack — reading and revising as I go along. Try doing that with iPhone and you’ll want to throw the thing against a wall.

As a result of this “feature” I no longer use Notes. I’ve switched to MagicPad and wish I could just delete Notes. Yeah, MagicPad has got copy/paste and font stuff, but for me the killer feature was simply that it allowed me via a settings preference to sort by note creation time, which is clearly the correct default.

These are strong points. I don’t keep a ton of notes in my iPhone around at a time — I carry a paper notebook with me wherever I go, and which is where I jot most transient thoughts/items. I use Notes on the iPhone mostly for reference material I’ll want to come back to many times (which is to say, over a long enough period of time that I’ll have gone through several paper notebooks over that period), and for very specific temporary material like my airline flight reservation number for a trip.

If you’re the sort of person who uses Notes for everything — say, if you’ve got dozens of notes — I can see how sorting by modification date might be maddening.

It also occurs to me that sorting by creation date would fit better with Notes’s “looks like a paper tablet” visual metaphor. With a paper notebook, it’s easy to find something you know you jotted down “about a month ago” just by flipping back to the right spot in the notebook.

In short, switching Notes to creation date sorting seems like a good idea. It would work better for people like Raphael, who keep a large number of active notes — and it would work just about the same for people like me, with a small number of active notes. Light users of Notes almost certainly wouldn’t even notice the change.

iPhone apps typically take at least a few seconds to launch, sometimes more. Developers can include an image to be loaded immediately after the app launches, named “default.png”. You can use this as a splash screen (more or less as a title card for the app), or, you can display the empty skeleton of the app’s UI (making it look like the real UI is starting to load, when in fact it’s just a screenshot of an empty UI).

Apple’s own apps — which don’t have the same restrictions as third-party apps — have another option available, which I’ll call “dynamic default.png”. What many Apple apps do is take a screenshot of the current display when you quit, and overwrite the default.png file inside the application bundle with that screenshot. Then when next you launch that app, you immediately see the entire contents of the screen from when you previously quit — but it’s still just a screenshot, a static image. It looks like the app has launched instantly, but in fact you’ve still got to wait a few seconds for the app to restore itself to the point where it’s actually ready to use.

I’ve seen third-party iPhone developers complaining that this trick is only available to Apple; they want to use it too. The technical reason why they can’t is that because application bundles are cryptographically signed, you can’t modify the contents of the application bundle (by, in this case, changing the default.png resource file) without breaking the digital signature. Apple could enable this feature for signed applications by providing for a way to specify a dynamic default.png that exists outside the application bundle, somewhere in the application’s private Library folder.

But I don’t think these dynamic default.png files are a good idea in the first place. I fully realize that the user’s perception of performance is often more important than actual measured-by-a-stopwatch performance, but in the case of dynamic default.png files, I think it goes too far. It is frustrating to see a complete UI that looks usable but isn’t. Dynamic default.png files make application launch times look faster, but they don’t make them feel faster. I feel like a dolt every time I get tricked into uselessly tapping UI elements on a default.png screen.

Notes uses this dynamic default.png cheat, and there are only very subtle indications to tell when the actual UI has replaced the screenshot (and is therefore ready to use). Several readers wrote in to complain about their frustration at not being able to tell when Notes is actually ready to use. Keshuv Prasad writes:

The splash/loading screen for the list view is identical to the loaded view and gives no indication when one becomes the other. In note view the background lines blink when the loading screen turns into a loaded screen, but the pre- and post-loaded screens are identical.

Photos, for example, displays a blank list as its splash screen and only shows the individual items (Camera Roll, Photo Library, etc.), after the app has loaded.  This makes it easy to tell whether the app is loading or has already loaded.

Applying this same design to Notes would reduce frustration with not knowing whether or not the screen is responsive or not upon loading the app (note view would show a blank note, with the appearance of text indicating that it has finished loading).

I too find the Photos model — where you just see a more or less empty shell of the UI upon launch — to be superior. That way, as soon as you see actual content, you know the app is ready to use.

Prasad has another good suggestion:

My second issue is how the notes are displayed in list view. There are up to 8 notes listed and the bottom one’s row fits exactly on the screen.  To use Photos as an example, it only displays 7 full rows, with the 8th row cut off.  Yes, the number of notes is in parentheses after Notes, but having the last row cut off (Contacts does this as well) would be a nice visual indicator that there is something below to scroll.  This is a minor quibble, though.

In other words, because iPhone list views don’t show persistent scroll bars (which, on the Mac, provide an indication when there is more content below what is visible), it’s helpful if the row height is such that a whole number of rows don’t fit exactly on screen. Good suggestion.

1. In a previous Apple handheld platform universe, Raphael was the developer of NewtPaint. ↩

Like most of you, I suspect, I’ve wound up with an awful lot of white Apple earphones over the last seven years. There have been subtle changes to the earbud shape, and the iPhone introduced the wonderful clicker (click for play/pause, double-click for next track, triple-click for previous track), but one thing has remained a constant: the cords get terribly tangled when bunched up in a pocket or pouch.

This has been a constant irritation for me ever since I first got an iPhone. In the back of my mind, I’ve had the vague hope that the problem would eventually be solved by wireless earphones.

When I got my iPhone 3G in August, I did notice that the cord of the included earphones felt different — they had a distinctly more rubbery, less plasticky texture. I didn’t give it much thought.

On an airplane yesterday, as I took them out of their pouch on my carry-on bag, I suddenly realized that the difference was more than just texture. These new earphone cables are somehow very much tangle-resistant. Back here in my office, where I’ve got a slew of older Apple earphone sets to compare them against, the difference is striking. You can just ball these new ones up into a glob, stuff them in a pocket, and then just shake them straight when you take them out.

Perhaps this new tangle-resistant cable is old news that I somehow missed, but now that I’ve noticed it, I can’t help but hold it up as a quintessential example of Apple sweating the details.

Update, 7 Nov 2008: A well-informed little birdie tells me that the primary reason behind the new earphone cord was environmental. Apple has switched from PVC to PTFE for all cables, and the increased tangle-resistance was a pleasant side-effect.

Hunter S. Thompson, September 1972:

The polls also indicate that Nixon will get a comfortable majority of the Youth Vote. And that he might carry all fifty states.

Well… maybe so. This may be the year when we finally come face to face with ourselves: finally just lay back and say it — that we are really just a nation of 220 million used car salesmen with all the money we need to buy guns, and no qualms at all about killing anybody else in the world who tries to make us uncomfortable.

The tragedy of all this is that George McGovern, for all his mistakes and all his imprecise talk about “new politics” and “honesty in government”, is one of the few men who’ve run for President of the United States in this century who really understands what a fantastic monument to all the best instincts of the human race this country might have been, if we could have kept it out of the hands of greedy little hustlers like Richard Nixon.

McGovern made some stupid mistakes, but in context they seem almost frivolous compared to the things Richard Nixon does every day of his life, on purpose, as a matter of policy and a perfect expression of everything he stands for.

Jesus! Where will it end?

It ends here, today.

I love this country.

Anyone involved in Mac software development is familiar with arguments over whether a particular app is “Mac-like”. In the early days of the Mac — the first decade or so — the entire Mac community was largely in agreement about just what this meant. To be un-Mac-like was to be ignorant of the fundamental concepts and norms of the Mac OS. It was something you could spot in an instant — software designed by engineers who just did not get it.

In the last decade, however, accusations of “un-Mac-likeness” have largely degenerated into meaningless hand-waving. You still occasionally see UI mistakes that are genuinely un-Mac-like — like, say, outright Windows-isms such as ordering dialog box buttons OK/Cancel rather than Cancel/OK — but in most cases, when someone complains “that’s not Mac-like”, what they really mean is “I don’t like that.”1

The overriding factor, I think, is that the overall scope of the Mac platform (and Windows, too, for that matter) has grown so large that it supports a wide variety of UI design philosophies and styles. iPhoto and Aperture have very different styles, both visually and functionally, but yet they’re both photo management apps made by Apple.

There are still fundamental norms and conventions which all Mac software should adhere to, but there no longer exists a single, simple, overall design style or philosophy that defines Mac-likeness.

The iPhone, on the other hand, is very much where the Mac was in the 1980s. It is new, innovative, and ambitiously stretches the bounds of what current hardware can support. Like the Mac, the iPhone has established UI conventions that aren’t just different, but contrary to the conventions of what has preceded it. Apple has sketched out a remarkably clear picture of what it means for an app to be “iPhone-like”.

And, just as many third-party Mac developers in the ’80s struggled to design Mac-like software because they couldn’t shake preconceptions forged in the “everything is just text” pre-Mac era, many third-party iPhone developers aren’t wholly getting the iPhone-like part. In many cases, I think, it’s because they can’t shake preconceptions forged designing Mac software.

I’ll put forth one central, overriding guideline for iPhone UI design:

Figure out the absolute least you need to do to implement the idea, do just that, and then polish the hell out of the experience.

I further suggest the following, more specific, guidelines:

• Each screen should display one thing at a time. That “thing” may be a list, but it should just be a list.
• Minimize the number of on-screen elements.
• Make UI elements large enough to be easy to tap; place them far enough apart that there is little risk of tapping the wrong target by mistake.
• Eschew preferences as much as possible, and assume that nearly all users will use the default settings.
• As you show more detail, conceptually you move from left to right — but it’s best to minimize how deep you can get while drilling down to the right.

These guidelines describe nearly every iPhone app designed by Apple, and apply to the ones I like most from the App Store.

As a case study, consider the iPhone’s built-in Notes app. This app is an excellent example of what it means to be iPhone-like.2

There are only two screens in Notes. First, a list of all Notes. A row in the list shows the note’s title and the date on which it was last modified. The list is always and only sorted chronologically, most recent first. There are only two things you can do at this screen: open an existing note by tapping it, or create a new note by tapping the “+” button that is always visible at the top of the list. There are no folders. There are no other sorting options.

When you create or edit a note, the toolbar at the top offers two buttons: “Notes”, which points back to the left and takes you to the list of notes, and “Done”, which ends the editing mode by putting the keyboard away and using the full screen to display the contents of the current note. There is no explicit “Save” button — changes are always saved automatically. There is no “Cancel” button when creating a new note; just hit “Done” or “Notes” before typing anything and no new note will be created.

There is no separate title field. The first line of text in the note is used as the title. Change the first line of the note, and you change the name of the note.

After opening an existing note, there is no “Edit” button — to switch to editing mode, simply tap the content area of the note itself and the keyboard will appear, with the insertion point at the position where you tapped in the note.

In an interview with Kyle Baxter in July, Brent Simmons said this regarding his design for the iPhone version of NetNewsWire: “Clarity is more valuable than density.” The iPhone’s Notes app is clear and sparse — or, perhaps better put, clear because it is sparse.

The only metadata displayed on the note screen is the modification date. The toolbar at the bottom of the note has just four buttons:

• A left arrow to move to the previous note.
• An envelope to send the note as an email message (without leaving the Notes app).
• A trash can to delete the note (with a two-button Delete Note/Cancel confirmation panel).
• A right arrow to move to the next note.

The left/right buttons aren’t necessary functionally, but they are necessary in order to avoid annoyance. Without them, to scan through multiple notes, you’d need to do a “back to the list, tap the next note, back to the list, tap the next note” dance.

This is the entirety of the Notes app. I’ve looked at several note-editing apps available in the App Store, and most of them seem to have been designed without any recognition of just how clever and well-designed Apple’s Notes app is. Notes exposes its core functionality clearly and obviously, launches very quickly, requires very few taps to use, and uses just two simple levels of hierarchy (the flat list of notes, and the notes themselves). After more than 16 months using the Notes app, I’ve found that having the list sorted chronologically is exactly what I want nearly all the time.

That’s not to say Notes, as it stands today (which is to say, as it stood when the original iPhone debuted, since it hasn’t changed since then) cannot be improved.

• The biggest missing feature, clearly, is syncing. Email is currently the only way to export notes from Notes, and there is no way at all to import. There practically begs to be some way to transfer snippets of text from your computer to the Notes app on your iPhone, but there is none. This is a major feature, and, currently, the biggest opportunity for third-party note apps.

• A search feature would be nice. I imagine something along the lines of the search field Apple added to the Contacts list in iPhone OS 2.0, sitting at the top of the list of notes; type a search string and the list of notes would be filtered to display only those which match.

• Notes doesn’t rotate. It should, for the benefit for those who prefer typing on the horizontal keyboard.

And that’s pretty much it for my Notes wish list — a pretty short list.

1. I think the logic behind this goes something like this: I like the Mac UI overall; but I don’t like this specific UI design; therefore this specific UI design is not Mac-like. ↩

2. No, I don’t like the Marker Felt font Notes uses. But that’s a subjective cosmetic niggle. ↩

Macworld Conference & Expo
January 5-9, 2009
Moscone Center — San Francisco, CA

Macworld Conference & Expo’s Early Bird Deadline is December 1st so Register Today to Save!

Macword offers access to hundreds of Mac products and services, paired with expert advice, demonstrations, and instruction. The 2009 event is focused on creating a Macworld experience based on your interests. Offering extensive conference content, special presentations, expo hall highlights and activities, Macworld has something to meet your specific needs. Check out all that Macworld has to offer at www.macworldexpo.com and Register Today!

[Update: Addendum regarding iPhone SDK guideline 3.3.2 appended.]

I’ve done some digging on this “Opera Mini was rejected from the App Store” story, and the truth appears to be very different than what has been reported and assumed.

It all started with this paragraph from Saul Hansell on the NY Times Bits weblog, regarding Opera CEO Jon Stephenson von Tetzchner:

Mr. von Tetzchner said that Opera’s engineers have developed a version of Opera Mini that can run on an Apple iPhone, but Apple won’t let the company release it because it competes with Apple’s own Safari browser.

Note, though, that this is not a quote from von Tetzchner — he’s being paraphrased by Hansell.

My understanding, based on information from informed sources who do not wish to be identified because they were not authorized by their employers is that Opera has developed an iPhone version of Opera Mini, they haven’t even submitted it to Apple, let alone had it be rejected.

One thing I hadn’t realized before is that Opera has two different mobile browsers: Opera Mini and Opera Mobile. Opera Mobile is pretty much a traditional, regular web browser. It’s Opera, but stripped down and optimized for mobile platforms. Opera Mini, though, is something else. Rather than a web browser that interacts with web sites directly, Opera Mini goes through proxy servers run by Opera.

In a nut, it works like this: You request a URL in Opera Mini. Opera Mini makes the request to a proxy server run by Opera. Opera’s proxy server connects to the web server hosting the requested URL, and renders the page into an image. This image is then transmitted (in a proprietary format called OBML — Opera Binary Markup Language) to the Opera Mini client. Opera Mini displays the rendered image on screen. This may sound convoluted, but apparently the result is very effective — it’s faster to transmit, because only OBML (a compressed binary format) is transmitted to the mobile device over the phone network, and far faster to render on slow mobile processors.

It is Opera Mini, not Opera Mobile, that Hansell indicated that Apple rejected. So, my speculation that it was rejected from the App Store for running its own JavaScript interpreter was wrong — Opera Mini is really only a thin client that knows how to display OBML. It doesn’t even render HTML, let alone contain a full JavaScript interpreter. (Chris Mills wrote a piece on the Opera developer weblog last year regarding Opera Mini and JavaScript.) OBML is more like PDF than HTML. So in theory, I think a version of Opera Mini that complies with the iPhone SDK Agreement could be developed.

However, the version that Opera has developed for the iPhone is problematic in other ways. The cross-platform code base for the Opera Mini client software is written in Java. The assumption being that it should run on any mobile phone with a Java ME virtual machine. The iPhone, of course, doesn’t support Java in any form.

On the Opera Labs web site in April, Chris Mills described how they ported Opera Mini to Android. Android uses the Java programming language for development, but doesn’t use a standard Java virtual machine; instead, for Android, Google has developed their own virtual machine called Dalvik. Here’s Mills’s description of how Opera ported it for Android:

We decided to use the existing Opera Mini code base (even the binary package) instead of creating a separate port, to save on resources. We created a special wrapper that translates Java ME (mostly MIDP) API calls into Android API calls. The tool used was MicroEmulator — this is an open source (LGPL) implementation of Java ME that runs on top of Java SE. The lead Opera Mini Android developer is also the lead developer of MicroEmulator, so it was an inspired choice! The Android platform is similar to Java SE, with the exception of several libraries normally included in Java SE (like AWT/Swing — these are excluded because they would likely be too heavy to fit into the embedded environment.) It is therefore fairly simple to port MicroEmulator to run inside Android environment. The only major task was to replace the AWT/Swing graphics backend of MicroEmulator with Android specific APIs.

So in short, they’ve written their own bridge to run Java ME bytecode on Android.

If what they’ve done for the iPhone is along the same lines — that they’ve gotten a Java ME runtime running on the iPhone — it’s clearly outside the bounds of the iPhone SDK Agreement. The guideline in question is rule 3.3.2, which reads:

3.3.2 — An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and built-in interpreter(s).

My somewhat informed hunch is that the iPhone version of Opera Mini that von Tetzchner alluded to in his interview with Hansell is running only on jailbroken iPhones. If it’s using APIs only available on jailbroken iPhones, it might not even run as it stands today on a standard iPhone using only the official APIs.

What Opera would need to do to have a version of Opera Mini they could submit to the App Store would be to port the entire client software to the C and Objective-C APIs officially supported on the iPhone. It could well be that even then, Apple would reject it from the App Store on anti-competitive grounds — but contrary to this week’s speculation, that has not happened.

And I hope it wouldn’t, because Opera Mini sounds like a very cool app.

Several readers dispute my interpretation of rule 3.3.2, arguing that it does not forbid interpreters in general. The key word in the clause is “downloaded” — that you cannot ship an iPhone app containing an interpreter which allows you to download additional executable content, circumventing the App Store. For example, a generic “Flash Player” app which allowed you to download directly to your iPhone games and utilities written in Flash — that’s the sort of thing 3.3.2 forbids.

An app which contains an interpreter that only executes scripts or bytecode that is self-contained within the app bundle, however, should be permissible under this guideline. And there are, apparently, apps that are shipping through the App Store today using just such technologies.

There are even commercial developer projects like Innnaworks’s AlcheMo, which translate J2ME Java apps to native iPhone apps, and Unity3D, a game development framework based on Mono, using JavaScript, C#, and Python, but which outputs native ARM assembly code and, thus, native iPhone apps.

So there may well be nothing in the iPhone SDK Agreement that would forbid Opera Mini from appearing in the App Store. Again, though, just because an app doesn’t violate the rules doesn’t mean Apple will accept it.

If you read my iPhone 3G review, you know that my biggest complaint was with regard to battery life. The problem isn’t that the iPhone’s battery life is poor compared to other similarly-featured phones. The problem is that the iPhone pushes the limits of modern battery technology — what makes the iPhone great is that it can do so much, but doing that much consumes significant power.

There’s an obvious trade-off between battery size/weight and battery life. I would actually pay more for an iPhone that was thicker and heavier but provided longer battery life. I don’t think Apple should offer such a device (insofar as there are obvious benefits to maintaining the simplicity of the product line by offering only one form factor), just that if they were to offer such a device, I’d have bought it.

Most days, when I go to bed my iPhone still has plenty of gas in the tank. The problem strikes on the days when I go commando — foregoing my MacBook Pro and using my iPhone as my sole connection to the Internet for the day. I no longer lug my laptop with me when attending a conference, for example.

I’ve found that the only way to make it through an entire day like this is to find a way to recharge the iPhone at some point. However, the days when I’m going commando are, by definition, the days when I’m least likely to be anchored near an AC outlet for extended periods.

Several peripheral makers now make external battery packs that fill this need. The basic idea is that the battery pack holds an extended charge, and when you need it, you plug it into your iPhone (or iPod) via the dock connector port.

Back in August I bought the $50 Richard Solo Backup Battery. I ordered it directly from their web site. It’s fairly small and holds a decent-sized charge.

You can see that it’s sort of a dongle that, when connected to the iPhone, hangs off the bottom.

The other competing design concept for iPhone battery packs is to make them in the form of an iPhone case — something the iPhone sits inside rather than something that hangs off the bottom. Mophie’s Juice Pack seems to be the leading example of this. I chose the Richard Solo dongle for two reasons: it’s far easier to keep in a pocket when not in use, and (b) it was half the price ($50 vs. $100). A third advantage is that the battery dongles should work with any iPhone or iPod — the integrated battery/cases only work with single specific iPhone models.

Here’s how it works. The Richard Solo Backup Battery comes with its own AC adapter. You connect the battery to the AC adapter via an included compact USB cord that plugs into the bottom of the battery. Left like this, the battery will charge. But you can also plug the battery’s dock connector into your iPhone while charging — in this case, the iPhone’s internal battery will charge first, and then the Richard Solo battery will charge. Thus, when traveling, you only need to bring the Solo AC adapter.

In practice, the Richard Solo Backup Battery seems to hold enough juice to add about 50-60 percent of a charge to an iPhone 3G. I.e. after running down the iPhone’s internal battery to the point where I got the “10 percent” warning from the OS, plugging in the Richard Solo Backup Battery and letting it charge the iPhone will restore it to somewhere around 70 percent capacity. It seems to take about an hour for a complete discharge.

You can also use it to slurp occasionally — plug it in for 15 minutes here and there throughout the day. And you can use the iPhone while the battery pack is plugged in — from the iPhone’s perspective, it’s just another power source connected to the dock port.

Is it an amazing amount of external battery power? No. But it certainly feels like $50 worth, and the power capacity seems commensurate with the physical size. And in my experience, it provides just enough extra power to make it through a heavy day of iPhone use.

My biggest complaint is that it ships with a junky plastic cap to cover the dock connector.

It didn’t snap on very tightly even when brand new, and within a week or two, it started falling off while in my pocket. Earlier this month while on vacation, I lost it. You don’t need the cap, but it somehow seems wrong to have the naked dock connector bouncing around in my pocket. A better design would be for the dock connector to be retractable, sort of like the blade on a box cutter.

Minor niggles include the supplied USB cable being too short, it being a little hard to tell at a glance which side of the battery is up, and a somewhat confusing array of LED lights that indicate when the battery is charging and when it is giving a charge.

The bottom line, though, is that it’s the next best thing to having an iPhone with a longer-lasting internal battery.

If you read my iPhone 3G review, you know that my biggest complaint was with regard to battery life. The problem isn’t that the iPhone’s battery life is poor compared to other similarly-featured phones. The problem is that the iPhone pushes the limits of modern battery technology — what makes the iPhone great is that it can do so much, but doing that much consumes significant power.

There’s an obvious trade-off between battery size/weight and battery life. I would actually pay more for an iPhone that was thicker and heavier but provided longer battery life. I don’t think Apple should offer such a device (insofar as there are obvious benefits to maintaining the simplicity of the product line by offering only one form factor), just that if they were to offer such a device, I’d have bought it.

Most days, when I go to bed my iPhone still has plenty of gas in the tank. The problem strikes on the days when I go commando — foregoing my MacBook Pro and using my iPhone as my sole connection to the Internet for the day. I no longer lug my laptop with me when attending a conference, for example.

I’ve found that the only way to make it through an entire day like this is to find a way to recharge the iPhone at some point. However, the days when I’m going commando are, by definition, the days when I’m least likely to be anchored near an AC outlet for extended periods.

Several peripheral makers now make external battery packs that fill this need. The basic idea is that the battery pack holds an extended charge, and when you need it, you plug it into your iPhone (or iPod) via the dock connector port.

Back in August I bought the $50 Richard Solo Backup Battery. I ordered it directly from their web site. It’s fairly small and holds a decent-sized charge.

You can see that it’s sort of a dongle that, when connected to the iPhone, hangs off the bottom.

The other competing design concept for iPhone battery packs is to make them in the form of an iPhone case — something the iPhone sits inside rather than something that hangs off the bottom. Mophie’s Juice Pack seems to be the leading example of this. I chose the Richard Solo dongle for two reasons: it’s far easier to keep in a pocket when not in use, and (b) it was half the price ($50 vs. $100). A third advantage is that the battery dongles should work with any iPhone or iPod — the integrated battery/cases only work with single specific iPhone models.

Here’s how it works. The Richard Solo Backup Battery comes with its own AC adapter. You connect the battery to the AC adapter via an included compact USB cord that plugs into the bottom of the battery. Left like this, the battery will charge. But you can also plug the battery’s dock connector into your iPhone while charging — in this case, the iPhone’s internal battery will charge first, and then the Richard Solo battery will charge. Thus, when traveling, you only need to bring the Solo AC adapter.

In practice, the Richard Solo Backup Battery seems to hold enough juice to add about 50-60 percent of a charge to an iPhone 3G. I.e. after running down the iPhone’s internal battery to the point where I got the “10 percent” warning from the OS, plugging in the Richard Solo Backup Battery and letting it charge the iPhone will restore it to somewhere around 70 percent capacity. It seems to take about an hour for a complete discharge.

You can also use it to slurp occasionally — plug it in for 15 minutes here and there throughout the day. And you can use the iPhone while the battery pack is plugged in — from the iPhone’s perspective, it’s just another power source connected to the dock port.

Is it an amazing amount of external battery power? No. But it certainly feels like $50 worth, and the power capacity seems commensurate with the physical size. And in my experience, it provides just enough extra power to make it through a heavy day of iPhone use.

My biggest complaint is that it ships with a junky plastic cap to cover the dock connector.

It didn’t snap on very tightly even when brand new, and within a week or two, it started falling off while in my pocket. Earlier this month while on vacation, I lost it. You don’t need the cap, but it somehow seems wrong to have the naked dock connector bouncing around in my pocket. A better design would be for the dock connector to be retractable, sort of like the blade on a box cutter.

Minor niggles include the supplied USB cable being too short, it being a little hard to tell at a glance which side of the battery is up, and a somewhat confusing array of LED lights that indicate when the battery is charging and when it is giving a charge.

The bottom line, though, is that it’s the next best thing to having an iPhone with a longer-lasting internal battery.

Espresso, MacRabbit’s upcoming web development tool, is not entirely done yet. Its engine, on the other hand, is roaring to be extended and pushed to its limits.

Do you develop sites, code applications or write articles? Sign up as a tester, download the Espresso Engine Preview today and get a taste of what’s to come.

Check the temperature in hell. One of the longest-standing truisms in buying a Mac is that you don’t get competitive prices when buying memory upgrades direct from Apple. Historically, Apple has charged exorbitant prices for RAM upgrades in build-your-own configurations — upwards of two or three times the market price, sometimes even higher.

So the standard advice has always been to buy your Mac with the standard memory configuration, and then purchase memory from a dealer such as Crucial or OWC or Newegg and then install it yourself. My assumption has always been that Apple could get away with such pricing because many Mac users just aren’t comfortable installing RAM chips by hand (even with machines where the memory slots are easily accessible) and are therefore willing to pay a premium price to have it installed by Apple.

But it ends up that Apple’s RAM pricing for the new MacBooks and MacBook Pros is extremely competitive. There’s only one upgrade configuration — going from the standard 2 GB to 4 — and for both the MacBook and MacBook Pro, Apple is charging $150. This same upgrade costs $142 from Crucial, $135 from OWC, and $160 (!) from Newegg. Factor in shipping and it’s pretty much even.1

This may not remain a good deal forever. My hunch is that Apple will continue charging $150 for this upgrade at least until the next MacBook revisions arrive; the prices at third-party memory stores fluctuate as commodity pricing changes. But for now, your best bet seems to be to buy MacBook memory from Apple when you buy your machine.

Apple’s prices for memory upgrades for other machines remains high; RAM from Crucial, OWC, and Newegg charge half the price or even better for machines like the Mac Mini, iMac, and Mac Pro. The most egregious example is the Mac Pro. Upgrading to the maximum memory configuration of 32 GB from Apple will cost you $9,100; the same upgrade from OWC costs just $1,680 — a difference so large that you could buy a second Mac Pro also maxed out to 32 GB with the savings.

1. One can argue that Apple is still charging a premium, since they’re charging $150 for the difference between 2 GB and 4 GB, whereas the third-party dealers are selling you 4 GB of RAM straight up. The effective difference is that when you upgrade the memory yourself, you get to keep two useless 1 GB RAM chips from Apple, but the out-of-pocket cost is about the same. ↩

For a long time — the entire decade of the ’90s and the first few years of this decade — the story of Apple was the story of a company searching for a way to be something other than “the Mac company”. From a financial perspective of revenue and profit, the Mac was Apple, and Apple was the Mac. This was problematic on two fronts. First, it was an “all of their eggs in one basket” scenario. If the Mac had sunk, the company would have gone under. Second, the potential for growth was severely limited by the fantastic success of Windows.

The iPod was Apple’s first breakthrough success after the Macintosh. During some quarters in recent years, iPod revenue has run even with or (in holiday quarters) exceeded Mac revenue. The iPod solved both of the problems Apple faced as “the Mac company”: its eggs were now divided between two baskets, and they’d entered a field with room for significant growth.

Last year, immediately after its debut, Steve Jobs began describing the iPhone as the third leg of the company. The numbers Apple released yesterday for its fourth quarter of financial year 2008 (July through September) back this up.

The main thing you must keep in mind regarding Apple’s reported numbers for the iPhone is that they’re using subscription-based accounting for it. When you buy a Mac or an iPod today, Apple reports the entire sale as revenue for this quarter. When you buy an iPhone today, however, Apple reports the revenue split evenly over eight quarters.

Apple’s interpretation of U.S. accounting regulations is that this is the only way they can provide free feature upgrades over the course of two years. That’s why iPhone OS 2.0 was a free update for existing iPhone owners, but a paid update for iPod Touch owners.

In the long run, Apple doesn’t make any more or less money from this. It’s just a method of accounting for the money they have made. (Indirectly, Apple clearly hopes that it helps sell additional iPhones, on the grounds that people enjoy getting “free” OS upgrades.) But in the short run, Apple’s iPhone revenue and profit are underrepresented in the company’s quarterly results — only one-eighth of the revenue from iPhones sold during the just-completed quarter appear in the quarter’s results. It also makes the iPhone numbers hard to compare against those of the Mac and iPod.

So, Apple is now providing two sets of quarterly numbers. First, GAAP results with subscription-based accounting for iPhones and Apple TV. (GAAP stands for Generally Accepted Accounting Principles.) Second, a new set of numbers — non-GAAP results — which, more or less, show what Apple’s quarterly numbers would look like if they weren’t using subscription-based accounting for the iPhone and Apple TV.

Here’s what Apple CFO Peter Oppenheimer said during his opening remarks of yesterday’s analyst conference call:

As we reported in our press release, iPhone unit sales grew significantly in the September quarter, resulting in a material increase in the amount of iPhone revenue and product costs that had been deferred for recognition in future periods. Specifically, deferred revenue from iPhone and Apple TV sales grew to $5.8 billion at the end of the September quarter, an increase of nearly $3.8 billion from the end of the June quarter. If iPhone revenue was not deferred, iPhone would have represented 39% of Apple’s revenue in the September quarter.

This means, I think, that Apple generated more revenue last quarter from iPhone sales than from either Mac or iPod sales. The iPhone, just 15 months old, is perhaps already the strongest of the company’s three legs. And it’s not like iPod or Mac sales are down — compared to the year-ago quarter, Mac sales are up 21 percent in terms of units and 17 percent in terms of revenue, and iPods are up 8 percent in units and 3 percent in revenue.

And in terms of the momentum of the iPhone OS as a platform, keep in mind that the iPod Touch is put on the books as an iPod, not an iPhone. (And Apple does not break those “iPod” numbers out into specific models; no one other than Apple’s top executives know exactly how many iPod Touches have been sold.)

Steve Jobs rarely appears on Apple’s quarterly analyst calls. I’m pretty sure you can count on one hand Jobs’s appearances on these calls over the last 10 years. Typically, Jobs has appeared when Apple has bad news to announce. (His appearance yesterday seems to have been about addressing Apple’s plans for weathering the current worldwide economic downturn.) Here’s what Jobs had to say in his prepared remarks regarding Apple’s revenue and profit from the iPhone:

As you can see, the non-GAAP financial results are truly stunning. By eliminating subscription accounting, adjusted sales for the quarter were $11.68 billion, 48% higher than the reported revenue of $7.9 billion, while adjusted income was $2.44 billion, 115% higher than the reported net income of $1.14 billion. Adjusted net income that is more than double our reported income — if this isn’t stunning, I don’t know what is, all due to the incredible success of the iPhone 3G.

I would like to now highlight two remarkable milestones resulting from iPhone’s outstanding performance last quarter. The first is that Apple beat RIM. In their most recent quarter, Research in Motion, or RIM, reported selling 6.1 million BlackBerry devices. Compared to our most recent quarter sales of 6.9 million iPhones, Apple outsold RIM last quarter and this is a milestone for us. RIM is a good company that makes good products and so it is surprising that after only 15 months in the market, we could outsell them in any quarter.

But even more remarkable is this — measured by revenues, Apple has become the world’s third-largest mobile phone supplier. I know this sounds crazy, but it’s true — as measured in revenues, not units, Apple has become the third largest mobile phone supplier. Let’s look at the ranking — Nokia is clearly number one at 12.7 billion; Samsung number two at 5.9 billion; Apple is number three at 4.6 billion; Sony Ericsson, number four at 4.2; LG, number five at 3.4 billion; Motorola, number six at 3.2; and RIM number seven at 2.1. Pretty amazing.

So, last quarter: (1) the iPhone was a bigger revenue and profit generator than either the iPod or Mac; (2) Apple sold more iPhones than RIM sold BlackBerrys; and (3) Apple trailed only Nokia and Samsung in worldwide mobile phone handset revenue (and they’re not far behind Samsung).

Jobs followed with this caveat:

Now, both of these things, beating RIM in units and becoming the third largest mobile supplier in revenues are amazing feats but part of this was the result of expanding into over 50 countries and there’s no guarantee that sustained sales will equal initial sales. And who knows what the future results will be, given the worldwide economic slowdown but we actually outsold RIM last quarter and ranked as the third largest mobile phone supplier in revenues. Not bad for being in the market for only 15 months.

He’s right that no one knows what the results will be for the current quarter (which started three weeks ago, and runs through the end of December) — but we can make an educated guess. Because it encompasses the entire holiday season, Apple’s October-December quarter has always been the strongest for iPod sales.

A year ago, iPod sales went from 10.2 to 22.1 million from Q4 (Jul.–Sep.) to Q1 (Oct.–Dec.). Two years ago, they went from 8.7 to 21.0 million. Three years ago, 6.5 to 14.0 million. In terms of a multiplier, that works out to 2.17, 2.41, and 2.15, respectively. I.e., Apple consistently sells a little more than twice as many iPods in the holiday quarter than in the preceding quarter.

We only have one year of data for the iPhone. Last year, Apple sold 1.1 million iPhones in Q4 2007. It went on to sell 2.3 million iPhones in Q1 2008 — a multiplier of 2.09, very much in line with previous years of holiday-quarter iPod sales.

So, it seems quite possible that Apple could sell twice as many iPhones during the current quarter as it did in the just-reported quarter. If they did, that would be 13.8 million iPhones. Even if they fall short of that mark, they seem poised to sell about 20 million iPhones in calendar year 2008 — more than double their oft-stated goal of 10 million. Many analysts doubted that 10 million iPhone goal for the year; Apple might in fact sell 10 million iPhones in a single quarter.

Even if sales are flat in the current quarter, it seems almost certain they’ll sell more than 10 million units in the first six months after the iPhone 3G went on sale.

As for where this growth positions the iPhone industry-wide, recall Microsoft’s projections for Windows Mobile licenses this year:

The warning signs were there. After boldly proclaiming that it would sell “more than” 20 million licenses to its Windows Mobile operating system by the end of its fiscal year on June 30, Microsoft later scaled that prediction back to “nearly” 20 million units. This week, however, the software giant conceded it did not hit its target: The company sold just 18 million units in the fiscal year.

So not only is Windows Mobile growth significantly slower than what Microsoft had publicly anticipated, but the iPhone seems set to surpass unit sales of all Windows Mobile phones combined next year. In fact, given that Apple acknowledged during yesterday’s conference call that, including October sales to date, they’ve already surpassed 10 million iPhones sold for calendar year 2008, the iPhone may well already be outselling all Windows Mobile phones combined.

The entire iPhone platform is only 15 months old. The cheapest model still costs $199. The room for growth in this market is unlike anything Apple has ever seen. So the question is: Despite continuing strong iPod sales and record-breaking Mac sales, how long until the iPhone is undeniably the primary product and platform made by Apple?

My answer: Not long.

And I think Apple’s executive team sees it the same way.

FileMagnet makes it easy to store and view documents on your iPhone.

Simply drag files to FileMagnet on your Mac or PC. Open FileMagnet on your phone, and your files are transferred automatically via Wi-Fi. Thanks to Bonjour networking, you’ll never have to enter a password or IP address.

FileMagnet views most any format, including Office, iWork, images, rich text, Safari WebArchives, and iPhone-compatible audio and video.

With Tilt Scrolling, read documents without lifting a finger — just tilt your phone to scroll.

Check out the demo video for a closer look. Available for $5 in the App Store.

With regard to “Update 2” here.

Let’s make this very clear: certain parts of this tip were wrong. The new product pricelist started at $899, and it wasn’t a laptop, but a monitor.

The entire report was completely wrong.

The $99 is semantics, because the tipster saw the figure 8, and obviously didn’t get the $99 part.

The difference between $899 and $900 is semantics. The difference between $899 and $800 is a hundred dollars. If our source saw “899” and didn’t “get” the “99” part, it suggests our source is either visually or mentally handicapped. As a full-time technology blogger, I am fully aware that every computer Apple sells or has sold in recent history has a price that ends with “99”, and that an “$800 laptop” from Apple, semantic differences aside, would sell for a list price of $799.

There was however a pricelist, and the first item was a product close to the mark.

That said, I did not report that Apple was set to introduce an “$800 product”. Rather, I reported specifically that Apple was set to introduce an “$800 laptop”. There was no “could be a laptop” or “we think it’s a laptop”.

Second, there was a sub-$1000 laptop, but at $999 not $800. No one saw the monitor coming, and others, having seen the same list our tipster did, called it a laptop. That doesn’t excuse the inaccuracy, but it also highlights that we weren’t alone in not knowing about the monitor, and considering the first price on that list to be a laptop.

I reported a guess as a fact.

Sometimes in this game you print unsubstantiated tips.

Sometimes in this game you print unsubstantiated tips, but you describe them like this: “The information comes from a source we would categorize as reliable, would have access to such information, and who has been accurate in the past,” because if you described them as, say, “unsubstantiated” or “sketchily sourced”, far fewer people would believe it or link to the report.

Sometimes they don’t work out. I’ve actually not lost faith in the tipper either, because I confirmed the list later, it’s just the presumption that the first item on it was a laptop that ended up wrong.

I will continue to publish bogus reports from the same source.

If some people have issues with that, there’s little I can do to change your mind, but anyone who has ever worked in journalism or high level blogging knows the risks and issues around tips, and I’m not about to change the way I deal with them just because one wasn’t totally correct in what it included.

If I just keep digging, surely I’ll eventually get out of this hole.

If we hadn’t published this, someone else would have.

If I hadn’t completely trashed my own credibility, someone else would have trashed theirs, and they would have gotten all the attention and page views that instead went to me.

One thing Apple knows is what it does. Apple designs and produces very nice things. All this hubbub over low-cost laptops is outside the realm of what makes Apple Apple.

There has long been, especially in the business press, a strong bias towards encouraging Apple to act like a “normal” computer company. Remember when it was common for analysts to call for Apple to break itself apart into separate software and hardware companies? Or for Apple to obtain a license for Windows and make “well-designed” Windows PCs. Or for Apple to sell licenses for Mac OS X to Dell?

A lot of the current action in laptops, industry-wide, is at the low end of the market. Some of these machines look pretty interesting. None of them look like something Apple would make.

But yet there was (and is) this consensus that given current industry trends, combined with the rather shaky (to say the least) state of the global economy, well of course, what Apple needed to do was cheapen its MacBook lineup. Exhibit A, exhibit B, exhibit C.

What Apple announced Tuesday was exactly the opposite. Instead of making them cheaper, they made them better. Dramatic performance improvements in graphics, and a significant leap forward in industrial design a