You probably don't want half your comments on YouTube and the half on your post. Thankfully, there's a plugin for that!

Genki Wordpress Plugin

The Genki YouTube Comments Wordpress plugin imports YouTube comments into your Wordpress posts. It's great for keeping the conversation on your blog. You can schedule comments to be imported at regular intervals or import them manually through the Admin interface.

For any post that you want to import YouTube comments into, you just add a Custom Field with youtubevidid as the key and the actual YouTube Video ID of your video as the value.

Making it pretty: adding a YouTube Gravatar

By default, the imported comments use the default Gravatar. If you want to use a custom gravatar, instead, hack the code to change the email address used for imported posts to youtube@aralbalkan.com:

$comment_author_email = 'youtube@aralbalkan.com';

I registered this Gravatar account and mocked up a quick YouTube icon for it. Feel free to use it.

By the way, I also removed the default (and butt-ugly) " [..YouTube..] " prefix that the plugin adds to comments:

$comment_content = addslashes($ytvideo->CONTENT[0]->_text);

You can see the plugin at work on my Star Trek: The Movie on USB Stick post.

Enjoy!

Today I saw something I'd been hoping to see for some time now: a movie released on USB stick. Specifically, the latest Star Trek movie in a limited-edition USB stick shaped like a Communicator.

Unboxing The Precious

You can watch my unboxing of it, above, to see that they really did put some care into the packaging. Unfortunately, the same care didn't seem to go into the software side of it (e.g., when you plug it into your Mac, it shows up as "NO NAME" – quite a large oversight.)

Watching the movie: DivX VOD

To watch the movie, you have to download the DivX player, get a DivX account, and activate the movie online using the activation code in the package and your email address.

The first time I did this, I got an error telling me that I wasn't licensed to view the movie. What I missed (and it's easy to miss) was this tiny little link in Step 3 of the activation process instructing me to download a .tix file with my license in it.

Needless to say, this is a huge usability FAIL that the Star Trek folks need to address. Center that baby, make it 30pt or something and heck, add an icon for good measure so no one can possibly miss it.

Once you download the license file, double click it to launch it and you should be up and running with the movie in the DivX player.

You can apparently play the film in up to 7 devices, including your PS3.

Watching the movie on a PS3

To get it up and running on the PS3, you need to register for an account with DivX and download the DivX player, as mentioned above. Then, on your PS3, go to Settings → System Settings → DivX VOD Registration Code and note down the code displayed on that screen.

Finally, in the DivX player on your computer, go to VOD → Register a DivX Certified Device… → and enter the DivX VOD Registration Code you noted from the PS3.

The DivX player should tell you that you need to download a registration video and play it back on your PS3 to complete the registration process.

This is where the Star Trek USB key comes in handy. Download the registration video and copy it on to your USB key. Then plug that into the PS3 and navigate to Video → USB Device (Flash Disk) from the main menu.

Do not enter the USB Device (Flash Disk) option using the "X" button the controller as you will see a message alerting you that "there are no titles" (usability FAIL). Instead, use the green triangle button to bring up the Options screen and then select the highlighted Display All option.

Now, you should see the PS3 DivX activation movie and the Star Trek movie. Play the DivX activation movie and you should see a screen telling you that your PS3 has now been activated. You should now be set up to watch DivX VOD movies on your PS3. Of course, you can test this right away by watching your new Star Trek movie in glorious HD.

USB to the Future

I have to say, this feels far more like the future than Blu-Ray. Me likes. And yet the usability can be improved and the process simplified. If anyone from Sony/DivX/etc. is reading this, feel free to get in touch with me as I'd love to work with you on improving the flow.

It is telling in itself that Paul doesn't feel the need to make the case that Apple's App Store approval process is broken. I feel we can all safely agree that it is. The real problem, according to Paul, however, is a greater one:

I don't think Apple realizes how badly the App Store approval process is broken. Or rather, I don't think they realize how much it matters that it's broken.

The way Apple runs the App Store has harmed their reputation with programmers more than anything else they've ever done. Their reputation with programmers used to be great. It used to be the most common complaint you heard about Apple was that their fans admired them too uncritically. The App Store has changed that. Now a lot of programmers have started to see Apple as evil.

Perception.

Good will.

We're not talking about how many applications there are on the App Store today or how many developers there are currently on the platform. We're talking about how happy those developers are. About what they think of Apple.

We're not talking about things that will necessarily affect Apple today but may have a profound affect on the iPhone platform one month/one year/maybe years from now.

I already wrote about how Apple has already begun to lose iPhone Value Adders and how I've personally been hurt by Apple's App Store approval process. Not surprisingly, I find myself left with a very sour taste in my mouth (and writing posts extolling the virtues of open web technologies and praising the innovative open approach of companies like Palm and Google.)

All this and I haven't even submitted my app to Apple yet. (I hope to by this Monday, the latest!)

I am scared, however, of how I will support my users when updates takes weeks to get approved.

Wait a second, I'm scared.

I'm scared of how Apple's lengthy approval process will impact my reputation if I can't deploy a bug fix in a timely manner. I am a developer and I am scared of the platform I am developing for.

Something is very wrong here.

Paul asks:

How did Apple get into this mess? Their fundamental problem is that they don't understand software.

