In the past month or so I've been dabbling around in my free time with developing applications for the BlackBerry PlayBook. There were two simple reasons for this. First of all RIM's 'WebWorks' SDK allows applications to be developed as pure HTML5 applications which is obviously pretty awesome for a front-end guy like me. Secondly the fact that RIM is handing out free PlayBooks may have had something to do with it. By now I have finished two applications that are available for free in BlackBerry AppWorld and I'm working on a third one. Based on the first two applications RIM has already deemed me worthy of receiving a free PlayBook so I'll be the proud owner of one of these puppies as soon as they hit the market. Go me!

BlackBerry PlayBook: awesome.

So what's it like, developing for the BlackBerry PlayBook? There's quite a lot to talk about which is why I figured I'd do a little writeup on it and provide some completely unsolicited advice to RIM for the future. I'm just going to pretend for a while that I'm Head of Tablet Development at RIM. Here's what I would do and what I would not do.

SDK's, SDK's, SDK's

It's not all there yet but it certainly looks like the PlayBook will go down in history as the device with the highest amount of different SDK's to develop applications with. There's an Adobe AIR SDK, a native C/C++ SDK (coming soon), a HTML/JS/CSS based SDK and last week RIM dropped the news that the PlayBook will support Android applications, albeit not completely like an Android tablet would. I suppose that means we have a whopping 4 different ways of developing applications for the same platform. Awesome, right? Yes and no. On one hand it's pretty cool when there's so many different flavors of development for a platform. It means developers can pick whatever environment they're most comfortable with and develop an application. This is great on paper but in my personal opinion not when a device hasn't even launched yet. So here's my first free unsolicited advice to RIM:

1: Focus on only HTML5 and Native C/C++ until both SDK's are fully matured. Only then it may make sense to look at more SDK's. Even then you have to ask yourself: what do any extra SDK's really add?

Currently BlackBerry PlayBook developers are looking at two very immature SDK's (WebWorks/HTML and Adobe AIR) and the native SDK isn't even out yet. In addition RIM is working on getting Android applications to run on the PlayBook. I'm not sure what the point of all this is. Why not focus all energy on just two SDK's first and make sure they're perfect? I'm pretty sure we'd have a more mature WebWorks SDK as well as a released C/C++ SDK by now if RIM hadn't been busy trying to support 'everything'. What in the world does Adobe AIR add that HTML5 can't do? Nothing! And since the PlayBook supports Flash the whole Adobe camp could probably function just fine with WebWorks and an embedded SWF file. Both SDK's will eventually be able to do the exact same thing. So unless Adobe is sending RIM large suitcases full of stacks of $100 bills I wouldn't bother with AIR. Not that there's anything wrong with AIR per se but it's just not worth the extra overhead. And what do mildly crippled Android applications add to this mix? Probably nothing besides enabling RIM's marketing folks to say there's a bazillion applications available that run on the PlayBook. Unfortunately most Android applications are rather crappy and they'll be even crappier than they already are in a crippled runtime. Also, if you really have to do Android just let the applications run free and don't require Android developers to (re)submit their applications to BlackBerry AppWorld. I sincerely doubt many developers will actually do this.

What do you mean, consistent look and feel?

I'm not a fan of Apple's walled iOS garden but if there's one thing they nailed it has to be the super consistent user experience which is present in almost any iOS application. Another vendor that did everything right in this department is HP/Palm. Both provide a robust set of UI components that ensure that all applications look great. Even if they were created by developers with little or no UI design skills. The first batch of PlayBook app are a great example of why this is important. And so is the Android universe. Everything looks and feels different and many applications are simply butt ugly. So here's advice number two:

2: Form a strong team of ninja front-end developers and recreate all QNX widgets in HTML/CSS/JS for the WebWorks SDK. Create a UI style guide, a set of examples and strongly encourage developers to stick to it. It works for Apple, it works for HP/Palm so it can work for RIM as well.

Now we're getting somewhere. We are now on our way towards an app universe of both native and web applications that all have the exact same look and feel. Take my word on this: Users LOVE that. Nobody likes to see a collection of completely different looking applications where people have to scratch their heads and think "How the hell does this thing work?" every time they launch a new app.

Developer feedback

I'm sure this is all about getting things started but still: I personally had to wait for 3.5 weeks before my submitted application got approved for BlackBerry AppWorld. And if you think that's a long time, think again. I've seen plenty of cases where people have been waiting for 2 months or more without receiving a notice of any kind on what's going on and why the approval process is taking so long. This is a huge de-motivator for any developer who wants to put his/her work out there. So here's my last bit of advice:

3: Make sure the waiting time for developers to receive feedback on their app submission doesn't exceed... let's say 3 weeks. Especially when you have a new platform it's VERY important to keep your developers motivated.

Several months is really unacceptable no matter how you put it. Especially if this waiting time comes with absolutely NO communication. Hire more reviewers if you have to!

So there you go. This is my advice for RIM that I could come up with while pretending to be the Head of Tablet Development in Waterloo, Canada. Don't get me wrong, I really enjoyed creating my first two PlayBook applications. The fact that they earned me a free PlayBook is even better. I'll surely be developing more applications in the future. That said, from looking at the WebWorks SDK it's easy to tell that there's a LOT of work to do for RIM still. At the moment the SDK hardly supports any hardware related features which limits applications to what can be done in a regular browser. Obviously this is not nearly enough. We want to be able to take pictures, record video and audio, access files on the device and a whole slew of other things. Only then the REALLY cool applications can be built.

I'm wishing RIM the best of luck with the launch of the PlayBook. I'm sure it won't be easy to engage in battle with Apple and the rest of the competition but who knows, it might just work. The PlayBook sure is a sweet and powerful piece of hardware that's totally up to the task. Now let's make sure the software is too!

WTF Where's my email and messaging?

After reading this article on Wired I felt the need to add a fourth friendly unsollicited advice, even though it has little to do with development on the PlayBook:

4: Put every second of developer time you can get your hands on in the next three weeks behind making sure the PlayBook ships WITH email and messaging.

Seriously RIM, if this isn't on the PlayBook the whole world will have a huge collective 'WTF?????'-moment as soon as people get their hands on the PlayBook. You'll be burned at the stake in any review and people who buy one will go back to the store after they find out they can't read their email on the PlayBook unless they own a BlackBerry smartphone. Absolutely unacceptable. Whoever thought this was a good idea at RIM must be suffering from some serious delusions. I appreciate the security of the BlackBerry Bridge for enterprise use and all but... There's a LOT of 'Joe Users' out there who just want to read their email and do messaging with their friends. Come on RIM, fix this as soon as humanly possible.