John Gruber analyzed the ramifications of an alleged 960×640 screen on the upcoming iPhone model:

Compare type on your iPhone or iPod Touch against the type in a glossy magazine. […] The next-gen iPhone is shooting for that caliber of resolution — not merely to exceed the resolution of competing devices, but to rival the optical quality of print.

I’m not sure what the software story will be for iPhone apps to take advantage of this increased resolution. If existing unmodified apps run pixel-doubled, they should look identical with the naked eye to how they look today on existing iPhone displays.

Marco Arment responds with skepticism about the value of such a move:

But I’m still puzzled about the 960 × 640 move, if it’s real. The iPhone is already the highest-DPI display that Apple sells, and to double its resolution is very expensive: the panel costs more, it’s likely to use more power, it places higher demand on the CPU for rendering, it needs much more memory for frame buffers and textures, and it incurs big costs on developers and Apple’s developer-tools and developer-support teams.

Let’s assume that Apple has a list of goals for the next phone, and a higher-resolution screen will help them to achieve them. Let’s not get carried away and start assuming that this means the high-resolution screen will be made available for general-purpose developer use.

Wouldn’t it be very Apple-like to use the higher-resolution screen as a mere implementation detail? Just because Apple’s putting a new screen in the phone, doesn’t mean they’ll let you have access to it. If they maintain a conceptual 480×320 screen for iPhones, there is very little of the increase in memory usage that Arment alludes to, there is zero change to complexity from a developer tools perspective, and there is no cost to developers in determining how or if their application should take advantage of a higher-resolution screen.

By applying the default pixel doubling as the baseline scenario for every app, they maintain 100% consistency in user experience across the current lineup of phones and the upcoming models. But on newer phones with high-resolution screens, Apple can take advantage of the screen at their discretion to pragmatically improve the user experience.

For example, if Apple applies this strategy, they can simply do the default bitmap doubling for all pixel-based drawing, but reap the benefits of the higher-resolution screen for all vector-based drawing. Vectors that are used e.g. to describe line art or the fine curves of a typeface, do not take up any more RAM when targeting a high-resolution screen than they do for a low-resolution screen, but when it comes time to draw them, they gobble up as much fidelity as you can throw at them.

A typical application running on a 960×640 screen will use the same amount of RAM as it does on a 480×320 screen, will have identical screen layout and user interaction behavior, but the fonts and vector art will be incredibly, dare I say magically, sharp and beautiful.

Update – A Catch!

John Siracusa explained to me through – a – series – of – tweets, how the story doesn’t play out so perfectly in reality.

Because the fidelity of any vector art is being compromised when it’s mapped to pixels, there will be subtle differences in the precise alignment of how these pixels end up falling on the higher-resolution screen vs. the lower-resolution one. In other words, the layout may change somewhat dramatically when, e.g., rendering a long line of text, or a complex, small vector illustration. If the application is designed with assumptions about the portion of the screen that content will take up, then the higher-resolution screen cannot dramatically alter that or it defies the developer’s design.

He’s got me worried that it’s a deal-breaker, but I leave it to Apple to demonstrate for us whether it is or not. I wonder if at some point the increased resolution becomes so high that it affords some compromise in the layout so that metrics continue to add up as expected without causing noticeable awkwardness in the rendering.

I complained on Twitter about PayPal’s unfortunate transaction search utility, which doesn’t recognize the transaction ID itself as a search term.

Georg C. Brückmann chimed in with a semi-solution, which is a URL template you can use to jump directly to a PayPal transaction by ID. Take the root PayPal URL for your country, and add “vst/id=” followed by the PayPal transaction ID. In the United States, this leads to a URL like: https://www.paypal.com/vst/id=1234.

It’s sad to say that remembering a static PayPal URL and pasting in the transaction ID in the magic location is indeed easier than navigating PayPal’s slow and awkward transaction history UI. But it could be even easier with a little automation.

Jump To PayPal Transaction ID is a simple AppleScript that prompts you for a transaction ID, constructs the desired URL, and opens it in your default browser. If you don’t live in the United States, open the script in AppleScript Editor and alter the template URL contained within it.

I put this in my Safari-specific scripts folder:

[Home] | Library | Scripts | Applications | Safari

So it’s available from FastScripts whenever I’m in Safari. Problem solved.

Brent Simmons reveals one of the biggest secrets for making friends and influencing people. Yes, it’s the oldest trick in the book: be nice.

Be gracious. Be thoughtful of other peoples’ interests. Don’t be a whiner. Be generous. Be inclusive. Pay it forward… you get the picture.

Have you ever noticed this phenomenon of the internet? As the ultimate reference archive, it reveals the most arcane and lesser-known facts of science, art, and trivia. It teaches us about the world. But as the ultimate social connector, it teaches us about people, how we do or don’t, and how we should or shouldn’t get along with each other.

I experienced this the other day when I was tweeting enthusiastically about Tweetie for the Mac and how I might be interested in taking the product over if it doesn’t fit into Twitter’s plans for the app. In the excitement, I not only violated one of the social rules of politeness by filling my followers’ Twitter screens to the brim, but I made the mistake of taking a stab at a company called Brizzly.