Apple understands that User Experience is about control. That's why they control both the hardware and the software that goes into a Mac. They understand that UX requires a dictatorial iron fist to avoid feature creep and maintain consistency. They understand that the magic word is "no", not yes. And this works wonderfully for them on the desktop because they don't attempt to extend this control to third parties.

There is an honor system of sorts for Mac software developers. Apple leads by example, not direct control. Developers create beautiful, engaging apps for the Mac because they want to and because they want to match the elegance of the operating system and the default applications. It is, however, possible to create ugly apps that don't work for the Mac and no one can stop you from doing that if that's what rocks your boat.

If this works on the desktop, why not implement it on the iPhone? Why not let developers put whatever they like up on the App Store (and update it as frequently as they like), implement a cooling off/refund period to protect users, and let users and the market decide which apps rise to the top and which get buried?

To understand Apple's thinking, here are more words of wisdom from Paul:

They treat iPhone apps the way they treat the music they sell through iTunes. Apple is the channel; they own the user; if you want to reach users, you do it on their terms. The record labels agreed, reluctantly. But this model doesn't work for software. It doesn't work for an intermediary to own the user… If software publishing didn't work in 1980, it works even less now that software development has evolved from a small number of big releases to a constant stream of small ones.

Software definitely isn't music. A piece of music, once published, is finished. File corruption aside, you never need to update a piece of music (I'd personally love a system where artists could push new versions and updates to their songs as they evolved them but that's definitely the topic of a separate blog post). Software, on the other hand, is ever-evolving. The only time a piece of software is "finished" is when it is no longer being developed or supported. In other words, the only time a piece of software is "finished" is when it is dead.

But Apple doesn't understand that either. Their model of product development derives from hardware. They work on something till they think it's finished, then they release it. You have to do that with hardware, but because software is so easy to change, its design can benefit from evolution. The standard way to develop applications now is to launch fast and iterate. Which means it's a disaster to have long, random delays each time you release a new version.

More than anything else, it is the potential nightmare of not being able to release timely updates that scares me about the iPhone. More than anything else, this is the reason I am actively looking into alternative platforms like Palm's WebOS and Google's Android. I love the iPhone but I also love my reputation and I would hate for Apple to ruin it.

To understand how important timely updates is to software, consider this:

How would Apple like it if when they discovered a serious bug in OS X, instead of releasing a software update immediately, they had to submit their code to an intermediary who sat on it for a month and then rejected it because it contained an icon they didn't like?

By breaking software development, Apple gets the opposite of what they intended: the version of an app currently available in the App Store tends to be an old and buggy one.

And this is where Apple is failing its users, developers, and, ultimately, its shareholders:

A buggy app on the App Store means lost sales for the developer and for Apple.

Apple has to realize that – like it or not – it is in bed with developers. This is an intimate relationship. If Apple's policies mean that developers and their apps get ill, Apple's eventually going to catch it too.

In the short term, it may feel like it's just a few disgruntled developers whining about their experiences but trust me, we're just the vocal ones. We act as the pressure valves, voicing concerns that a much larger group may share even if they don't necessarily have the platform or desire to voice them as loudly. Apple's worries will truly begin when the silent developers simply stop developing for the iPhone and take their efforts elsewhere.

The problem with that is that you don't hear it happen.

* * *

There is far more to Paul's post that I have addressed here so, do yourself a favor and read the full article.

The virtual whore house those scrawny-necked geeks had set up at his geocoordinates was a blemish on the otherwise spotless reputation of his fine foods business. Bitches and caviar didn't mix. And Mr. Reed was not about to let anyone jeopardize the success he had scraped together from the crumbs of so many sacrifices.

Follow request: The_Cleaner_Brighton.

The_Cleaner_Brighton is now following you on Twitter.

d @The_Cleaner_Brighton: Need to remove porn geolayer at 50.826298,-0.139132. Pls help.

d @RitchesFoods: £5K to TheCleanerBrigton@googlemail.com via PayPal. I will handle it Tues.

d @The_Cleaner_Brighton: Sent.

Tuesday, May 23rd, 2013.

Refresh… porn… refresh… hookers… refresh… nothing.

Mr. Reed smiled for the first time in months. The_Cleaner_Brighton was good. The seedy geolayer would soon be a distant memory; a humorous conversation piece at the club. How refreshing to have one's top worry once again be whether to stock Norwegian or Scottish salmon next month.

His smile faded as his glance fell on the morning paper.

GEOHACKERS FOUND DEAD IN BRIGHTON.

d @The_Cleaner_Brighton What did you do?

d @RitchesFoods I handled it.

@The_Cleaner_Brighton You killed them?

d @RitchesFoods That wasn't a direct message.

d @RitchesFoods Don't worry, I'll handle it.

• The Really Mobile Project » Blog Archive » Shopping at the OVI store…
  A tale of woe about shopping in the OVI store… “Would you like a Hannah Montana screen-saver with that?”

  It would be funny if it weren’t true.

  (via James Governor)

  (tags: ovi, nokia, ux)
• Apple's App Store Rejections | Ted Landau's User Friendly Blog | The Mac Observer
• Apple doesn’t seem to like mixing apps, politics - Tech and gadgets- msnbc.com
• Respected developers begin fleeing from App Store platform - Ars Technica

