iPad development and not living in the USA

Apple announced the release date for the iPad today. It will be available for sale on April 3d. That is, if you live in the United States. If, like me, you live in Canada, it will be available by the end of April.

Considering the secrecy surrounding the iPad and the geographical distribution of Apple retail outlets, I can understand why the initial release is only done on home soil. It also makes sense in terms of supply and demand. Apple wants to have enough iPads for everybody.

As a consumer, I don’t have a problem with apple releasing in the USA only. As a registered developer, it frustrates me profoundly.

Like many others developers, I am working on an iPad app. Like many others, I am stuck testing it on the tools available to me at the moment. Some privileged top tier developers already have access to the physical device and will be able to have their apps available on April 3rd. I’m fine with that. I understand that Apple wants to hand-pick a few top notch developers for their 0-day offerings. Really, I’m fine with that.

What I’m not fine with is that every developer outside of the United States will not have access to the iPad until approximately three weeks after american developers. That means that our submissions will be artificially delayed by three weeks as well. It basically translates into an unfair advantage for american developers and lost opportunities for the rest of us.

There are already two classes of developers: those who get to sign the secret NDAs and get invited to Cupertino, and those who don’t — please don’t create a third.

To fix this, Apple needs to make iPads available to all their developers come April third. This could be done via the online stores, or even from the retail locations which are located outside the US. If Apple is able to invent a magical and revolutionary product like the iPad, surely they can find a way to put one in our hands as well.

Please retweet.

  • Twitter
  • Facebook
  • del.icio.us
  • StumbleUpon
  • Digg
  • LinkedIn
  • RSS

Why the App Store review process won’t get “fixed”

The classic argument for loosening App Store review is that Apple is harming their product more than they’re helping. By hand-cuffing developers they’re preventing bug fixes from going live, they’re making developers unhappy, etc — you know the story. And then, the argument continues, that hurts developers and customers both indirectly and directly.

Here’s the problem: the numbers disagree. There is no metric or indicator I’ve seen that demonstrates that the App Store review process is hurting Apple in any way. So from a business perspective why should Apple make any dramatic changes to its review process? All that does is add risk they can’t quantify. There’s a risk they know about, and it’s not yet harming the business. They’d be crazy to act on that risk in the name of adding an unknown (and potentially much larger) risk.

- Neil Mix

  • Twitter
  • Facebook
  • del.icio.us
  • StumbleUpon
  • Digg
  • LinkedIn
  • RSS

Bike Gears for iPhone website revamped

I revamped my iPhone Bicycle Gear Calculator’s website. Check it out.

http://www.jpmartineau.com/iphone/bicycle-gear-calculator

  • Twitter
  • Facebook
  • del.icio.us
  • StumbleUpon
  • Digg
  • LinkedIn
  • RSS

The Evolution of Convert’s User Interface

Anyone who’s ever designed a user interface knows that it’s an iterative process. The first design you lay out is almost certainly very different from the one you end up using. Many factors explain this:

- The user interface is directly affected by feature-set changes. Add a feature, you need to change the UI. Remove a feature, you need to change the UI as well.
- Because it’s visible and tangible, (You literally can touch it!), the UI is a likely victim of enthusiastic micromanagers.
There are also some good reasons to change the UI, like streamlining the design to improve usability.
So by the time a project is done, its UI has been through many iterations. Often, there is no record of these changes. The folks at Tap Tap Tap put this video together, from a bunch of screenshots. It shows the evolution of their Convert app’s UI.
From now on, I will be saving a screenshot of every design iteration in all of my projects.
  • The user interface is directly affected by feature-set changes. Add a feature, you need to change the UI. Remove a feature, you need to change the UI as well.
  • Because it’s visible and tangible, (you literally can touch it!), the UI is a likely victim of overenthusiastic micromanagers.

There are also some good reasons to change the UI, such as streamlining its design to improve usability.

So by the time a project is done, its UI has been through many iterations. Often, there is no record of these changes. What if you could go back and see every design decision you’ve taken, in sequence. Wouldn’t that be a useful record for a project’s post-mortem?

The folks at Tap Tap Tap put this video together, from a bunch of screenshots. It shows the evolution of their Convert app’s UI. It seems that the changes in their UI were done for the good reasons too: the end-result is strikingly elegant.

From now on, I’ll be saving a screenshot of every design iteration in all of my projects.

  • Twitter
  • Facebook
  • del.icio.us
  • StumbleUpon
  • Digg
  • LinkedIn
  • RSS