See, my friends Buzz and Neven built a wonderful iPhone Twitter app called Birdfeed. A few months ago, Brizzly acquired Birdfeed from my friends, and revamped the user interface a bit to match their style. I’m not a fan of these revisions, and I have stuck with the original Birdfeed app on my phone. But I used this distaste for the UI changes to fuel a less constructive tweet that I would characterize as a “low blow” against Brizzly. I have since deleted the original tweet, but it prompted a response from Brizzly’s CEO:

@phopkins He may be hella cool but does he realize that smacking Brizzly isn’t going to get him anywhere?

I immediately had one of those wake-up-call feelings where you realize that what was just mindless banter at “somebody else’s” expense was actually at the expense of somebody very particular. Yes, I reminded myself, there are actually people on the internet:

I should know this by now: there are people behind products. Ashamed of my tasteless treatment of Brizzly, and by extension, @shellen.

Some people who don’t know me very well assume that because my Twitter name, @danielpunkass, is a bit crass, that I must be a provocative and thoughtless person. They are surprised to meet me in person and find out that I’m actually pretty nice.

What my Twitter name represents to me is my willingness to be the cheeky one. To defy the standards and be a bit of a jerk when it’s called for, but only when it’s called for. Sometimes, the most unexpected, uncalled for, provocative, defiant move you can make is to be nicer than people expected you to be.

One of my customers reported a really subtle bug having to do with a keyboard shortcut for a command. I’m going to change some facts to protect the innocent, but imagine I got a report:

“Every time I press cmd-N to create a new document and start typing, instead of accepting the text, it just beeps at me.”

This seems impossible to me. Creating a new document and typing into it is fundamental to my product. Surely if it was broken I would know from my own daily testing of the application. I try diligently to reproduce it, but of course, I can’t. Create a new document. Start typing. Everything works, everybody’s happy. Except the person who reported the bug.

At some point in my tinkering I stumble upon the bug. Beep. I can’t type. There it is! What a drag. This application sucks!

Now that I’ve seen and heard the bug with my own eyes, I’m more committed than ever to fixing it. But how on earth did I do it? I try several more times and am unable to reproduce the problem.

I have only spotted the issue once in my dozens of trials, yet the customer claims it affects him every single time. What explains this? Maybe it simply doesn’t happen as often on my Mac as it does on his. My thoughts turn to the brute force of AppleScript. If this happens only once in a blue moon on my Mac, surely I can reproduce it by running a script that iterates the test conditions hundreds or thousands of times. I open AppleScript Editor and enter the following:

tell application "System Events"
	repeat 100 times
		keystroke "n" using command down
		keystroke "Testing typing"
	end repeat
end tell

Nothing! Even after running it 1000 times, nothing. How can this be? How could something so common for the customer, something that I saw myself once, be so difficult to reproduce on my Mac?

After playing around a bit more, I started to reproduce it more readily. What was happening? I couldn’t figure it out, but something “felt” a little different when I reproduced it. I thought carefully about the parameters of the bug, as exemplified (I thought) by my script:

1. The command key is pressed.
2. The N key is pressed.
3. The N key is released.
4. The command key is released.
5. Typing into the new document is attempted.

I looked again at the script. Perhaps this “keystroke” command is not literal enough. For all I know it’s circumventing the normal key events that get generated when you type on the keyboard. On a lark, I modified the script to be more explicit:

tell application "System Events"
	repeat 100 times
		key down {command}
		key down  "n"
		key up "n"
		key up {command}
		key down "x"
		key up "x"
	end repeat
end tell

Here we have a more literal match with my analysis of what happens. Hold down the command key, press the N key, release, then type something. In this case I just type an x character because I figure any typing is enough to trigger the bug.

I ran this 100 times as well and no luck. The bug is simply not reproducible through scripting. I guess I’ll have to figure out what conditions are making it more likely for the customer to run into the bug. Maybe he has some 3rd party software that is interfering. Or … wait a minute.

tell application "System Events"
	repeat 100 times
		key down {command}
		key down  "n"
		key up {command}
		key up "n"
		key down "x"
		key up "x"
	end repeat
end tell

I ran the modified script and the bug immediately exhibited itself. So what changed? Look carefully and you’ll see that my previous script assumed that when a keyboard shortcut is pressed, there is a sort of nested symmetry to the order of pressing and releasing the keys. When I press keyboard shortcuts, I hold the modifier keys down throughout the stroke, and release only after the letter key has been released. But this customer has muscle memory that inclines him to instead release the keys in the order they were pressed. When he releases the N key, the command key has “long” since been released.

This subtle difference turns out to trigger a bug in my event monitoring code that, to make a long story short, robs first responder status from the default view in the document. So when he creates a new document, there is no first responder, and his typing just causes a bunch of beeps. When I create a new document, there’s always a first responder, so I don’t see the bug.

As difficult as this bug was to track down, it would have been near impossible without the theory testing, disproving, and ultimately proving tool of using AppleScript and System Events to zero on in the behavior. Sometimes when the steps a customer provides to reproduce a bug seem exactly the same as what you’re doing, you’re just not trying hard enough to find the difference.