Beyond that, however, Occipital is a Value Adder, just like Joe Hewitt.

Instead of being content with having one of the top-selling apps on the App Store, as a Value Adder, Occipital decided to devote considerable time, effort, and money into extending the iPhone platform by sharing their technology and giving any developer the ability to add 1D barcode scanning to their apps via a commercial SDK called the RedLaser SDK.

(Occipital takes a well-deserved 10% cut of commercial apps that use the RedLaser SDK.)

The RedLaser SDK

The RedLaser SDK is a beautiful plug-and-play library that makes it trivial to add high-accuracy 1D barcode scanning for any generation iPhone (not just the 3GS with its auto-focus camera). This is huge. It opens up the iPhone platform to a whole slew of new applications hitherto made infeasible by the poor quality cameras on older iPhone models and the complexity of implementing accurate and efficient 1D barcode scanning from the ground up.

So how do you think Apple responded to such a wonderful addition to the iPhone platform? By working closely with Occipital to help them in any way they could? By buying Occipital and adding their technology to the official iPhone SDK?

Nope, you guessed it: by rejecting apps built with the RedLaser SDK.

Why?

Because Occipital used an undocumented API call in a public framework (not a private API call) to bring real-time barcode scanning to the iPhone platform in the RedLaser SDK.

The technical details

The RedLaser SDK which Apple rejected – let's call it the RedLaser Realtime SDK – uses the undocumented UIGetScreenImage call to constantly sample the video stream, trying to detect the presence of a barcode in the image.

In my extensive tests with the RedLaser RealTime SDK while bulding 'avit, I did not encounter any crashes whatsoever and neither did I find any other negative repercussions from the use of this call. As far as I'm concerned, there is no technical reason whatsoever for Apple to have rejected the use of this call apart from the fact that it is an undocumented API call in an otherwise public framework.

Get it straight: This is not Occipital's fault but Apple's shortsightedness

After it came to light that Apple was rejecting the RedLaser Realtime SDK some people mistakenly began to blame Occipital and RedLaser.

The most public of these came from Nick Lansley from Tesco, in his blog post titled Barcode scanning for iPhone – anyone help? wherein he lamented the RedLaser Realtime SDK's use of "'hidden' iPhone API calls" and put out a call for someone to create a barcode scanning component using "published iPhone/Cocoa-Touch API calls and not in any way try and use hacked internal knowledge of iPhone."

Unfortunately, what Nick didn't understand was that any real-time solution that anyone created would have had to use the same undocumented API call and that the only other alternative was what RedLaser ended up implementing in the next version of their SDK – let's call it the RedLaser Burst SDK – which was to use a "tap to scan" flow and the takePicture() API call.

Thankfully, Nick did post a retraction on his blog after this clear explanation by Jeffrey Powers, co-founder of Occipital:

I thought you would like to know that RedLaser, as an algorithm, has nothing to do with unpublished APIs, but that video processing in general is currently impossible without unpublished API use. We have some confidence that Apple will course-correct on this issue with their next OS update.

In the meantime, we do have a version of RedLaser that avoids this problem which became publicly available as of yesterday. It uses what we call "Photo-Burst" instead of the unpublished API, which means it takes a couple of snapshots very rapidly and then processes those momentarily. At the core it still uses RedLaser's state of the art barcode recognition, and it still works on all iPhone models.

Apple to developers: your app's UX be damned?

From the user's perspective, the realtime nature of the barcode scanner in the RedLaser Realtime SDK provides a beautiful user experience:

You simply aim your iPhone's camera at a barcode and move it around slightly until the phone recognizes the barcode. The flow incorporates elements of game dynamics as the user quickly learns the ideal range that a barcode is sampled at via play.

Unfortunately, since Apple decided to reject apps built on the realtime RedLaser SDK, this user experience is now not available to iPhone users.

The alternative

In light of Apple's rejection of apps built on the RedLaser Realtime SDK, Occipital was forced to devote yet more development time, effort, and money, to reworking a perfectly functional SDK to create the RedLaser Burst SDK, which doesn't use the undocumented API call.

This means that the RedLaser Burst SDK doesn't perform realtime analysis of the video image. Instead, the user has to align the barcode and tap the screen (or a button). At this point, the phone takes two or three pictures of the barcode in rapid succession and attempts to detect the barcode within those images. If it cannot detect it, the user has to align the barcode again and tap to scan again.

This, of course, is a step backwards insofar as the user experience is concerned.

In place of a playful process of continuous feedback, you potentially have a series of failures and retries.

Now, thankfully, RedLaser's barcode recognition algorithms are really advanced so in most cases a single scan with the Burst SDK is all it takes to recognize a barcode. However, the accuracy does drop on older handsets and it may take the user a little while to find the best focal distance for capturing barcodes without continuous feedback.

The saddest part of all this is that Apple has made the decision to reject the RedLaser Realtime SDK not based on any sound technical decision but rather on its shortsighted and inconsistent App Store review policies. Furthermore, it has done so in full knowledge that this decision would lead to less-than-optimal user experiences in apps that used the non-realtime alternative.

Can you see how Apple is acting contrary to its own interests here?

Apple is all about user experience.

Here, they are saying that app developers have to sacrifice the user experience of their apps because, well…, because Apple said so, that's why!

