Putting a burden on your platform

There’s been an equal amount of like and dislike for RIM’s upcoming foray into the tablet space, the BlackBerry Playbook. From a UI perspective it actually looks like a half decent entry into the tablet space and one that while it is definitely not a direct challenger to the iPad; it is in fact a welcome change into the space dominated by questionable Android tablets.

What has me a little confused and worried is the promise of Playbook’s extensive legacy support; especially supporting existing applications made for BlackBerry OS 6 made in Java or WebWorks. It’s one thing to support existing BB OS applications (like iOS does going from iPhone to iPad) but it’s even more dangerous to make it a selling feature that you can take the existing applications you know and love from your low resolution BlackBerry and then have them working on this completely different paradigm shifted tablet device.

I feel RIM is supporting way too many platforms and treating their new consumer device like a PC. From the looks of the specification PDF (seriously, what sort of company publishes their specs only in PDF format?) the Playbook supports Air/Flash, HTML5, Java, POSIX OS (do they mean C?), BlackBerry 6, etc etc.

Supporting that many platforms and especially supporting that many legacy platforms isn’t going to be the death of the Playbook (I for one hope it succeeds, the UI is pretty sexy) but I think it’s going to be a dent in the user experience. Users are going to through on a bunch of applications that they can get their hands on in the RIM App World and I think they are going to be confused or a put off by the weird inconsistency of the app behaviours; you’ll have some apps that feel that they depend on a keyboard or optical trackpad, you’ll have some that depend on a mouse pointer and then you’ll finally find some apps that like and handle multitouch well.

Not to bring this back to Apple but I’m glad that iOS sticks to one native platform and forces everyone to use it. With Objective C and the iOS frameworks (CoreAnimation, CoreGraphics, etc) all developers have the same way of accepting input, drawing graphics, rendering native UI controls and interacting with the “multitasking” layer. There’s even a guide from Apple on how to treat user experience in your applications.

Sadly RIM is trying to play catchup in the tablet space and to do that they are more concerned about the number of apps at launch, than the sexiness of their apps at launch. RIM needs to understand that they world has move on from accepting BB OS’s outdated UI and accept that from the homescreen to the app everything needs to look awesome.

add a comment Posted 18/04/2011 as rim, blackberry, playbook, java, apps, tablet

introducing lightpanel.

I’ve always been interested in building things off the desk or off the computer in front of us; that’s why I love building mobile products. But I’ve always had a passion for visual display through lighting, so with that I’ve been working and revising lightpanel for the past year.

Lightpanel is a project I’m building that comprises of three LED (7 column, 9 rows) Phidget boards that are connected to a computer over USB and exposed over the network by a lightweight and fast Java server that accepts commands over socket connections. For example if I want to switch on row 2 and column 5 at 100% I just send the command “2 5 100” to the server over a standard socket session (telnet works great)

Here is my latest demo which is a snake simulation where the snake moves around the 3 boards with its tail decaying as it moves along. Because of the great framework I’m using on Java end I actually have 5 ruby clients running an instance of the snake resulting in a pretty crazy visualisation.



Source on Github.

add a comment Posted 01/03/2011 as led, ruby, java, hacking, project