And this decision isn't even in Apple's own best interests or, perhaps more importantly, in those of its shareholders.

How Apple's App Store review process is failing its shareholders

If you understand that Apple's bottom line is inextricably linked to sales of apps on the iPhone platform, you begin to understand how its App Store review process actually hurts Apple and its shareholders.

Let's see how Apple's decision to reject apps based on the RedLaser Realtime SDK, hurts itself and its shareholders:

• Apple makes 30% of all app sales
• Apps that use the RedLaser Realtime SDK will have the best possible user experience and will sell the most possible units, making Apple the highest profit.
• Apps that use the RedLaser Burst SDK will have a sub-optimal user experience – even though that may still be a good user experience, it will not, by definition, be the best possible one. This will likely lead to less units of the app being sold and thus Apple will make less profit than it otherwise could have.

Let me state it plainly: by rejecting apps and whole SDKs based on its shortsighted App Store review process policies instead of based on the value they add to the platform and their user experience, Apple is reducing its own profit and thus failing its stockholders.

And I'm not the only one who thinks so.

Apple's shortsighted policy on disallowing real-time analysis of the video image on iPhones is blocking a whole range of potential augmented reality applications and thus further reducing Apple's potential profits.

Another app not created, another sale unrealized.

Just last night, when I was thinking of writing this blog post, I read a tweet from Tim Sears, author of the excellent Robotvision augmented reality iPhone app (iTunes link):

Spent a few hours last night playing around with face tracking on the iPhone. Too bad rapid image capturing isn't supported. Too bad.

Here was a developer complaining that he couldn't build a cool new iPhone app that used face tracking because of Apple's policy disallowing real-time analysis of the video image from the iPhone's camera. I decided to contact him to ask him what his thoughts were on the subject and he responded with this gem of a quote, which I wholeheartedly agree with (emphasis mine):

I believe Apple needs to change their philosophy to the App Review process, making it less about what technology you use and more about good business decisions. They should be rejecting apps that are abusing infrastructure and are creating a poor experience for the user and accepting apps that are driving innovation. It shouldn't be based around logistical red-tape such as what supported libraries you are using and what text you are entering into your marketing description.

What can I say? Tim said everything I was thinking in one succinct paragraph. I can only hope that someone at Apple reads this, prints out that paragraph in 72pt text, and pastes it all around the Apple campus.

Apple stifling augmented reality apps on the iPhone

Tim goes on to talk about how the burgeoning augmented reality industry on the iPhone is suffering due to Apple's shortsightedness on this issue:

UIGetScreenImage is just one more case for this (on top of the many others such as the CameraOverlay, and the Google Voice fiasco). The young and fertile augmented reality industry is suffering because of it, as well, as there are many more doors to be opened once we can leverage the iPhone for marker-based tracking and object recognition. These are core technical requirements critical to the continued innovation of this industry.

As you can probably tell, Apple's stance on this issue is hurting not just iPhone apps that want to perform barcode scanning but also the take off of what is perhaps the hottest and most exciting mobile application category of our day: augmented reality.

Why this matters to me

As you may already know, this is an issue that is close to my heart since my first iPhone app, 'avit, uses the RedLaser SDK.

Because of Apple's rejection of RedLaser's Realtime SDK, I've had to re-architect 'avit to use the RedLaser Burst SDK.

As an independent developer, this delay has cost me unnecessary time and money.

And yet, it hasn't been all bad.

Although Apple's rejection of the SDK meant that the release of 'avit was delayed (I still haven't submitted it to the App Store – I hope to do so this week after we've signed the license agreement for RedLaser with Occipital), it also meant that I was able to use the extra time to improve the user experience of other parts of the application.

Once I've had a chance to record a new screencast for 'avit, I will write up another post comparing and contrasting the user experience between RedLaser's Realtime and Burst SDK versions in more detail.

And just in case I didn't make it painfully clear earlier, Occipital is in no way to blame for any of this. Their only crime was to try and make the best possible barcode reader for the iPhone.

If anything, Occipital have performed brilliantly and with great patience while firmly lodged between a rock and hard place. They've also been very helpful to me personally during all this with Jeffrey constantly and personally keeping me updated on the latest developments and working with me to make the transition to the new SDK as painless as possible.

Also, before anyone jumps to any conclusions, Occipital in no way asked me to write any of this nor have they had prior knowledge of this post. In fact, knowing Jeffrey's humble and non-confrontational approach, he would probably have preferred it had I not written anything at all. That, of course, would not have been possible since I had to explain to you guys why the user experience changed in 'avit since the initial screencast and I couldn't do that without addressing this issue.

Beyond that, I also feel that the issue needs to be addressed as it pertains to more than just my app but concerns the long-term health of the platform itself. Furthermore, we as developers cannot live in fear of offending the gatekeepers of the platforms that we develop for. To paraphrase Thomas Jefferson:

When developers fear their platform, there is tyranny; when the platform fears developers, there is liberty.

All this to say that I hope Apple will come to its senses and start supporting the real-time analysis of the video image on iPhones so that I can go back to enabling realtime barcode scanning in 'avit, Tim can create his awesome new face-tracking app, and so that someone out there reading this can build something revolutionary that none of us has even thought of yet.

Apple, please hear the rising chorus of discontent from developers who are unhappy with your App Store review process, stop playing gatekeeper and limiting the potential of this awesome platform, and address these issues before the cacophonous crescendo is replaced by a deafening silence.

If you're an Apple engineer, access Radar ticket 7400523 for this issue (thanks, Nik.)

John provides a few simple commands that let you do this in his blog post and I've been using this for the beta builds of 'avit but I soon got bored of manually typing these in. So, instead, I wrote up a quick re-usable Bash script, building on John's, that makes packing up an Ad Hoc distribution very easy.

Here's the script:

#!/bin/bash
if [ "$1" == "" ] ; then
echo "Usage: adhoc <NameOfApp>"
else
echo "Deploying $1…"
mkdir Payload
cp -rp "$1".app Payload/
zip -r "$1".ipa iTunesArtwork Payload
fi
echo "Done! Send your .mobileprovision and $1.ipa file to your beta testers."

Either save the above code in a file called adhoc (and don't forget to chmod +x adhoc) or

Download the script

adhoc.zip (352 bytes)

Usage instructions

1. Create a folder for your distribution, e.g., "MyApp Beta X"
2. Download the mobile provisioning file you created in the iPhone Developer Program Portal and make sure that it includes all the Devices you want this build to run on (i.e., the Device IDs of your beta testers' iPhones, iPods, etc.)
3. Copy the AdHoc script into the "MyApp Beta X" folder
4. Create a 512x512 PNG or JPEG of your icon, name it iTunesArtwork (without an extension; this is important) and place that in the "MyApp Beta X" folder also.
5. In XCode, create a new Distribution build of your app, making sure to select the correct mobile provisioning profile in the Code Signing Identity section of your Project Settings.
6. Under the Products section of the Groups & Files pane in XCode, right-click the name of your app (e.g., MyApp) and select Reveal in Finder. Copy this executable to your "MyApp Beta X" folder also.
7. Finally, in Terminal, switch to your "MyApp Beta X" folder (tip: you can drag the folder into the Terminal window to get its path)
8. Type: ./adhoc MyApp, substituting the name of your application's executable with MyApp.
9. That's it! When the script is done, you will find MyApp.ipa in the "MyApp Beta X"

When distributing your Ad Hoc build, make sure you send both the MyApp.ipa and your .mobileprovision file to your testers.

I hope this little script helps speed up your process.

How interesting.

Me? Why yes, it just so happens that I am a developer. How'd you know? Oh, my sexy three keyboard cats howling at the moon t-shirt gave me away, eh?

So, you wanna know how to seduce me into your mobile boudoir so I can give you lots and lots of beautiful apps? (Man, you don't waste time do you? That's OK, I like a mobile platform that isn't afraid to take the lead.)

I know you're really excited about smartphones. I mean, who isn't? And apps? Oh, yes! Apps really turn you on, don't they? Those delicious little bundles of pure profit. I can see that you're getting hot under the collar just thinking about how much you can make from them. You know, like how That Other Plaform does today. Oh, I shouldn't mention her? OK, I'll try not to. No, no, I don't think your UI looks fat in that.

OK, so lets cut to the chase. I'm going to be blunt with you. I'm somewhat in demand and I don't just develop for any platform that calls. And you know I'm a professional, right? I mean, I don't do this for free. Goodness knows Mr. A. Dobe tried for years to hypnotize me with his magic Flash Lite thingy but I kept telling him: "Dobe, you ain't getting my apps for free... monetize me, sweetheart". But did he listen? Nuh-huh!

So, if you don't have some way of paying me, you know, like That Other Platform does, we can stop talking right now. Oh, you do... ok, then... you got my attention.

Now, if you want to keep my attention, here are some ground rules:

First of all, Don't Make Me Think!

Yep, just like Steve Krug, I don't like to use my gray matter more than I absolutely have to. You see, it's not that I'm lazy, it's just that there are so many other fish in the sea. If you want me to evaluate you as a suitable mate, you can't afford to play hard to get.

So give me everything I need to start developing on your platform in one neat package that Just Works. Put it all in one DMG, baby, and make it just one click away. One click to download, one click to install, and by the third click you got me up and running! Zero to "Hello, world!" in under 60 seconds or I'm out the door, evaluating your sexy neighbor next door.

What? You've got a few extra pounds and don't think you'll fit into a DMG? That's OK, baby. I don't mind a little meat on my IDE. I understand there's more to you than the size of your SDK. You got baggage, I can deal with that. But how about squeezing all that into a virtual machine for me so I don't have to worry about any of it?

See, I was talking to Sam the other week and I told him just that – not sure if he heard me, though. Sam? Yeah, Sam Sung, you know him? He wanted to get in my pants big time but I just don't think it's going to work out. [Oh man, now I feel dirty!] See I'm a Mac guy and Sam told me I needed a PC to rock his boat. And he's visual in the studio sense, if you know what I mean. "So wait a minute, Sam," I said, "let me get this straight..."

"So you want me to install Windows, then Visual Studio, then your SDK, then a gazillion updates for Windows and Visual Studio before I can even say 'Hello, world?' I don't think this is going to work out."

"Oh, don't worry", he said, all smiles under his $300 suit, "in a year you won't need any of that. I'm going under the knife big time. Yeah, baby, can you say 'proprietary C++ framework'. Uh, huh, that's right sweet cheeks."

"Don't call me sweet cheeks," I found myself yelling as my hand closed round my pepper spray...

Hmm? What? Oh, no, no, you're nothing like Sam. Where were we again?

Oh yes, so what I'm trying to say is, this is no time to be playing hard to get. Don't make me fiddle with your fiddly bits; configure your own dependencies so I can get right down to the fun stuff.

What else? Well, don't pull a Sung on me. Let me use the tools and technologies I already know instead of forcing me to learn a whole new set. Give me some open web technologies to play with and I might just stay the night. Heck, give me some Java-style robot love and I might still be game. But whatever you do, don't force your homegrown bloated framework down my throat. [Eww, ewww, eeeewww!] You're not that Other Company, after all. You have no clue how to pull it off gracefully. [Ba-da-bing-ba-da-boom!]

But you know what? At the end of the day, all I really want is to be treated with a little bit of respect. I only put up with the abuse that That Other Company dishes out because of her supermodel looks and her promises of riches. You've got a lot to prove. Don't pull the same crap she pulls on me. Make my life easier. Be more open. Don't chain me to your whims. And I may even end up liking you better.

Just maybe.

xxx

The company in question, of course, is Apple and the issue I'm writing about is the App Store review process.

Apple is losing its Value Adders

You all know the numbers: there are more than 100,000 apps on the App Store and there are thousands, if not tens of thousands of iPhone developers out there. But numbers never tell the whole story and a company like Apple, with such a strong focus on UX, must understand that quality trumps quantity in the Age of User Experience.

So there are developers that create fart apps and there are developers that not only create apps overflowing with value but also contribute to the community by sharing their knowledge, creating open source projects, and extending the platform. These are the sort of developers I call Value Adders and their presence or absence can make or break a platform.

One such developer is Joe Hewitt.

How Apple lost Joe

When Joe first started developing for the iPhone, he started with web applications. And his first contribution to the community was the iUI framework.

Then, after he started working on native apps and created the excellent Facebook application, he didn't stop there. Instead, he went the extra mile to create and release an open source framework called Three20, which he then used to build the next version of the Facebook app.

Joe is a Value Adder. He doesn't just consume a platform, he extends it. He is exactly the developer you want working on your platform. And he is exactly the developer that Apple just lost.

Back in August, Joe voiced his misgivings about the App Store review process. They apparently fell on deaf ears. Then, this week, he announced in a Tweet that he was leaving iPhone development due to his disenchantment with – you guessed it – the App Store review process. You can read more about Joe's views on the subject in his blog post titled On Middle Men, where he talks about the importance of the web to the future of software (a topic that is close to my heart and one that I recently attempted to address):

We're at a critical juncture in the evolution of software. The web is still here and it is still strong. Anyone can still put any information or applications on a web server without asking for permission, and anyone in the world can still access it just by typing a URL. I don't think I appreciated how important that is until recently. Nobody designs new systems like that anymore, or at least few of them succeed. What an incredible stroke of luck the web was, and what a shame it would be to let that freedom slip away.

His conclusion, especially, is one that we all should take to heart:

In short, the mobile web needs better tools, better standards, and better browsers, and it needs them fast, before the only technologies that matter are the ones controlled by the gatekeepers.

You can read more about Joe's departure in a Techcrunch article titled Facebook iPhone Dev Quits Project Over Apple Tyranny. Om Malik also has a thoughtful piece on the subject titled Cupertino, You Have a Problem.

Joe is not a fart app developer. And his loss to Apple and the iPhone is more than just the loss of a great developer working on one of the most successful iPhone apps out there. It spells the loss of two existing open source projects on the iPhone platform and the loss of the potential future contributions that Joe would have made to the platform.

If investors understood the value of Joe's loss, Apple's stock would be affected.

And Joe is not the only one.

No more amoebas

Hot on the heels of Joe's departure, Mac dev house Rouge Amoeba announced that they will be discontinuing iPhone development because of their harrowing experience with the App Store review process:

In the future, we hope that developers will be allowed to ship software without needing Apple’s approval at all, the same way we do on Mac OS X. We hope the App Store will get better, review times will be shorter, reviews will be more intelligent, and that we can all focus on making great software. Right now, however, the platform is a mess.

How many more prominent developers and Value Adders have to quit the iPhone platform before Apple starts listening? It's time for Apple to at least address the App Store review process issue and tell us what they are planning to do about it. Preferably before all we're left with on the platform are fart app developers.

In the meanwhile, I urge developers to at least keep an eye on the alternatives. Especially gatekeeper-free and more transparent alternatives like Palm's WebOS and Google's Android.

A personal note

This isn't just a current interest item for me as I've been developing for the iPhone for quite a few months now and I've personally been affected by Apple's faulty App Store review process – but that, as they say, is the topic of a separate blog post.

Stay tuned.

Given such a limited and valuable resource, you should be looking to make the most of how you invest it. In other words, which tools and technologies should you devote this limited resource to learning?

If you want to develop on mobile devices, you have a plethora of choices: do you invest time, like I did, into learning Objective-C and Cocoa to develop native applications for the iPhone? Or do you devote that same time into learning Java to develop for the Android? Or do you devote that same time instead into learning C++ and some proprietary framework that will only let you develop for Samsung's upcoming smartphone platform?

The question you should be asking yourself as a developer whenever you decide to invest your most valuable resource is this: how much of a return can I get from this investment? In other words, you need to calculate your Developer's Return on Investment on Time (DROIT).

Developers considering ROI, has the world gone mad?

These are not the DROITs you're looking for

Here's a very simple guide to help you decide whether or not you should invest time in learning a new tool, technology, or platform:

Seek: open standards and open platforms.

Avoid: proprietary platforms and walled gardens.

Let's examine why proprietary platforms and walled gardens constitute bad investments of your time and why open standards and platforms are the logical alternative.

Avoid: proprietary platforms and walled gardens

A proprietary platform is a platform that is developed and controlled by one (or primarily one) commercial entity. While there may be short-term economic incentives for learning and developing on proprietary platforms (for example, the evangelizing company may offer economic incentives or run high-cash-prize contests, or there may be lucrative enterprise contracts), their long-term return may be less certain. More dangerously, you will be locked into developing for a single platform and may have a harder time re-using your knowledge elsewhere. And what if the company in question decides to abandon the technology or stop investing in it?

Case in point: say you decided to learn the proprietary platform that Samsung is building for its next generation of smartphones. You cannot use those skills to develop for the iPhone or Android devices (or for the Web, or for desktop applications). This is a bad investment with a very low DROIT. This is one of the reasons why Samsung will fail dramatically in smartphones – they don't understand developers or the importance of maximizing DROIT.

Semi-open and Openwashing

Unlike Samsung, most companies with proprietary platforms are usually well aware of how unattractive lock-in can be for developers and this is why they often to embrace – at least superficially – open standards. Of course, just because a platform supports XML or some other open technology or standard, it doesn't mean that the platform is open. Most proprietary platforms feature some degree of Openwashing wherein the owners of the platform go to great lengths to make the platform appear more open than it truly is. Adobe did this for a long with the Flash Platform, stating that SWF was an open standard while actively barring anyone else from creating a Flash Player (this has now changed, and the SWF format has truly been opened up but its development and future direction are still primarily controlled by Adobe.)

When in doubt, of course, prefer proprietary platforms that do support as many open standards as possible to increase the reusability of your knowledge and maximize your DROIT. So, a good rule of thumb is:

Prefer semi-open over closed.

But there's an even better rule:

Prefer open over semi-open or closed

Open standards, technologies and platforms – by their very nature – offer you the highest DROIT.

As a developer who wants to maximize her DROIT, you owe it to yourself and your career to invest time in learning these open technologies. The advantages of open over closed are the following:

• No lock-in and skill reuse: the technologies you learn will be applicable across different platforms and devices; both today and in the future
• No walled gardens: to paraphrase Oliver, you don't have to ask "please, sir, may I deploy my app" to deploy or sell your apps

So, as a developer looking to enter the exciting world of mobile development, what technologies should you learn?

Based on the simple guide, above, and on a desire to maximize your DROIT, the answer is plainly clear:

Learn HTML5, CSS3, and JavaScript

The web is the best example of an open platform that we have today. It is the antithesis of a walled garden: you can deploy what you want, when you want, and don't have to ask anyone for permission.

While iPhone developers wait months on end for a response from Father Apple, you can deploy dozens of apps to the web without hassle.

And the technologies of the web, open standards all, have the highest reusability of any technology to date. Perhaps the saying should go: Learn HTML, CSS, and JavaScript and you shall never go hungry.

"But, Aral," I hear you say, "surely there are drawbacks to building apps using web technologies."

"Surely someone like yourself, with such a strong focus on User Experience, should understand that it would be untenable to create experiences using such generic technologies that match the experiences possible with native tools and technologies on mobile platforms."

Thus, surely, an iPhone web app must offer a lesser experience than the same app built using Objective-C and Cocoa Touch. Thus, surely, we must embrace the Lowest Common Denominator and sacrifice UX if we develop using cross-platform technologies.

Not at all.

Embracing Write Once, Compile Anywhere, not Write Once, Run Anywhere.

The ability to re-use code and easily port your applications between platforms and devices does not imply that we take a Lowest Common Denominator, Write Once, Run Anywhere (WORA) approach to UX.

Write Once, Run Anywhere has long been seen as the Holy Grail of software development. Sun promised us this elusive ideal years ago with Java and failed to deliver on it. Flash managed to deliver it across browsers and operating systems insofar as the web was concerned but Adobe then decided to embark on a futile mission to replicate this success across desktop applications and mobile devices. And browsers – and HTML, CSS, and JavaScript – were, and continue to be, criticized for failing to deliver on this due to the many browser incompatibilities that plagued developers in the early days of the web before we had better standards support in browsers and JavaScript libraries like JQuery that abstract out the more painful inconsistencies in the DOM.

But what do we mean by Write Once, Run Anywhere in today's world? And is it even a goal worth having?

No, it's not.

Not as the term has traditionally been understood in any case.

Defining Write Once, Run Anywhere (WORA)

Write Once, Run Anywhere implies that you create an application once and it runs the same way (or similarly) on anything. If you're Adobe, pushing Flash, "anything" may include the Web, desktop, and mobile devices.

If you have any understanding of User Experience, you will instinctively realize that regardless of whether or not WORA is technically attainable, it is definitely not a desirable goal to have as far as the user experience is concerned.

User Experience is about focus and optimization. You cannot write a web application and have it be a great user experience on the iPhone, for example, without optimizing the user experience for the iPhone. Optimizing in this sense of the word doesn't just mean scaling your interface down to fit within the dimensions of the iPhone's screen. It may mean having to completely recreate the UI of your app, including user gestures and interactions, to give your iPhone users the best possible experience on their device.

The same goes for when you want to run that same application on an Android phone or the Palm Pre. Where the changes may be less pronounced than those required to go from Web or Desktop to Mobile, the difference in feature sets and operating system expectations between the devices will require UX optimizations that may dramatically affect the structure of your user interfaces.

So while you can port an application that uses open web technologies across platforms and devices, you must still optimize the User Experience for each platform and device that you support. I won't downplay the importance of this: it may mean that you have to do a lot of work and invest a lot of time and money into altering your user interface radically to best support the unique features of the platform or device you are supporting.

However, it will mean that you do so without changing technologies and without changing your entire codebase (this is where maintaining a clear separation of concerns between your View and Model begins to pay real dividends.)

Even though Write Once, Run Anywhere is undesirable insofar as UX is concerned, it doesn't reduce your DROIT in open technologies. While the re-usability of your applications may not extend to the UI layer (or may apply less to it depending on how similar your various target platforms are), it will still apply to other parts of your application.

Using open technologies will make it easier to port your applications across platforms and devices. This does not mean, however, that there is a magic bullet that will make your applications usable on every platform. The concept of Write Once, Run Anywhere is a relic from the Age of Features that has no place in the Age of User Experience.

But what about the argument that applications built using web technologies cannot be as optimized for UX as native applications?

In a nutshell, it fails to hold water, and brings us to the alternative to WORA.

The alternative to WORA: Write Once, Compile Anywhere (WOCA)

There are currently a plethora of tools and technologies – both open and closed – that allow you to re-use your DROIT in open technologies to build native applications across various platforms without sacrificing UX. In fact, this is one the most exciting trends of our time and one of the reasons why it's a great time to be a developer.

Examples abound: the open source Phonegap framework, for example, lets you build applications using your existing DROIT in open web technologies while compiling your app into native applications on iPhone, Android, and Blackberry.

And it's not the only one. Check out Titanium and Appcelerator, and also look at web frameworks like iUI, xUI, Magic Framework, and JQTouch – all of which increase your DROIT.

Commercial and proprietary platforms are also embracing WOCA. Adobe, for example, realized that WOCA was the way to stay relevant with the iPhone and their upcoming Flash IDE in CS5 allows developers to create iPhone applications by re-using their DROIT in the Flash IDE while outputting native iPhone apps. (I hope Adobe wakes up and realizes that it has a far brighter future if it focusses on its development tools and native compilation with WOCA instead of spending time and money on trying to get native support for Flash on devices. Flash support in mobile browsers is necessary for a faithful rendering of today's web but native Flash support for applications adds absolutely no value to a platform.)

(Another proprietary WOCA solution to keep an eye on is Unity3D.)

Beyond WOCA: Palm leads the way with WebOS

The WOCA solutions we have today are a wonderful way of increasing DROIT in open web technologies. But mobile platforms can do better by actually embracing web technologies as first class citizens on their platform. (Not as crippled subsets like Apple's initial foray on the iPhone.) In fact, one company is already doing that and doing it beautifully.

While Microsoft drifts aimlessly with Windows Mobile trying to play a fruitless game of cat and mouse with Apple, and while Google – the defender of all things open and web – invests in Java with Android, one company has come out of left field with a solid vision to embrace open web technologies for its mobile platform. That company is Palm and its platform is called WebOS. And you should stand up and take notice because it is one of the most important developments in the mobile world today.

With WebOS, you don't need to compile your HTML, CSS, and JavaScript to native applications because they are the native technologies of the platform.

Beyond supporting open web technologies, Palm also supports the ethos of the Web. You are not bound to Palm's store (even though they have one) and can deploy your apps to the web without asking permission from anyone. (If you do want to use their store, you can do that also and get the best of both worlds – the impulse buys and worry-free purchasing that the store provides coupled with the freedom to also distribute your apps yourself.)

More than that (and this is a personal point), having been to the Palm developer event in London recently and met Dion and Ben (who head up Palm's developer relations), I have to say that Palm has some genuinely nice people working for them. I love their approach and their vision. They have hired developers who have contributed to the open web and believe in its future. In other words, Palm has the right people running the show. And I wish them all the success.

(And this has nothing to do with the fact that they gave me a free Palm Pre to play with. In fact, if anything, I find it unfortunate that the hardware of the Pre doesn't allow the software and Palm's vision to shine currently. But it is a Version 1.0 phone and I look forward to seeing how the hardware evolves with the Palm Pixi.)

In conclusion

As a developer, your scarcest resource is time. It is thus of paramount importance that you invest this time wisely in learning the relevant open web technologies of today – namely HTML5, CSS3, and JavaScript – in order to maximize your DROIT.

Thanks to WOCA solutions like Phonegap and native web platforms like Palm's WebOS, you no longer have to sacrifice either your investment in open web technologies or your commitment to creating great user experiences. In other words, you can have your cake and eat it too!

Bon appetite!